Time to First Byte (TTFB): the clock that runs before your page arrives
Time to First Byte is the clock that starts the instant a visitor clicks your link and stops when the first byte of your HTML arrives — and because it happens before anything is visible, every later loading metric has to wait on it. Google’s guidance is blunt: TTFB precedes every other meaningful loading metric, so a slow first byte caps how fast your page can possibly be. If your server takes 1.2 seconds to answer, your Largest Contentful Paint cannot beat 1.2 seconds no matter how perfectly you’ve compressed images or deferred JavaScript — you cannot optimize your way past a slow server. The bar to clear is 0.8 seconds, with anything over 1.8 counted as poor, but that’s a floor where TTFB is already hurting you, not a target; competitive sites aim under 200 milliseconds. It’s a composite you diagnose, not one thing you fix — DNS, the TCP and TLS handshakes, the network trip, and the server’s own processing time — and the fixes are all server-side, in priority order: hosting, a CDN, caching, removing redirects, and how the HTML is generated. This is where the numbers tell the story: a static page from a CDN edge answers in 80-150ms because there’s no database query or per-visitor computation between the click and the first byte — it clears the bar on day one, where a database-driven site has to earn it.
What exactly is TTFB measuring?
Time to First Byte measures the elapsed time between starting to navigate to a page and when the first byte of the response begins to arrive (web.dev, 2026). It’s not a single number so much as a sum of stages: a DNS lookup to resolve the hostname, the TCP connection and TLS handshake for HTTPS, the server’s own time processing the request and generating the response, and the network round trip carrying that first byte back (Is It Down Checker, 2026). Each stage can slow down independently, which is why TTFB is a metric you diagnose rather than a switch you flip.
Different tools name it differently — Lighthouse calls it “server response time,” Chrome DevTools calls it “waiting for server response” — but the foundational role is the same (DebugBear, 2026). For a navigation request, the request for the HTML document itself, TTFB precedes every other meaningful loading performance metric (web.dev, 2026). It is, quite literally, the first thing that happens when a page loads, and the one thing everything else waits behind.
What’s a good TTFB?
Google’s rough guide puts good TTFB at 0.8 seconds or less, needs-improvement between 0.8 and 1.8 seconds, and poor above 1.8 seconds (web.dev, 2026). But that 0.8-second figure is best understood as a floor rather than a goal — it’s the point where TTFB is actively damaging your Core Web Vitals, and for a comfortable path to a good Largest Contentful Paint at the 75th percentile, you should target under 200 milliseconds (PaidHosting, 2026).
There’s a measurement subtlety worth knowing: Lighthouse’s “server response time” audit uses a stricter 600ms threshold because it measures only the server-processing slice, not the full TTFB including connection setup (OuterBox, 2026). Whichever tool you use, lower is always better, and the gap between a 150ms first byte and a 900ms one is felt directly by every visitor.
Why does one slow number ruin everything downstream?
Because TTFB is foundational: any time added to it is also added to Largest Contentful Paint and First Contentful Paint (corewebvitals.io, 2026). The mechanism is simple. The LCP element — usually your hero image or headline — can’t begin loading until the browser has received the HTML that references it, and that HTML doesn’t arrive until TTFB completes, so a 600ms TTFB means LCP cannot possibly start before 600ms (PaidHosting, 2026).
This is the insight most front-end performance advice misses: you cannot optimize your way past your TTFB. Compressing images, deferring JavaScript and minifying CSS all reduce the time after the first byte arrives, but none of them can reduce the time before it — if your TTFB is 1.2 seconds, your LCP can’t be faster than 1.2 seconds regardless of how optimized your images are (PaidHosting, 2026). A 100ms TTFB leaves 2.4 seconds of budget to reach Google’s 2.5-second LCP threshold; a 900ms TTFB leaves 1.6. Fix the first byte first, then the front end — which is why this sits upstream of the loading metrics in our pillar on Core Web Vitals and site speed.
The realistic benchmark ladder
Abstract thresholds mean less than concrete numbers, and TTFB tracks infrastructure closely enough to tabulate (Is It Down Checker, 2026):
| Setup | Typical TTFB |
|---|---|
| Static page from a CDN edge near the user | 80-150ms (the floor) |
| Database-backed dynamic page, well-tuned origin | 200-400ms |
| Same-region WordPress blog | 300-700ms |
| Cross-continental, database-bound page | 500-1,500ms |
| Cold database queries, several API calls, no caching | 1,500-5,000ms |
The pattern is unmistakable: TTFB rises with the amount of work the server does per request. A cached static file needs almost none; a page assembled from database queries and API calls on every visit needs a great deal (DebugBear, 2026). The ladder is really a ladder of per-request computation.
What causes a slow first byte?
Slow TTFB comes from any of the layers in the chain, which is why diagnosis matters more than a reflex fix (OuterBox, 2026). The largest contributor is usually server processing time — the database lookups, framework rendering and plugin overhead needed to generate a page that wasn’t cached (web.dev, 2026). Physical distance is next and unavoidable: light travels through fiber at roughly 200,000 km per second, so a request from New York to a server in Los Angeles carries a minimum round trip no tuning can remove (InMotion, 2026).
Two subtler causes bite often. Redirects each add a round trip, and redirect chains compound — a particular problem for traffic arriving through analytics redirects from ads and newsletters (web.dev, 2026). And external API calls made while building the initial HTML nest the third party’s own TTFB inside yours, so a slow partner service becomes your slow first byte (DebugBear, 2026). A high TTFB is a sign to investigate why the browser is waiting, not a prescription for a single tool.
How do you fix it, server-side and in order?
Because TTFB is decided before the browser receives anything, the fixes are all server-side, and they sort cleanly by impact: hosting, then a CDN, then caching, then redirects, then how the HTML is generated (Logos Web Designs, 2026). Better hosting comes first because each step from shared to VPS to dedicated typically halves TTFB, and a CDN comes next because it serves content from an edge near the user and can cache the HTML so the origin is never contacted (Is It Down Checker, 2026; web.dev, 2026).
Caching reduces the work the server repeats for every visitor, though cart, checkout and personalized pages often can’t be cached the same way as a static template (OuterBox, 2026). Several connection-level wins stack on top: TLS 1.3 cuts the handshake from two round trips to one, HTTP/3 with QUIC combines connection setup further, Brotli compression shrinks the response, and a fast DNS provider resolves in under 20ms (gf.dev, 2026). What won’t help is any front-end trick — the decision is made before the browser receives a thing, which is why our guides on what a CDN is and web caching do more for TTFB than any amount of image work.
How to measure it properly
Measure with field data first, because it reflects real users and includes delays like redirects that lab tools miss (web.dev, 2026). PageSpeed Insights shows real-user TTFB from the Chrome User Experience Report at the top of its report, and Google Search Console flags slow first bytes as “server response times are slow” alongside your other Core Web Vitals (PaidHosting, 2026). For a single test load, Chrome DevTools’ Network panel and WebPageTest both show it.
Two habits separate a real diagnosis from a misleading one. Test both cached and uncached responses — append a random query string to bypass the CDN cache and measure the true origin time — and test at different times of day, since a server that answers in 100ms at 3am and 900ms at 3pm has a capacity problem (gf.dev, 2026). And read the 75th-percentile distribution rather than the mean, because an average TTFB of 180ms can hide a 75th-percentile of 900ms from occasional slow queries or traffic spikes — and the 75th percentile is exactly what Google measures (PaidHosting, 2026).
Why a static site clears the bar on day one
Everything above points at the same structural answer. Because TTFB is dominated by per-request server work, and a static site pre-builds its HTML during deployment, there’s no database query, no template rendering, and no per-visitor computation between the click and the first byte — the CDN just hands over a file it already holds at an edge node near the user. That produces a TTFB in the 80-150ms range, the floor of the ladder, and clears Google’s 0.8-second bar by default while a database-driven CMS has to fight for it (Logos Web Designs, 2026).
The gain compounds, because a fast first byte is a bigger LCP budget for free. When the HTML arrives in 120ms instead of 900, the browser has almost the full 2.5-second window to load and paint the hero content, which is why static delivery tends to carry good LCP and INP along with it (Logos Web Designs, 2026). It’s the same architecture that makes the site cheap to host and trivial to serve from a CDN — one decision, paying off on the metric that gates all the others.
The honest caveats: TTFB is a diagnosis, not a verdict
Two honest limits keep this from becoming a slogan. First, a strong TTFB doesn’t guarantee good Core Web Vitals — a page can deliver its first byte quickly and still fail Largest Contentful Paint if the LCP image is lazy-loaded, the hero content depends on JavaScript, CSS blocks rendering, or a web font delays the text (OuterBox, 2026). TTFB clears the runway; the front end still has to fly the plane, which is why render-blocking resources matter even on a fast server.
Second, the reverse holds: a page with a mediocre TTFB can still deliver an acceptable experience if the rest of the critical path is lean, so TTFB is best used as one diagnostic signal inside the larger picture rather than a pass-fail verdict (OuterBox, 2026). But the direction is never in doubt: a slow first byte can only hurt, a fast one can only help, and the fastest first byte of all is the one your server never had to compute. That’s the same principle running through the whole performance cornerstone — the fastest work is the work you designed out.
Frequently asked
- What is a good Time to First Byte?
- Google's rough guide is a TTFB of 0.8 seconds (800 milliseconds) or less as 'good', 800ms to 1.8 seconds as 'needs improvement', and anything over 1.8 seconds as 'poor'. But 0.8 seconds is a floor — the point where TTFB is actively hurting your Core Web Vitals — not a target. For a comfortable path to a good Largest Contentful Paint, competitive sites aim for under 200 milliseconds. As a reference, a static page served from a nearby CDN edge answers in about 80-150ms, while a database-backed dynamic page typically lands at 200-400ms and an uncached one much higher.
- Is TTFB a Google ranking factor?
- Not directly — TTFB isn't one of the Core Web Vitals that Google scores, so there's no ranking penalty tied to the metric itself. But it feeds Largest Contentful Paint, which is a ranking signal, and a slow TTFB makes a good LCP nearly impossible to achieve. If your server takes a second to send the first byte, LCP cannot fire before that second, no matter how optimized your front end is. So TTFB affects rankings indirectly, through the loading metrics it gates, and Google has confirmed that server response time affects search rankings.
- How do I reduce my TTFB?
- TTFB is decided on the server side, so front-end fixes like compressing images or deferring JavaScript won't help — those only affect the time after the first byte arrives. The five biggest levers, in priority order, are: better hosting (each step from shared to VPS to dedicated typically halves TTFB), a CDN to serve content from an edge near the user, caching so the server doesn't regenerate pages per request, removing redirects, and changing how the HTML is generated — often by moving to pre-built static output. Start by diagnosing which layer owns the delay before changing anything.
- Why does my TTFB affect my LCP score?
- Because TTFB is foundational — it precedes every other loading metric, so any time spent waiting for the first byte is time added to Largest Contentful Paint and First Contentful Paint. The LCP element, usually your hero image or headline, can't begin loading until the browser has received the HTML that references it, and that HTML doesn't arrive until TTFB completes. A 600ms TTFB means LCP cannot possibly start before 600ms, leaving a lean budget to reach Google's 2.5-second 'good' threshold. You cannot optimize your way past a slow server.
- Why do static sites have such low TTFB?
- Because TTFB is dominated by the work the server does per request, and a static site does almost none. Its HTML is pre-built during deployment, so when a visitor arrives there's no database query, no template rendering, and no per-visitor computation between the click and the first byte — a CDN simply hands over a file it already has, cached at an edge node near the user. That produces TTFB in the 80-150ms range, clearing Google's 0.8-second bar on day one, whereas a database-driven CMS has to fight for it with caching layers and server tuning.