Time to first byte ends before the browser can render anything. A slow value can come from redirects and network distance, but WordPress often spends it bootstrapping plugins, querying options, waiting on the database, or calling another service.
Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: break server response time into network, cache, PHP, database, and external-call work before cleaning autoloaded options.
What the symptom narrows down
- Page caching misses and PHP executes expensive work on every request.
- Large autoloaded options are fetched during WordPress bootstrap even when the page does not use them.
- Database contention or outbound HTTP delays the response.
The branches are ordered to protect the strongest evidence around this possibility: page caching misses and PHP executes expensive work on every request. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Performance work needs a measured bottleneck and a comparable before/after trace; a faster test after warming a cache or changing network conditions is not proof that the code improved; in this guide, the practical goal is to break server response time into network, cache, PHP, database, and external-call work before cleaning autoloaded options.
Evidence to collect before the fix
- Measure uncached and cached TTFB with
curl -wfrom more than one location. - Profile PHP/database time on staging and list autoloaded option sizes with WP-CLI.
- Identify the owner and access pattern of each large option before changing it.
- Inspect external HTTP calls and cron work accidentally running in the request.
The sequence moves from observation toward intervention. Preserve the result of the final check—inspect external HTTP calls and cron work accidentally running in the request—because it provides a useful comparison after the repair.
From first observation to a reversible decision
Begin with the first plausible cause: page caching misses and PHP executes expensive work on every request. Before changing state, write down what would confirm it and run the first read-only check: measure uncached and cached TTFB with curl -w from more than one location.
If the result supports that cause, try one bounded repair on staging: restore effective page/object caching for public pages. If evidence from “Measure uncached and cached TTFB with curl -w from more than one location” points elsewhere, keep this layer unchanged and move to the next check. That small decision log is far easier to audit than several simultaneous edits.
Apply fixes in the safest order
- Restore effective page/object caching for public pages.
- Update or remove the component that stores inappropriate bulk data as autoloaded; change autoload behavior only with ownership understood.
- Optimize slow queries and move background work out of the page response.
Before applying “Restore effective page/object caching for public pages,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can compare percentiles and cache states, not one fast request; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Measure TTFB and inspect the largest autoloaded options
Take repeated cached and uncached measurements, then inspect option size without deleting anything.
curl -sS -o /dev/null \
-w 'status=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/
wp db query "SELECT option_name, LENGTH(option_value) bytes
FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC LIMIT 20;Interpretation and safety: Confirm the table prefix and WordPress version. Large does not mean unused; identify the owning plugin and read path before changing autoload behavior.
Prove recovery
- Compare percentiles and cache states, not one fast request.
- Confirm functionality that owns changed options still works.
- Watch database queries, PHP time, and external-call time separately.
One successful refresh is not closure. Keep the incident open until you can also confirm functionality that owns changed options still works, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Record URL/template, device and network profile, cache state, geographic test point, trace or waterfall, field-data window, and deployed version; report medians or percentiles across repeated observations rather than the best run; include the result of this first observation: measure uncached and cached TTFB with curl -w from more than one location.
State what was tested, including the result of “Measure uncached and cached TTFB with `curl -w` from more than one location,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Shortcuts that create a second incident
- Do not delete large options by name without knowing their schema and owner.
- Do not call a front-end optimization successful if origin TTFB remains slow.
Change record
Primary references
- WordPress optimization — official reference consulted for this guide.
- Optimize LCP — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Restore effective page/object caching for public pages”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.