Originally published: May 3, 2022 · Last updated: August 16, 2026
Time to First Byte, or TTFB, measures how long it takes from the start of a request until the first byte of the response begins to arrive. It is often described as a server metric, but that is only part of the story: connection setup, network latency and backend processing can all contribute.
Why TTFB matters
TTFB happens before the browser can begin processing the HTML response, so a slow TTFB adds delay to later loading milestones. It does not describe the whole page experience, but it is a useful diagnostic signal when a site feels slow before anything appears.
web.dev gives roughly 0.8 seconds or less as a practical target for many sites, while emphasizing real-user measurements rather than one isolated laboratory test.
What can increase WordPress TTFB?
Common causes include:
- slow hosting or an overloaded server;
- uncached dynamic page generation;
- heavy plugin or theme processing;
- slow database queries;
- remote API calls during page generation;
- unnecessary redirects;
- geographic distance between visitors and origin server;
- cache misses at the CDN or page-cache layer.
Measure before changing anything
Use more than one observation. Compare real-user data, PageSpeed Insights or another field-data source with a repeatable lab test. Test from a region that resembles your audience.
A fast result from a data center next to the host does not tell you what distant visitors experience.
Start with full-page caching
For public WordPress pages that do not need to be generated uniquely for every visitor, page caching can remove much of the PHP and database work from repeat requests.
If the first uncached response is slow but cached responses are fast, the bottleneck is probably in backend generation rather than the network alone.
Audit expensive plugins and theme work
Plugins can add database queries, remote calls and processing before WordPress returns HTML. Do not assume the plugin with the largest interface is the slowest. Measure the site with controlled tests and inspect the request path.
Removing one unnecessary heavy plugin can matter more than installing another optimization plugin.
Check the database and scheduled work
Large autoloaded options, inefficient queries, accumulated transient data and badly timed background jobs can increase backend work. Database cleanup should be targeted and backed up, not performed blindly because a table looks large.
Reduce redirects in the critical path
Each redirect adds another request-response cycle before the final document arrives. Make internal links point directly to the current canonical URL and avoid chains created by multiple historical URL changes.
Use a CDN or edge cache where it makes sense
A CDN can reduce geographic latency for static assets, and some services can cache HTML closer to visitors. The benefit depends on the site’s architecture and whether pages are safely cacheable at the edge.
Do not optimize TTFB in isolation
A low TTFB does not guarantee a fast page if the browser then has to process excessive JavaScript, CSS, fonts and images. Use TTFB as one part of a larger performance investigation.
A practical WordPress TTFB checklist
- Measure from representative locations.
- Compare cached and uncached responses.
- Check hosting resource pressure.
- Audit plugin and theme overhead.
- Inspect slow database work.
- Remove unnecessary redirects.
- Review CDN and cache configuration.
- Retest the complete user experience.
The practical rule
TTFB is a diagnostic metric, not a trophy score. Find where the delay occurs, improve the slowest layer and then verify that the change improves the page experience for real visitors.
Official reference: web.dev guidance on optimizing TTFB.