Time to First Byte is five phases, and three of them are finished before WordPress runs a single line of code. Redirects, DNS and the connection handshake all happen while your server is still unaware that anyone wants anything. Only the last two phases belong to PHP, the database and your host.
That split is the whole article, because it decides whether the standard advice applies to you. Almost every “reduce TTFB in WordPress” guide optimises phase five and skips the rest. If your problem is an http-to-https-to-www redirect chain, or an origin server on another continent, you can tune PHP all week and move nothing.
TTFB is five phases, three of them off your server
Google defines TTFB as the sum of redirect time, service worker startup time where one exists, DNS lookup, connection and TLS negotiation, and then the request itself up to the moment the first byte of the response arrives (web.dev, verified August 2026). Good is 0.8 seconds or less, poor is over 1.8 seconds, at the 75th percentile of real page views.
Read that list slowly. The browser has to resolve your domain, open a connection, negotiate TLS and follow any redirects before your server is even asked for a page. On a WordPress site with a redirect chain and a distant origin, that prelude can be the majority of the number. Everything the usual checklist talks about — caching, plugins, queries, PHP version — lives in the last phase.
One more framing that saves a lot of wasted effort: TTFB is not a standalone score to beat. It is the first leg of Largest Contentful Paint, and web.dev’s healthy shape for LCP allocates it roughly 40% of the budget. So the question is never “is my TTFB good” in isolation. It is how much of your LCP target you have already spent before the first byte arrives.
The one metric where a better host is the answer
We normally tell people the opposite. Changing host rarely fixes a slow site — the plugins, the images and the code travel with it, so the bottleneck arrives at the new server intact. “We need a faster host” is the reflex diagnosis precisely because it is the one that is nobody’s fault.
TTFB is the exception, and it is the only one. It measures your server answering, so hardware, PHP version, database and physical location genuinely set the floor. web.dev’s own advice on the server phase is close to a shrug — “a general rule of thumb is to ensure that your website’s host is capable of handling the traffic you send to it” (verified August 2026) — because past a point there is nothing clever left to do, only a better machine.
And it is still the third move, not the first. Ahead of it come two cheaper things. One: the phases before your server, where a collapsed redirect chain costs nothing and can return more than a hosting upgrade. Two: a page cache, which changes the question from “how fast does my server build this page” to “how fast does my server hand over a file it built earlier”. web.dev makes the point that with caching in place only the first visitor in each caching window pays the full latency back to the origin server (verified August 2026). Buying a faster machine before that is paying, monthly, to run PHP that should not have run.
What makes TTFB long on WordPress
Same five phases, mapped onto what actually goes wrong on a WordPress install. The phase column is the one to read first — it tells you whether the row is even yours to fix on the server.
| Factor | Phase | What it costs you | The fix |
|---|---|---|---|
| Redirect chain (http → https → www) | Before the server | A full round trip per hop, paid before anything else starts | Collapse to a single server-level redirect and point your internal links and canonicals at the final URL |
| Slow or distant DNS | Before the server | A delay before the connection is even opened | A DNS provider with a wide anycast network — most CDNs include one |
| Distance to the origin, old TLS setup | Before the server | The handshake costs more the further away the server is | Serve from the edge, keep HTTP/2 or HTTP/3 and a modern TLS config on |
| No page cache | Server | Every visitor pays for the full WordPress bootstrap, theme and plugin load | A page cache. The single largest lever on most WordPress sites |
| Plugins doing work on every request | Server | Queries and outbound HTTP calls during init, on every uncached page | Find them with a profiler, remove what earns nothing |
| Database: bloated autoload, repeated queries | Server | The same lookups re-run on every single request | Trim autoloaded options, add a persistent object cache — WordPress’ own object cache is non-persistent by default |
| WP-Cron firing on page load | Server | One unlucky visitor waits for whichever scheduled job was due | DISABLE_WP_CRON in wp-config.php plus a real system scheduler hitting wp-cron.php |
| End-of-life PHP | Server | Slower execution, and no security fixes | PHP 8.3 or greater, which is what WordPress.org recommends |
The WP-Cron row surprises people, so here is the mechanism in the documentation’s own words: “WP-Cron works by checking, on every page load, a list of scheduled tasks to see what needs to be run”, and it “does not run constantly as the system cron does; it is only triggered on page load” (WordPress Developer Resources, verified August 2026). The handbook is blunt about the cost once you have a real scheduler: leaving it on “is no longer necessary and will contribute to extra resource usage on your server”.
The database row has the same shape. WordPress’ object cache is “non-persistent” by default, which means cached data “resides in memory only and only for the duration of the request” and “will not be stored persistently across page loads unless you install a persistent caching plugin” (WordPress Developer Resources, verified August 2026). Every request starts from nothing. That is also why Site Health nags about it.
What each hosting tier actually buys you
No typical millisecond figures here, because the honest answer is that they vary more between two providers in the same tier than between tiers. What does not vary is what you are buying, and which part of TTFB it can and cannot touch.
| Tier | What you are actually buying | What it fixes for TTFB | What it will not fix | When it is the right call |
|---|---|---|---|---|
| Budget shared hosting | A slice of a machine shared with a lot of neighbours | Nothing on its own — this is usually the floor you are trying to leave | Anything, once your traffic outgrows the slice. Response times move with the neighbours | A brochure site with light traffic and a page cache doing the work |
| Managed WordPress hosting | Tuned PHP and database, server-level caching, support who know WordPress | The server phase, mostly by giving you a good cache you did not configure yourself | Distance to your visitors, redirect chains, your own plugin load | Most business sites and small shops. The best value per hour of your time |
| VPS or cloud you tune yourself | Dedicated resources and full control of the stack | The server phase, as far as your configuration skill goes | Nothing you do not configure — an untuned VPS can be slower than good shared hosting | Custom stacks, heavy WooCommerce, someone on the team who runs servers |
| Origin plus edge-cached HTML | Your pages held on servers physically near your visitors | Distance, TLS negotiation and the server phase together, for cached pages | Logged-in users, cart and checkout — those bypass the cache by design | An audience spread across countries, or a content site with stable pages |
| Statically pre-rendered site | HTML files built ahead of time, with no PHP in the request path at all | The server phase, by deleting it | Your publishing workflow, which now runs through a build step | Sites that do not need a CMS in the request path — the reasoning behind our Next.js builds |
Note the fourth row’s limitation, because it catches shop owners out. Edge caching your HTML does impressive things for anonymous visitors and nothing at all for the person holding a cart — which is why a WooCommerce buyer gets the slowest version of the store. If your revenue happens on uncacheable pages, the server phase is not optional and the tier you pick has to be sized for it.
What to do, in order
- Get the field number. PageSpeed Insights shows real-user TTFB alongside the vitals. If it is under 0.8 seconds, close the tab and go and work on something else.
- Split it before you fix it. The network panel in DevTools breaks the navigation request into DNS, connection, TLS and waiting. If “waiting” is small and the rest is not, none of the WordPress advice applies to you.
- Kill the redirect chain. Request your bare domain over http and count the hops to the final URL. Any number above one is free time you are giving away.
- Put a page cache in place and confirm it is actually serving — check the response headers, not the plugin’s dashboard. Then re-measure. Most sites stop here.
- Now look at the server phase properly. Server-Timing headers or a profiler will tell you whether the time is PHP, the database or an outbound call a plugin makes on every request.
- Do the cheap server work: PHP 8.3 or later, autoloaded options trimmed, a persistent object cache, WP-Cron moved to the system scheduler.
- Only now consider moving. If the server phase is still heavy on a tuned, cached site, the machine is the bottleneck and changing host is the correct answer rather than the lazy one. Match the tier to the table above and to where your visitors are.
When it is not worth chasing
If your field TTFB is already under 0.8 seconds, stop. TTFB is not a Core Web Vital, and web.dev says as much: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold” (verified August 2026). It matters as a share of your LCP budget, not as a trophy. Once it is a reasonable fraction of your target, the next 200 milliseconds are worth far less than the render-blocking script you have been ignoring.
And do not buy a bigger server to avoid configuring a cache. This is the expensive version of the same afternoon’s work: a hosting upgrade is a monthly cost that makes PHP faster, where a page cache is a one-off change that stops PHP running. Doing them in that order means paying every month for something you had already fixed. Worth saying too: if your site is slow but your TTFB is fine, moving host will change nothing and you will have spent a weekend proving it.
Where the work does pay: a site failing LCP in Search Console where the field TTFB is eating half the budget, an origin on the wrong continent from its visitors, or a WooCommerce install where the pages that make money are the ones the cache cannot serve. That is what our WordPress speed optimisation work starts from — the split first, the spending last.
Frequently asked questions
What is a good TTFB?
0.8 seconds or less is good and anything over 1.8 seconds is poor, measured at the 75th percentile of real page views (web.dev, verified August 2026). Worth knowing before you panic: TTFB is not itself a Core Web Vital, and web.dev says so directly — it is not absolutely necessary that sites meet the good threshold. Treat it as a budget rather than a grade, because whatever TTFB spends is spent before your Largest Contentful Paint clock has moved at all.
Will a faster host fix my TTFB?
More often than for any other speed metric, yes — TTFB measures your server answering, so the machine genuinely matters. But it is the third move, not the first. If you have no page cache, you are about to pay monthly for a faster machine to run PHP that should never have been run. If your TTFB is going into a redirect chain or the distance between your visitors and your origin, a bigger server in the same data centre changes nothing.
Why does my TTFB look fine in one test and terrible in another?
Three reasons, and they are all real. Lab tools measure from one location, so distance to your origin shows up or does not depending on where the test ran. Some lab measurements exclude the redirect and DNS time that field data includes. And a cached page is a completely different request from an uncached one: with a page cache in place, only the first visitor after each purge pays the full trip back to the origin. Judge with field data, diagnose in the lab.
Does a CDN reduce TTFB?
Only if it caches your HTML. This is the distinction most guides skip. A CDN that serves your images, CSS and JavaScript from the edge does nothing for TTFB, because TTFB is measured on the navigation request — the HTML document — and that request is still travelling all the way to your origin. A CDN that caches and serves the HTML page itself at the edge is a different product, and it is the one that moves the number.
Does WP-Cron slow down my site?
It can, and the mechanism is documented: WP-Cron works by checking, on every page load, a list of scheduled tasks to see what needs to be run, and it is only triggered on page load rather than running constantly like a system cron. Most of the time that check is cheap. The problem is the visitor who happens to arrive when a heavy job is due and ends up waiting for it. Setting DISABLE_WP_CRON and calling wp-cron.php from a real system scheduler moves that cost off your visitors.
Does upgrading PHP reduce TTFB?
It shortens the PHP execution part of the server phase, which is only one slice of one of the five phases, so treat it as a contribution rather than a cure. The stronger reason to do it anyway is that WordPress.org currently recommends PHP 8.3 or greater, and PHP 7.4 and below have reached official end of life — running an unsupported version is a security position, not a performance one.
Sources (verified August 2026): web.dev — Time to First Byte (TTFB); web.dev — Optimize Time to First Byte; WordPress Developer Resources — WP-Cron; WordPress Developer Resources — WP_Object_Cache; WordPress.org — Requirements.