Time to First Byte gets mentioned constantly in speed audits and rarely explained properly. It’s the number that shows up in every PageSpeed report, every hosting sales page, and every “why is my site slow” conversation, but most explanations stop at the definition without saying what a realistic target actually looks like, or what’s genuinely driving a bad number. Here’s the fuller picture.
What TTFB actually measures
Time to First Byte is the time between the browser requesting a page and receiving the very first byte of the response back from the server. It’s measured in milliseconds, and it isn’t one number so much as the sum of several stages happening in sequence: resolving the domain’s DNS, completing the TCP handshake, negotiating TLS encryption for HTTPS, the request physically traveling to the server, the server actually generating the response running application logic, querying the database, rendering the page and finally that first byte landing back in the browser. A slowdown at any one of those stages adds directly to the final TTFB number, which is why fixing it requires knowing which stage is actually the bottleneck rather than assuming it’s always “the server.”
Why TTFB matters even though it isn’t a Core Web Vital
This trips people up constantly: TTFB is not one of Google’s three official Core Web Vitals. Those are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. But TTFB is what those metrics are built on top of, particularly LCP. The browser literally cannot begin rendering anything including the largest visible element that LCP measures — until that first byte arrives. A slow TTFB puts a hard floor under how good your LCP can possibly be, no matter how well-optimized the rest of the page is. Sites with poor LCP scores spend an average of 2.27 seconds on TTFB alone, which by itself consumes nearly the entire 2.5-second budget LCP is allowed before the browser has even started painting anything to the screen. Fixing TTFB is frequently the single highest-leverage change available for a site with a poor LCP score, because every improvement to it passes straight through to the metric Google actually uses in ranking.
What counts as good in 2026
Google’s threshold puts a TTFB of 800 milliseconds or less, measured at the 75th percentile of real user data, in the “good” category, with anything above 1.8 seconds landing in “poor” and the range between counted as “needs improvement.” Real field data backs up how meaningful that gap is in practice: across roughly 190,000 sites measured on desktop in the second quarter of 2026, 63% scored good on TTFB, with a typical site’s TTFB sitting around 596 milliseconds — but the worst 10% of sites were above 1.8 seconds, and the worst 1% were above 4 seconds, more than six times the typical site’s response time. That long tail is doing a lot of damage to a small number of sites while the majority cluster in a reasonably healthy range, which tells you something important: a bad TTFB is very rarely “normal variation.” It’s usually a specific, fixable problem.
The three things actually driving your number
It helps to separate TTFB into what’s actually controllable, because the three components behave very differently.
Connection setup — the DNS lookup plus TCP and TLS handshakes happens once per new connection and is largely a function of your DNS provider and whether modern protocols like HTTP/2 or HTTP/3 are enabled, which allow connection reuse rather than paying that setup cost repeatedly. Most reasonably configured hosts and CDNs handle this well by default, so it’s rarely the biggest lever available.
Network latency — the physical round-trip distance between the visitor and wherever your server actually sits — is pure geography, and it’s the part a CDN addresses directly by serving cached content from an edge location physically closer to the visitor rather than routing every request back to a single distant origin server.
Server processing — the actual work of generating the response, including database queries and application logic — is the component most within your direct control, and it’s usually where the biggest, cheapest wins live. An uncached dynamic page that rebuilds itself from scratch on every request, a database query running without a proper index, or an application layer doing more work than necessary before it can respond are the most common causes of server-processing time dominating the TTFB number.
What actually fixes it
Server-side caching is usually the single biggest win available, since caching a dynamic page’s output in something like Redis or Varnish can strip hundreds of milliseconds off processing time that would otherwise be spent regenerating the same content for every visitor. A CDN addresses the network latency component directly by handling DNS, TCP, TLS, and content delivery from a location physically closer to the visitor rather than a single origin server. Confirming HTTP/2 or HTTP/3 is actually enabled most CDNs and modern hosting turn this on by default, but it’s worth verifying rather than assuming reduces the connection-setup cost for repeat requests. And for sites where slow database queries are the real bottleneck, the fix isn’t caching at all, it’s identifying and indexing the specific queries doing unnecessary work, since caching a symptom doesn’t fix a query that will still be slow the moment the cache expires.
What this means practically
If a speed audit flags TTFB as a problem, the fix almost never lives in the frontend no amount of image compression or JavaScript minification moves this number, because none of that code runs until after the first byte has already arrived. TTFB is entirely a server, database, and network problem, which makes it as much a hosting and infrastructure question as it is a development one. A host running on outdated hardware, without server-side caching enabled by default, or without a CDN integration, puts every site on it at a structural disadvantage before a single line of frontend code gets touched and it’s exactly the kind of underlying cause that’s easy to blame on “the CMS” when the actual bottleneck was never in your control to begin with.
