Back to blog
Reducing TTFB in WordPress: Where Server Response Time Actually Goes
TTFB isn't one number, it's five stages stacked together. Here's how to find which one is slow before you blame your host.
TTFB isn't one number, it's five stages stacked together. Here's how to find which one is slow before you blame your host.
"Reduce initial server response time" is one of the least helpful warnings a speed testing tool produces. It tells you the number is too high without telling you which part of it is slow, and the reflexive response, blaming the host, is right maybe half the time.
Time to First Byte is not a single measurement. It's five distinct stages stacked end to end, and only one of them is your server actually generating a page. A site with a fast backend and a slow redirect chain, or a fast backend and a distant server, will post the same bad TTFB as a site with genuinely slow PHP. The fixes are completely different.
TL;DR
- TTFB is documented by web.dev as covering redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request phase up to the first byte. Server processing is one component, not the whole thing.
- Thresholds: good at or under 800 ms, poor above 1,800 ms, assessed at the 75th percentile like Core Web Vitals.
- TTFB is not itself a Core Web Vital. web.dev states plainly that "because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the 'good' threshold." It's a diagnostic that constrains LCP.
- The
Server-Timingresponse header is the tool for splitting server-side time into its real parts (database, template rendering, cache hit or miss) instead of guessing.- 103 Early Hints does not reduce TTFB. It lets the browser start fetching resources during the server's existing think time, improving LCP. Don't confuse the two.
- The single biggest WordPress-specific lever is whether the request hits a cache at all, since a cached response skips PHP and the database entirely.
web.dev defines TTFB as "the time between starting navigating to a page and when the first byte of a response begins to arrive," and documents its components explicitly:
Only the last item involves your server doing work. The other four are network and protocol overhead that happen before your server begins generating anything.
This is why "my TTFB is 1.4 seconds, my host is slow" is often wrong. It might be. It might also be a redirect chain, a slow DNS provider, or a server on another continent from your visitors.
web.dev's documented cutoffs:
| Rating | TTFB |
|---|---|
| Good | ≤ 800 ms |
| Needs improvement | 800–1,800 ms |
| Poor | > 1,800 ms |
Assessed at the 75th percentile, the same methodology as Core Web Vitals.
Worth being precise about, because plenty of content implies otherwise. web.dev states: "Because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the 'good' threshold."
What it is instead is a diagnostic metric that constrains everything downstream. web.dev notes TTFB "precedes every other meaningful loading performance metric," including LCP. If TTFB consumes 1.5 seconds of your 2.5-second LCP budget, you have one second left to download and render your largest element, which is usually not enough.
So the practical framing: you don't chase a good TTFB for its own sake. You chase it because a bad one makes a good LCP arithmetically impossible.
Before optimising, find out which of the five components is actually consuming your time. Guessing here wastes the most effort of anything in performance work.
Open the Network tab, click your main document request, and look at the Timing panel. It breaks the request into named phases that map closely to the components above: redirect, DNS lookup, initial connection, SSL, and waiting for the server response.
The "Waiting" or TTFB row within that breakdown is the server-processing portion. If that's 90 ms and your total is 1.2 seconds, your server isn't the problem.
For splitting up the server-side portion specifically, Server-Timing is the right tool. MDN describes it as communicating "one or more performance metrics about the request-response cycle to the user agent," used "to surface backend server timing metrics (e.g., database read/write, CPU time, file system access) in devtools."
The syntax:
Server-Timing: db;dur=53, app;dur=47.2Each entry has a name, an optional dur in milliseconds, and an optional desc. Those map onto the PerformanceServerTiming interface in JavaScript, so they're readable programmatically as well as in DevTools.
web.dev specifically recommends Server-Timing as the diagnostic for finding why TTFB is slow, distinguishing database time from rendering time from cache hits and misses.
For WordPress, the practical route to this is the Performance Lab plugin from the WordPress performance team, which ships a Server-Timing API. Its default metrics are wp-before-template, wp-template, and wp-total, which split the request into WordPress bootstrap versus template rendering versus everything.
One security note directly from MDN: the header "may expose potentially sensitive application and infrastructure information." Be deliberate about what you emit, and consider restricting it to authenticated sessions or non-production environments.
Every redirect is a full round trip before the real request begins. A chain like http://example.com → https://example.com → https://www.example.com costs two round trips before your server does anything useful.
web.dev's guidance is to eliminate redirects, particularly same-origin ones, and to use Strict-Transport-Security (HSTS) so browsers go straight to HTTPS without the initial redirect. HSTS preloading extends that to first-time visitors who've never hit your site before.
For WordPress specifically, the common causes are: a WP_HOME/WP_SITEURL mismatch with your actual canonical domain, redirect plugins with accumulated chained rules, and trailing-slash handling that bounces requests. Test with curl -IL on your main URLs and count the hops.
DNS resolution happens before anything else, and slow DNS is invisible in most speed tests because it's usually cached by the time you run a second test.
The fix is a fast, well-distributed DNS provider. This is infrastructure rather than something you tune, but it's worth checking rather than assuming.
Modern protocols reduce this materially. HTTP/2 and HTTP/3 with modern TLS cut the number of round trips required to establish a connection. web.dev lists this among the benefits of using a CDN, which typically brings "faster DNS, HTTP/2/HTTP/3, modern TLS, and compression" alongside the geographic benefit.
This one is physics and can't be optimised away, only routed around. A server in Frankfurt answering a visitor in Sydney has an irreducible round-trip cost regardless of how fast your PHP is.
web.dev names CDN adoption as the fix, since edge nodes serve from a location closer to the user. For a cached WordPress page, that's the whole response. MagicWP's global edge cache operates across multiple regions for exactly this reason.
This is what people usually mean by TTFB, and it's where WordPress-specific work happens.
web.dev's first recommendation is blunt: hosting is "the first thing you consider," noting that memory allocation, how current the backend stack is, and the provider's maintenance practices all matter, and that shared hosting is generally slower than dedicated or managed options for larger applications.
Beyond hosting, in rough order of impact for WordPress:
Cache the response. web.dev's guidance is to "use the appropriate Cache-Control HTTP headers" so edge and CDN caching can serve without touching your origin, noting that even short cache windows help busy sites. For WordPress this is the largest single lever available: a cached response skips PHP, plugins, and the database entirely.
web.dev adds a diagnostic tip worth adopting: keep a cache-bypass mechanism, such as a query parameter, so you can measure your true backend time separately from cached responses. Otherwise you're measuring your cache and calling it your server.
Add a persistent object cache. For requests that can't be page-cached (logged-in users, cart pages, admin, REST API calls), Redis or Memcached keeps repeated query results in memory rather than hitting MySQL again.
Find your slow queries. Query Monitor attributes slow database queries to the responsible plugin. A single badly written query in one plugin routinely accounts for most of a site's server processing time.
Check autoloaded options. WordPress loads all autoloaded options in one query on every request. WordPress 6.6 added a Site Health warning above 800,000 bytes, and a bloated wp_options table adds measurable time to every uncached request.
Verify OPcache is enabled and adequately sized, so PHP isn't recompiling core, your theme, and every plugin on each request.
Move WP-Cron off page loads on busy sites, using DISABLE_WP_CRON plus a real system cron, so scheduled work doesn't compete with visitor requests.
103 Early Hints appears in a lot of TTFB advice, and it's usually described incorrectly.
Early Hints is a preliminary HTTP response sent before the final one, carrying Link headers with preconnect or preload hints so the browser can start fetching resources while your server is still generating the actual page.
It does not reduce TTFB. TTFB is measured to the first byte of the final response, and Early Hints doesn't make that arrive sooner. What it does is let the browser use the waiting time productively. Chrome's documentation frames its impact in terms of LCP, citing improvements of several hundred milliseconds up to a second in real-world cases.
Chrome's own docs also carry a warning worth repeating: Early Hints "can mask underlying performance issues." If your server takes 1.5 seconds to respond, Early Hints makes the page feel better without fixing why it takes 1.5 seconds.
Browser support differs by hint type, with preload support notably narrower than preconnect. Treat specific version numbers as worth re-checking rather than trusting any published figure, including this one.
A question that comes up constantly: what proportion of TTFB is typically network versus server processing?
There's no documented answer. web.dev doesn't publish a ratio, and it would be meaningless if it did, because it depends entirely on the distance between your server and your visitor, your protocol stack, and how much work your application does. A site with a 400 ms backend serving local visitors and the same site serving visitors on another continent have wildly different splits.
This is exactly why the diagnostic step comes first. Measure your own split with DevTools and Server-Timing. Anyone quoting you a general percentage is making it up.
Server-Timing for the server-side portion.curl -IL. Cheapest possible win if you find any.What is a good TTFB? web.dev documents good as 800 ms or under, needs improvement between 800 and 1,800 ms, and poor above 1,800 ms, assessed at the 75th percentile of page views.
Is TTFB a Core Web Vital? No. web.dev states explicitly that it isn't, and that meeting the good threshold isn't strictly necessary. It matters because it precedes every other loading metric, so a bad TTFB makes a good LCP very difficult to achieve.
Why is my WordPress TTFB high even with a caching plugin? Common causes: the request isn't actually hitting the cache (logged-in users, cart pages, and query strings often bypass it), a redirect chain runs before the cached response, or the geographic distance to your server dominates. Check the DevTools Timing breakdown to see which stage is consuming the time.
Does a CDN reduce TTFB? It can substantially, by serving cached responses from a location closer to the visitor and by bringing faster DNS, modern TLS, and HTTP/2 or HTTP/3. It doesn't help with uncacheable requests that still have to reach your origin.
How do I find out what my server is actually spending time on?
The Server-Timing response header, which MDN documents as surfacing backend metrics like database read/write and CPU time in DevTools. For WordPress, the Performance Lab plugin ships a Server-Timing implementation with wp-before-template, wp-template, and wp-total metrics.
Does 103 Early Hints reduce TTFB? No. TTFB is measured to the first byte of the final response, which Early Hints doesn't change. It lets the browser start fetching resources during the server's existing processing time, which improves LCP. Chrome's documentation also warns it can mask underlying performance issues.
Is high TTFB always the host's fault? No. Server processing is only one of five documented TTFB components. Redirects, DNS, connection and TLS negotiation, and geographic distance all count toward it, and all are independent of how fast your host generates pages.
Does PHP version affect TTFB? It can, since newer PHP versions have generally improved execution performance, and OPcache configuration affects whether PHP recompiles your code on every request. But on most WordPress sites, slow queries and cache misses dominate over raw PHP execution speed.
TTFB is a stack of five stages, and the useful work is figuring out which one is yours before you start fixing anything. Redirects and DNS are cheap to check and cheap to fix. Geographic distance is solved by edge caching. Server processing is where WordPress-specific work lives, and there the order is: make sure the request is cached at all, then profile what the uncached path is actually doing.
Two things to avoid. Don't chase TTFB as a goal in itself, since it isn't a Core Web Vital and its real significance is the budget it leaves for LCP. And don't accept Early Hints as a TTFB fix, because it isn't one, however useful it may be for LCP.
Measure the breakdown, fix the stage that's actually slow, and re-check in the field rather than in a single test from your own laptop.
Monthly engineering notes, product updates, and WordPress performance tips. No spam, unsubscribe anytime.
