TTFB: what a good time to first byte looks like, and how to get there
Time to First Byte is the wait before your server says anything at all, and it sets the ceiling for everything after it. What good looks like, and how to find which part of yours is slow.
TTFB is the time between the browser sending a request and receiving the first byte of the response. Under 200ms is good, 200–600ms is workable, over 600ms is a problem. It is made of four separable parts — DNS, connection setup, network travel, and server processing — and improving it starts with working out which of the four is eating your budget.
Time to First Byte is the quietest performance metric and one of the most consequential, because nothing else can start until it finishes. The browser cannot parse HTML it does not have, cannot discover the stylesheet referenced inside it, cannot begin fetching the hero image. A slow TTFB makes the entire page late regardless of how well everything downstream is optimised.
It is also frequently misdiagnosed, because "TTFB is 900ms" is a symptom with at least four different diseases.
The four things hiding inside one number
In your browser's Network tab, click any request and open the Timing panel. You will see the breakdown that the single TTFB number hides:
- DNS lookup — turning your hostname into an IP address. Usually 0 to 50ms, and zero on repeat visits. If it is consistently high, your DNS provider is slow or your TTL is too short.
- Initial connection and TLS — the handshakes. Two to three round trips over TCP, one over QUIC. Scales directly with distance, and this is the part terminating TLS at a nearby edge eliminates.
- Request travel — getting your request to the server that will answer it.
- Waiting (TTFB proper) — the server actually doing the work. This is the part Chrome labels "Waiting for server response", and on a slow dynamic site it is the whole story.
Diagnosing is a matter of looking at which bar is longest. If "Waiting" is 700ms and everything else is 40ms, no CDN configuration will save you — your application is slow and that is where the work is. If "Waiting" is 40ms and the connection phases are 600ms, your application is fine and you have a geography problem.
What counts as good
An important caveat about those thresholds: they are only meaningful alongside the location they were measured from. A 150ms TTFB from your office in the same city as your server can be 800ms for a customer in São Paulo, and the São Paulo number is the one affecting your revenue. Always test from at least three regions where you actually have visitors.
TTFB is not a Core Web Vital
Worth stating clearly, because it causes confusion. Google does not rank on TTFB directly — it ranks on Largest Contentful Paint, and TTFB is a component of it. That does not make TTFB unimportant; it makes it a leading indicator. Every millisecond of TTFB is a millisecond LCP cannot recover, so a site with a 900ms TTFB has spent more than a third of its 2.5-second LCP budget before the browser has seen a single tag.
Fixing each cause
| Symptom in the Timing panel | Cause | Fix |
|---|---|---|
| Long "Waiting", short everything else | Slow server-side render | Cache the finished page; profile the slow query |
| Long connection/TLS, short "Waiting" | Origin far from visitor | Terminate TLS and serve from a nearby edge |
| Fast locally, slow from abroad | Single-region origin | Cache at edges near your actual audience |
| Fast on second load, slow on first | Cache misses | Raise cache hit ratio; pre-warm after purges |
| Consistently high DNS | Slow resolver or short TTL | Anycast DNS; raise TTL on stable records |
| Erratic, spikes under load | Origin capacity | Offload to cache so the origin sees less |
Notice the pattern across most of those rows: the fix is "stop doing the slow thing on every request". A cached page served from a nearby edge skips the long-distance handshake, the application render and the database entirely — which is why caching does more for TTFB than anything else available to you.
One trap worth naming: a CDN in front of an uncacheable page makes TTFB slightly worse, not better, because you have added a hop. If a page carries Cache-Control: no-store the edge must forward every request to your origin and relay the answer. When someone reports that a CDN made their site slower, this is nearly always what happened — and the fix is to make the page cacheable, not to remove the CDN.
A five-minute diagnosis
Measure from three regions
Your own location plus two places you have real visitors. Note the spread, not just the best number.
Open the Timing panel on the HTML request
Not on an asset — on the document itself. Identify the longest bar.
Load the same page twice
If the second load is dramatically faster, you were measuring a cache miss and your problem is hit ratio, not raw speed.
Compare edge and origin directly
Request the page through the CDN and then straight from your origin hostname. The difference tells you how much the edge is contributing — and whether it is contributing at all.
Frequently asked questions
What is a good TTFB?
Under 200 milliseconds is good and feels instant, 200 to 600 milliseconds is acceptable with room to improve, and above 600 milliseconds is slow enough that visitors notice. These figures only mean something in combination with where the measurement was taken — a good TTFB from your own city can be poor for visitors on another continent, so test from the regions your audience is actually in.
What causes a slow TTFB?
Four things, and the browser's Timing panel will tell you which. Slow server-side processing shows as a long "Waiting" phase; physical distance to the origin shows as long connection and TLS phases; cache misses show as a slow first load and a fast second one; and DNS problems show as a consistently high lookup time. Each has a different fix, so identifying which one dominates comes before any change.
Is TTFB a Core Web Vital?
No. Google's Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. TTFB is not ranked directly, but it is a component of LCP — every millisecond spent waiting for the first byte is a millisecond LCP cannot get back, so a high TTFB caps how good your LCP can be.
Does a CDN improve TTFB?
Substantially, for cacheable content. A cached page is served from an edge near the visitor, which removes the long-distance handshake, the application render and the database work in one go. For uncacheable pages a CDN slightly increases TTFB by adding a hop, so if a page sends no-store the fix is to make it cacheable rather than to remove the CDN.
How do I measure TTFB?
In Chrome DevTools, open the Network tab, click the document request, and read the Timing panel, which separates DNS, connection, TLS, request and waiting time. For a quick command-line check use curl with a write-out format printing time_starttransfer. To see what real visitors experience rather than what you experience, use a synthetic testing service that measures from multiple regions, or real-user monitoring.
TTFB caps your whole page's speed, so aim for under 200ms — but measure it from where your visitors are, and split it into its parts before changing anything. If "Waiting" dominates, fix your application or cache the page. If connection time dominates, move the response closer. Fixing the wrong one is the most common way to spend a week and gain nothing.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
