At a glance
Server response time (Time to First Byte) for the audited URL, measured from the moment the browser sends the HTTP request to when the first byte of the response arrives. Everything else in the page-load timeline waits for TTFB to complete. A 1,200ms TTFB means LCP cannot be faster than 1,200ms regardless of how optimised the front-end is. Healthy ecommerce sites run TTFB under 600ms; over 1,000ms is “slow”; over 1,800ms is “poor” and structurally limits all CWV improvements.
| What it counts | The duration from the browser’s HTTP request being sent to the first byte of the HTTP response being received. Includes: DNS lookup time, TCP handshake, TLS handshake, server processing time, network transit time. Server processing time is typically the dominant component; the others are network-layer and largely fixed per geography. |
| Sample type | Lab data from Lighthouse audit (single synthetic measurement). Field equivalent: crux_ttfb_p75. |
| Lighthouse scoring thresholds | Good: < 800ms (passes Lighthouse audit). Needs improvement: 800-1,800ms. Poor: > 1,800ms. The CrUX field-data thresholds are stricter: good < 800ms (same), poor > 1,800ms (same), but the ranking-impact CWV doesn’t include TTFB directly, it’s a CWV input via LCP. |
| What drives slow TTFB | (1) Slow server response: PHP rendering on Stencil, slow database queries, uncached pages. (2) Cold cache at CDN edge: cache miss forces request to origin which is slower. (3) Geographic distance: server in US, user in UK = 100-200ms baseline RTT. (4) TLS handshake: HTTP/2 + TLS 1.3 reduces this; older configurations add 100-300ms. (5) Heavy backend logic: dynamic personalisation, A/B test variant selection, complex catalog queries. |
| Common ecommerce patterns | (1) BC Stencil sites typically run TTFB at 400-800ms with healthy cache hit rates, 1,000-2,000ms on cache-miss or origin-pull. (2) Catalyst sites (BC’s Next.js stack) typically run faster (200-500ms) due to edge-rendering. (3) Custom-platformed sites vary widely; Magento/Adobe Commerce often runs 800-1,500ms TTFB without aggressive caching. |
| Optimisation playbook | (1) CDN caching: cache full pages at the edge for cold visitors (no cookies, no personalisation). Drops TTFB to 50-200ms for cached pages. (2) HTTP/2 + TLS 1.3: reduces handshake overhead by 50-150ms. (3) Edge functions / SSR: render dynamic content at edge POPs near the user. (4) Database query optimisation: index missing fields, eliminate N+1 query patterns. (5) Application-level caching: Redis/Memcached for product data, session state. |
| Why this card matters as a leading indicator | TTFB is upstream of every other front-end metric. Brands optimising LCP without checking TTFB hit a ceiling: even with perfect image optimisation and zero render-blocking resources, LCP cannot be faster than TTFB. Always confirm TTFB is healthy before front-end optimisation work; otherwise the front-end fixes are bounded by the back-end ceiling. |
| Currency | n/a, this is a duration in milliseconds. |
| Time window | T/7D |
| Alert trigger | > 1,800ms (poor band). Sub-thresholds: amber 800-1,800ms, red > 1,800ms. |
| 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, lab measurement Wednesday 15 May 26.| Page template | TTFB (mobile) | TTFB (desktop) | Cache state | Driver |
|---|---|---|---|---|
| Homepage | 1,180ms | 720ms | Cache miss (cold visitor) | BC Stencil rendering + uncached |
| Homepage (warm cache) | 220ms | 180ms | CDN edge hit | Cached HTML |
| Product detail page | 1,420ms | 880ms | Cache miss | Stencil rendering + product query |
| Collection page | 1,680ms | 1,040ms | Cache miss | Stencil + 12-item query + filters |
| Cart | 380ms | 240ms | n/a (no cache for cart) | Light backend, session-driven |
| Checkout | 540ms | 320ms | n/a (no cache) | Heavier session validation |
| Mobile p75 (mixed) | ~1,180ms | Amber band, dragging LCP |
- Cache-miss TTFBs are the load-bearing problem. All three primary content templates (homepage, PDP, collection) run 1,180-1,680ms TTFB on cold visits. This sets the LCP ceiling: no front-end optimisation can produce LCP under ~1,200ms because TTFB alone consumes that much.
- Warm-cache TTFB at 220ms shows the upside. When CDN edges have a fresh page cache, TTFB drops dramatically. The optimisation lever: maximise CDN cache hit rate for cold visitors. BC Stencil sites typically have moderate cache hit rates by default; explicit edge-caching configuration can lift hit rates from ~40 percent to 85+ percent.
- The collection page at 1,680ms is the worst. 12-item product query plus filter logic plus Stencil rendering compounds. Investigate: are product queries indexed? Is filter logic efficient? Is the page cacheable at edge for unauthenticated users (typical case)? Most BC merchants can cache collection pages aggressively because they show the same content to every visitor of a given segment.
- Cart and checkout TTFBs are low because they’re necessarily uncached (session-specific) but they’re light backend pages. No optimisation needed; they’re already healthy.
- The mixed mobile p75 of ~1,180ms places the site in amber band. Improvements are possible but it’s not in the “poor” zone. Realistic post-optimisation target: 400-600ms cache-miss TTFB, 100-200ms cache-hit TTFB. Cache-hit rate is the key lever: lifting from 40 percent to 80 percent more than halves the average user’s TTFB.
- LCP implications: the homepage’s 4,820ms LCP includes the 1,180ms TTFB. Front-end optimisations cap at “LCP - TTFB” = 3,640ms of front-end-controllable time. If the merchant achieves 200ms TTFB via aggressive edge caching, the LCP ceiling lifts to 5,000-200 = 4,800ms of headroom; even small front-end wins translate into bigger LCP improvements.
- Geographic latency: some of the TTFB on UK visitors hitting US-based origin servers is unavoidable network RTT (50-100ms). Edge caching at UK POPs (Cloudflare London, Fastly LHR, etc.) eliminates this. BC’s CDN should have UK presence by default; verify in CDN config.
- Distinguish cache-miss TTFB from cache-hit TTFB. Lighthouse measures one synthetic load; check both warm and cold cache states in DevTools.
- Check cache hit rate. CDN dashboard shows what percentage of requests serve from edge cache. Below 60 percent is poor; 80+ is healthy.
- For cache-miss TTFB: check origin server response time (backend + database). For cache-hit TTFB: check CDN edge configuration.
- Geographic check: confirm the audit is hitting an edge near the merchant’s primary user geography.
| Time horizon | Action |
|---|---|
| First 1 hour | Check warm vs cold TTFB; identify if the issue is origin or cache configuration. |
| First 24 hours | Configure aggressive CDN edge caching for cacheable templates. |
| First 7 days | Optimise origin server response for the templates that can’t cache (cart, checkout, personalised pages). |
| Re-audit | Confirm TTFB dropped; verify LCP improvement follows. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_ttfb_p75 | Field-data TTFB; the real-user counterpart. |
crux_lcp_p75 | LCP includes TTFB; LCP cannot be faster than TTFB. |
psi_lab_lcp | Lab LCP; same dependency. |
psi_caching_opportunities | Caching reduces TTFB on repeat visits. |
psi_perf_score_summary | Composite score; TTFB indirectly affects via LCP/FCP. |
crux_fcp_p75 | First Contentful Paint; also includes TTFB. |
psi_top_opportunities_ms | ”Reduce server response times” appears here when TTFB is amber/red. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, “Reduce server response times (TTFB)” opportunity in Diagnostics.
- Chrome DevTools → Network tab, first request’s “Waiting for server response” time is TTFB.
- CDN dashboard, cache hit rate is the most actionable metric for repeat-visitor TTFB; origin response time matters for cold-cache hits.
- Application Performance Monitoring (if configured), Datadog, New Relic, or similar APMs surface server-side timing breakdowns.
| Reason | Direction | What to do |
|---|---|---|
| Cold cache vs warm cache. Vortex IQ runs cold; PSI may hit warm CDN edges. | Vortex IQ higher (cold cache penalty) | Use cold-cache testing for direct comparison. |
| Audit region. Vortex IQ runs from a fixed region; PSI runs from Google infrastructure. | Either direction depending on geography | Confirm audit region matches the merchant’s primary user geography. |
| Run-to-run variance. TTFB depends on network state; ±20-40 percent typical. | Either direction | Use 7-day rolling. |
crux_ttfb_p75, crux_lcp_p75).
Quick rule for support tickets: if a merchant says “my origin server is fast but TTFB is slow”, the most common cause is CDN cache miss rates. Check cache hit rate; below 60 percent often produces “fast origin but slow TTFB” reports because cold visitors hit origin while warm visitors hit edge.