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.
| What it counts | Time-series of experimental_time_to_first_byte p75 across the rolling 28-day CrUX window. Each daily data point reflects the trailing 28 days of real-user TTFB measurements. |
| Sample type | Field data sourced from CrUX. Lab equivalent: psi_server_response. |
| Why TTFB drift matters as an early warning | TTFB rises typically precede FCP rises (which precede LCP rises) by 1-2 weeks because the rolling-window absorption is staggered. A TTFB alert at +200ms catches infrastructure regressions before they cascade into ranking-impact CWV failures. |
| Common TTFB drift patterns | (1) CDN cache hit rate degradation: cache configuration drift, new dynamic content disabling cache, geographic POP changes. (2) Origin server slowness: backend code changes, database query degradation, scaling issues during traffic peaks. (3) CDN POP changes: vendor moves your traffic to different POPs without notification. (4) Geography mix shifts: marketing campaigns drawing more traffic from far-from-origin regions. |
| Sample size threshold | CrUX requires sufficient real-user volume (~1,000+ sessions per 28 days). |
| Currency | n/a, time-series of milliseconds. |
| Time window | 28D rolling × T |
| Alert trigger | current value > 800ms OR 7-day rolling delta > +200ms (regression). |
| Sentiment key | psi_ttfb |
| Roles | owner, operations |
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.| Month | TTFB p75 | Δ vs prior | CDN cache hit rate | Notes |
|---|---|---|---|---|
| Nov 25 | 580ms | (baseline) | 78% | Healthy |
| Dec 25 | 600ms | +20ms | 76% | Stable |
| Jan 26 | 720ms | +120ms | 68% | Cache hit rate drift starts |
| Feb 26 | 760ms | +40ms | 64% | Continued cache drift |
| Mar 26 | 1,020ms | +260ms | 45% | Sharp drop: BFCM dynamic-pricing widget disabled cache for many pages |
| Apr 26 | 1,140ms | +120ms | 42% | Persisted post-BFCM (config not rolled back) |
| May 26 | 1,180ms | +40ms | 42% | Current state, “needs improvement” |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Check CDN cache hit rate trend; identify when it dropped. |
| First 4 hours | Restore aggressive caching for previously-cached templates. |
| Day 7 | TTFB partial recovery as 28-day window absorbs. |
| Day 28 | Field TTFB fully reflects fix; FCP and LCP follow. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_ttfb_p75 | Static TTFB snapshot. |
psi_server_response | Lab TTFB measurement. |
crux_lcp_trend | TTFB regressions cascade into LCP. |
crux_fcp_trend | TTFB regressions cascade into FCP. |
crux_pass_rate_trend | Pass rate trend; TTFB indirectly affects via LCP. |
psi_caching_opportunities | Caching is the primary TTFB lever. |
crux_regression_timeline | Composite regression detection. |
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.
| Reason | Direction | What to do |
|---|---|---|
| TTFB definition. CrUX includes DNS + TCP + TLS + server time; CDN dashboards typically measure server-only. | CrUX higher | Use CrUX for user-perception decisions; CDN for backend optimisation. |
| Window timing. | Vortex IQ lags 1-2 days | Wait for refresh. |
| Smoothing. Each daily point is 28-day rolling. | Smoothed | Step regressions appear gradual. |
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.