Skip to main content
Metrics type: Supporting Metrics • Category: Website Performance

​
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.

​
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. What the per-template view is telling us:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
The diagnostic flow:
  1. Distinguish cache-miss TTFB from cache-hit TTFB. Lighthouse measures one synthetic load; check both warm and cold cache states in DevTools.
  2. Check cache hit rate. CDN dashboard shows what percentage of requests serve from edge cache. Below 60 percent is poor; 80+ is healthy.
  3. For cache-miss TTFB: check origin server response time (backend + database). For cache-hit TTFB: check CDN edge configuration.
  4. Geographic check: confirm the audit is hitting an edge near the merchant’s primary user geography.
Rapid-response playbook:

​
Sibling cards merchants should reference together

​
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.
Why the Vortex IQ TTFB may differ from PSI: Cross-connector reconciliation: primarily internal (with 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.

​
Known limitations / merchant FAQs

Why is TTFB so important? Because everything else waits for it. The browser cannot start parsing HTML, downloading resources, or rendering until the first byte of the response arrives. A 1,200ms TTFB sets a 1,200ms floor on every other page-load metric. Always check TTFB before front-end optimisation work; if TTFB is slow, front-end fixes hit a ceiling. My TTFB is 600ms. Is that good enough? Yes. 600ms is right at the Lighthouse “good” threshold. Improvements below 400ms have diminishing returns for ecommerce; the marginal LCP improvement is usually under 100ms. My origin is fast (200ms) but TTFB is 1,200ms. Why? Almost certainly CDN cache miss. The user’s request goes: browser → CDN edge → origin → CDN edge → browser. If the edge has a cached copy, request stops at the edge; if not, it continues to origin. Cache hit rate is the lever; lift it via aggressive edge-caching configuration. Should I optimise origin or CDN first? Cache hit rate first, almost always. Lifting cache hit rate from 40 percent to 80 percent halves the average user’s TTFB. Origin optimisation helps only the 20 percent of cache-miss visitors. CDN configuration is the highest-leverage TTFB work. Can I cache cart and checkout pages? No. These pages are session-specific (per-user cart contents, login state, payment flow). Cache them and you’d serve user A’s cart to user B. Accept higher TTFB on cart/checkout; optimise origin instead. The volume of cart/checkout requests is small relative to product browsing, so the impact is bounded. My BC store has 1,500ms TTFB on collection pages. Is BC slow? Probably not BC’s fault; usually configurable. BC Stencil with default settings serves uncached collection pages, hitting BC’s origin renderer per request. Configure aggressive CDN caching for collection pages (Stencil supports edge-caching with appropriate cache-control headers). Most BC merchants reach 200-400ms TTFB on collection pages with proper config. Can Vortex IQ change my CDN config? Read-only by design. The card identifies the issue; the merchant or developer configures the CDN. Will moving to Catalyst help TTFB? Yes, structurally. Catalyst (Next.js-based) defaults to edge-rendered SSR which produces 100-300ms TTFB at edge POPs. Stencil’s default rendering pattern produces 600-1,500ms TTFB. Migration is one of the strongest TTFB improvements available; CWV pass rate improves accordingly.

​
Tracked live in Vortex IQ Nerve Centre

Server Response 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 or book a demo to see this metric running on your own data.