At a glance
Time to First Byte p75 over time, daily time-series of mobile TTFB from CrUX. Pairs with crux_ttfb_p75 snapshot. The most infrastructure-driven CWV trend, TTFB regressions almost always trace to server, CDN, or origin configuration changes rather than front-end code. The leading indicator for FCP and LCP regressions because TTFB is upstream of both. A TTFB regression that goes uncaught becomes an LCP regression 7-14 days later as the rolling window absorbs.
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile TTFB trend over 6 months ending Wednesday 15 May 26.
What the trend is telling us:
- The Mar 26 BFCM-prep change is the dominant cause. A dynamic-pricing widget added to the homepage and PDPs disabled CDN caching for those pages (because price varies per session). Cache hit rate dropped from 64% to 45% overnight; TTFB jumped 260ms. The change was intentional but the cache impact was unintentional.
- Post-BFCM, the configuration was never rolled back. The dynamic-pricing widget remained on pages that no longer needed it. Cache hit rate stayed at 42%, dragging TTFB up permanently. A 6-week-old config decision is still affecting current performance.
- The recovery path is clean and fast: identify which pages have dynamic pricing actively in use today (probably none post-BFCM), restore aggressive CDN caching for the rest. Estimated post-fix: cache hit rate back to 75-80%, TTFB drops to 600-700ms.
-
The TTFB → FCP → LCP cascade is visible across cards: TTFB rose first in Mar 26, FCP rose visibly in Mar-Apr, LCP rose in Apr-May. Catching the TTFB regression in Mar 26 would have prevented the cascade entirely; a
+200ms TTFB delta over 7 daysalert would have fired then. - The 42% cache hit rate is dragging every cold-cache visitor’s TTFB to ~1,400ms while warm-cache visitors get ~250ms. The 3-4x penalty for cold visitors is what’s structuring the 1,180ms p75. Lifting cache hit rate is the single highest-leverage TTFB fix.
- Cross-reference TTFB inflection with CDN cache hit rate trend. Most TTFB regressions trace to cache configuration changes.
- Check origin response time during the inflection window. If origin is also slow, backend / database is the issue.
- Verify CDN POP coverage matches user geography. Geographic mix shifts can cause TTFB to rise without server changes.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- CrUX BigQuery, historical TTFB data.
- CDN dashboard, origin response time + cache hit rate trends.
- APM tools (Datadog, New Relic), server-side timing breakdowns.
Cross-connector reconciliation: primarily internal (with
crux_ttfb_p75, psi_server_response, psi_caching_opportunities).
Quick rule for support tickets: if a merchant says “TTFB regressed but origin response time is steady”, the cause is CDN cache hit rate degradation. Check CDN dashboard cache hit rate trend.
Known limitations / merchant FAQs
Why is TTFB the most important trend to monitor? Because TTFB is upstream of every other CWV. A TTFB regression cascades into FCP and LCP regressions over the following 1-2 weeks. Catching TTFB drift early prevents the cascade. Set the alert threshold tight (+200ms over 7 days), TTFB drift is rarely noise, almost always traceable to a specific infrastructure change.
My TTFB regressed but my origin server response time is fine. What’s wrong?
CDN cache hit rate degradation. The origin is fast for cache-miss visitors but cache-hit visitors are now hitting origin instead of edge. Check CDN dashboard cache hit rate trend; the inflection should match TTFB regression date.
Should I alert on TTFB or just on LCP?
Both. TTFB alert catches infrastructure regressions early; LCP alert catches the cascaded ranking-impact failure. TTFB is the early-warning signal; LCP is the truth-source for ranking.
Why does TTFB take 28 days to fully reflect a fix?
Same as all CrUX metrics, the rolling-window methodology smooths step changes. Fix today → 7-day rolling shows partial movement → 14-day substantial → 28-day fully reflected.