Where the Milliseconds Go: Building Toward a 200ms TTFB
Imagine a performance review where the target is 200ms, field TTFB is 940ms, and Lighthouse reports a 380ms server response. Before choosing a fix, the team needs to establish where the target came from and whether the two measurements cover the same conditions and timing interval.
Time to first byte spans several stages of a page request, so improving it starts with finding where the delay occurs. Google describes 800ms or less as good TTFB, rather than a failure line. For cacheable public pages, 200ms can be a useful stretch target that prompts an earlier discussion about how HTML reaches the user.
The 200ms Target Is Not Google’s Number
Start with the provenance, because the figure gets quoted as though Google published it last week.
The 200ms recommendation comes from the PageSpeed Insights v4 API documentation, which Google retired in 2019. It was a real Google recommendation once. It has not been current guidance for years, and any vendor presenting it as today’s standard is working from a deprecated doc.
What Google publishes now is three numbers that measure three different things, which is most of the reason teams talk past each other in performance reviews.
| Number | Source | What it measures | What it is for |
|---|---|---|---|
| 800ms | web.dev TTFB guidance, 75th percentile of real users | Full TTFB including redirects and DNS | The point where server response is actively damaging your Core Web Vitals |
| 600ms | Lighthouse server response time audit | Server response only, excluding DNS and redirect time | A lab pass or fail flag, folded into the Document request latency insight in Lighthouse 13 |
| 200ms | PageSpeed Insights v4 docs, deprecated 2019 | Server response time | Historical only |
Two things follow, and the second matters more.
First, TTFB is not a Core Web Vital. The Core Web Vitals are LCP, INP, and CLS. Time to first byte is a diagnostic metric, and Google’s own guidance says sites do not strictly need to hit the good threshold. Anyone calling TTFB a ranking factor is wrong.
Second, 800ms is a failure line rather than a goal. It marks the point where server response has begun to cap what your LCP can ever be. Set your target at the failure line and every regression ships to production before anyone notices, because there is no headroom between where you are and where you break.
So keep 200ms. Not as a pass or fail gate, but because it is the only target on that list you cannot reach by tuning. You can get to 600ms with a faster query and a bigger instance. You cannot get to 200ms without deciding how your HTML is served, which is the decision most performance programs avoid making.
Where the Milliseconds Actually Go
TTFB is the sum of redirect time, service worker startup where one exists, DNS lookup, connection and TLS negotiation, and the request itself up to the arrival of the first byte. Five waits, different owners.
| Component | What usually causes the delay | Where it is fixed | Visible in the Lighthouse server response audit |
|---|---|---|---|
| Redirects | HTTP to HTTPS, missing trailing slash, www normalization, legacy URL maps chained two or three deep | Edge rules, HSTS preload, a flattened redirect map | No |
| DNS lookup | Cold resolution against a distant or slow authoritative nameserver | DNS hosted on your CDN’s network | No |
| Connection and TLS | Round trips to a single origin region, older TLS versions, no connection reuse | CDN edge termination, TLS 1.3, HTTP/2 or HTTP/3 | No |
| Request and server think time | Per-request rendering, uncached CMS API calls, cold serverless functions, database work | Application and caching architecture | Yes |
| Service worker startup | A worker that must boot before it can respond | Worker strategy, or removal from the critical path | No |
The legacy server response audit covers a narrower interval than full navigation TTFB. That distinction can explain part of a lab-to-field gap, but the current Document request latency insight also checks redirects and compression. Use the request waterfall to inspect the delivery stages individually.
A lab test represents one location, configuration, and moment in time. Field data reflects actual users across different networks and locations. Tests that start at the final URL can miss redirects, while cache behavior can also change the result. Neither cold DNS nor a particular redirect sequence should be assumed without inspecting the trace.
When field TTFB is worse, investigate network conditions, redirects, and server-side caching before assigning a cause. Then check application traces for differences in rendering and upstream requests. One fast lab response does not establish how the application behaves across production traffic.
How HTML Delivery Changes the TTFB Budget
A useful architectural question is whether the request can reuse prepared HTML or must generate a response. Location, upstream dependencies, and cache behavior determine how much work remains before the first byte reaches the user.
| Delivery model | What happens on request | Realistic TTFB | What breaks it |
|---|---|---|---|
| HTML cached at the CDN edge | Edge returns a stored response | Tens of milliseconds | Any per-request personalization inside the HTML |
| HTML rendered at the edge | Code runs close to the user, no origin hop for cached data | Low hundreds of milliseconds | Uncached upstream API calls |
| Server-side rendered at a single origin | Full round trip to one region, then render | 300ms and up, worse by distance | Distance, cold starts, CMS API latency |
| Rendered per request with live CMS calls | Round trip, then one or more content API calls, then render | Frequently past 800ms | Everything above, compounded |
The important distinction is the work each request must perform. Reusing HTML at the edge can remove an origin round trip, while dynamic rendering can remain fast when the necessary work and data are nearby. Measure representative requests rather than assigning a guaranteed TTFB to a delivery model.
A headless CMS gives teams more freedom to choose how content reaches the browser. Public pages can be generated ahead of requests or updated through incremental regeneration, reducing routine dependence on live content API calls. Dynamic sections can use a separate delivery strategy. That flexibility is valuable when publishing workflows, content freshness, and caching are designed together. The CMS alone does not guarantee faster TTFB, but a well-implemented headless architecture makes those delivery choices explicit.
For frequently requested public pages, HTML caching can remove substantial repeated work. Where personalization affects only part of the page, consider caching a shared document and delivering those regions separately. Keep user-specific content out of shared responses unless cache isolation is explicitly designed. Stale-while-revalidate can serve an existing response during its permitted stale window; cache misses and expired windows can still require a fresh response. Test the full experience, including any delay introduced by client-side personalization.
Global delivery makes location an important part of the performance plan. Contentful’s published case study describes eight25 helping Qlik move from Sitecore XP to Contentful in under five months, with faster publishing and easier content reuse afterward. That establishes enterprise migration experience; it does not establish a particular TTFB result. For global sites, measure key regions separately and ensure the CDN delivery strategy covers HTML as well as assets. An HTML cache hit can avoid a trip to the origin, while an uncached response may still depend on it.
Choose optimizations around the measured bottleneck rather than treating web.dev’s recommendations as a fixed sequence. Hosting, CDN delivery, caching, redirects, streaming, and 103 Early Hints address different delays. Early Hints can start critical resource downloads while HTML is prepared. They can also lower reported TTFB when the tool counts the interim response as the first byte, so measure final-response timing and LCP alongside it.
What TTFB Means for LCP, Crawling, and AI Retrieval
Three arguments get made for fixing time to first byte. Two are documented. The third is the one being sold hardest.
TTFB is the first phase in the standard LCP breakdown, followed by resource load delay, resource load duration, and element render delay. In the 2025 Web Almanac’s mobile data, 77% of sites achieved good INP and 81% good CLS, compared with 62% for LCP. Good TTFB stood at 44%, while 17% was poor. These figures support examining delivery latency early, but an individual site’s LCP breakdown should determine whether to prioritize TTFB, resource loading, or rendering.
Google documents response speed and server health as factors in crawl capacity. Slower responses and server errors can reduce capacity; healthy responses can support more connections when crawl demand exists. This matters for large or frequently changing sites, but page count alone does not establish a crawl-budget problem. Check crawl statistics and indexing behavior before presenting faster TTFB as a way to accelerate discovery.
AI retrieval needs a separate distinction between training crawlers, search indexing, and user-triggered fetches. OpenAI and Anthropic document different agents for these purposes. The public documentation reviewed does not establish a universal one-to-five-second timeout or a no-retry policy. Treat those figures as unverified unless supported by documentation for the specific agent.
| Claim | Status | What to do about it |
|---|---|---|
| Slow TTFB reduces how much Google crawls | Documented in Google’s crawl budget guidance | Treat as a real, named consequence |
| TTFB sets the floor for LCP | Definitional | Fix server response before optimizing LCP images |
| TTFB is a Google ranking factor | No | Stop presenting it as one |
| AI crawlers time out after 1 to 5 seconds | Not published by any AI vendor | Do not build a business case on the number |
| Slow pages hurt live AI retrieval | Directionally sound, unquantified | Treat as risk management, not as a forecast |
When an assistant fetches a page during a user request, delivery latency can contribute to the wait. Cached content and parallel retrieval can change that relationship, so TTFB alone does not predict answer speed or citation likelihood. The practical recommendation is reliable access and responsive delivery, without assigning an unsupported visibility uplift.
Where Migrations Quietly Spend the Budget
Performance regressions rarely arrive as a performance decision. They arrive as five ordinary delivery choices nobody costed in milliseconds.
Redirect chains at cutover. Map legacy URLs directly to their final destinations wherever possible, and test the map before and after launch. eight25’s published NetApp account describes an initial estimate of 40,000 pages, an audit-stage estimate near 12,000, and roughly 14,000 pages at launch. A pre-cutover review identified 741 already-resolved redirects. That illustrates the value of a current URL inventory; redirect count alone does not establish chain depth or latency.
Production caching left unverified. A CDN can serve assets while HTML remains uncached. Check production cache rules, response headers, and HTML cache status rather than assuming the CDN caches the document. A low hit ratio needs investigation because intentional bypasses, cache keys, and traffic patterns can also explain it.
Content API calls left on the request path. Inspect which requests must complete before HTML can be sent. A single slow request can dominate the wait, while independent requests may run in parallel. Reuse content where appropriate and measure dependency timing before attributing the delay to the CMS.
Preview behavior leaking into public delivery. Editorial preview can legitimately run on production infrastructure, but it should require appropriate authorization. Verify that public requests receive published content and that preview cookies or parameters do not unintentionally bypass caching for ordinary visitors.
No performance budget in the acceptance criteria. Set measurable budgets for representative templates, regions, and delivery states before launch, then validate them against real-user data afterward. A new site’s production field performance cannot be fully established in advance. For a headless migration, the acceptance plan should cover HTML caching, content freshness, preview isolation, and dynamic rendering alongside TTFB and LCP.
Getting to 200ms, In Order
The order matters more than the list, because each step changes what the next measurement means.
- Establish the baseline. Use real-user monitoring to compare the 75th percentile by region and template, with lab tests for diagnosis.
- Inspect the delivery path. Test actual entry URLs and record redirects, DNS, connection setup, and response wait.
- Remove unnecessary redirects. Prefer direct HTTPS links and final destinations. HSTS preload can avoid HTTP upgrade redirects in supporting browsers, but requires a separate suitability review.
- Check HTML caching. Measure hits, misses, bypasses, and revalidation separately from asset caching.
- Design content freshness. For a headless CMS, decide which pages are pre-rendered, how publishing updates them, and which sections genuinely need dynamic delivery.
- Trace backend work. Use application traces or Server-Timing to identify rendering, database, and content API delays. Prioritize whichever measured component offers the largest useful improvement.
A site that completes steps one through five and still cannot get under 200ms has a genuine architectural constraint worth documenting. A site that starts at step six, which is where most programs start, spends a quarter hunting a hundred milliseconds inside a budget that was blown before the server received the request.
Where This Leaves Your Performance Program
A useful performance target makes delivery decisions explicit. For a headless CMS, that means choosing which pages can be prepared ahead of requests, how publishing updates cached content, and where dynamic rendering is necessary. The benefit is control over the request path, with performance verified against the users and pages that matter.
If you are planning a replatform, settle those choices before the build. eight25’s documented work moving Qlik to Contentful and NetApp to Contentstack provides relevant enterprise migration experience. Bring HTML delivery, caching, and regional measurement into the scope early, so performance is part of the implementation brief.
Frequently Asked Questions
What is a good TTFB in 2026?
Google describes 800ms or less as good TTFB and above 1.8 seconds as poor. The historical 200ms recommendation came from deprecated PageSpeed Insights guidance. Use any stricter internal target with a clearly defined measurement scope.
Is TTFB a Google ranking factor?
TTFB is not a Core Web Vital or an independently identified ranking signal in the guidance reviewed. It contributes to LCP, while response speed also affects crawl capacity. Neither relationship guarantees a ranking improvement.
Why does my TTFB pass in Lighthouse but fail in field data?
First check whether you are comparing full navigation TTFB with the narrower server response measurement. Lab and field conditions also differ by location, network, redirects, and caching. Investigate production requests before ruling out backend causes.
Does a headless CMS automatically improve TTFB?
Not automatically. Headless CMS gives teams flexibility to pre-render public pages, regenerate them as content changes, and handle dynamic sections separately. Performance depends on how those choices are implemented and measured.
Can a personalized page get under 200ms?
Potentially. A shared document with separately delivered personalized regions is one option; efficient dynamic rendering is another. User-specific content needs appropriate cache isolation. Measure personalization’s effect on LCP and visible content as well as TTFB.
Does slow TTFB hurt AI search visibility?
Slow delivery can delay a live fetch, but TTFB alone does not establish AI search visibility or citation likelihood. The documentation reviewed does not support a universal one-to-five-second timeout. Focus on reliable access and responsive delivery, and treat visibility gains as unproven.