> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Server Speed Over Time, Website Performance (PageSpeed + CrUX) > Server Speed Over Time for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how t... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## At a glance > **Time to First Byte p75 over time**, daily time-series of mobile TTFB from CrUX. Pairs with [`crux_ttfb_p75`](/nerve-centre/kpi-cards/website-performance/server-response-time) 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`](/nerve-centre/kpi-cards/website-performance/server-response-time). | | **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"** | What the trend is telling us: 1. **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**. 2. **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**. 3. **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. 4. **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 days` alert would have fired then. 5. **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. The diagnostic flow: 1. **Cross-reference TTFB inflection with CDN cache hit rate trend.** Most TTFB regressions trace to cache configuration changes. 2. **Check origin response time during the inflection window.** If origin is also slow, backend / database is the issue. 3. **Verify CDN POP coverage matches user geography.** Geographic mix shifts can cause TTFB to rise without server changes. Rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/server-response-time) | Static TTFB snapshot. | | [`psi_server_response`](/nerve-centre/kpi-cards/website-performance/server-response-time) | Lab TTFB measurement. | | [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time) | TTFB regressions cascade into LCP. | | [`crux_fcp_trend`](/nerve-centre/kpi-cards/website-performance/first-content-over-time) | TTFB regressions cascade into FCP. | | [`crux_pass_rate_trend`](/nerve-centre/kpi-cards/website-performance/speed-test-pass-rate-over-time) | Pass rate trend; TTFB indirectly affects via LCP. | | [`psi_caching_opportunities`](/nerve-centre/kpi-cards/website-performance/caching-opportunities) | Caching is the primary TTFB lever. | | [`crux_regression_timeline`](/nerve-centre/kpi-cards/website-performance/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. **Why the Vortex IQ TTFB trend may differ from CDN dashboard:** | 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. | **Cross-connector reconciliation:** primarily internal (with [`crux_ttfb_p75`](/nerve-centre/kpi-cards/website-performance/server-response-time), [`psi_server_response`](/nerve-centre/kpi-cards/website-performance/server-response-time), [`psi_caching_opportunities`](/nerve-centre/kpi-cards/website-performance/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. *** ### Tracked live in Vortex IQ Nerve Centre *Server Speed Over Time* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.