dotvitals

The server takes too long to send the first byte to real visitors

MediumConfirmedperf.crux.ttfb-slow

What this check looks for

For a quarter of real visits to ‹scope›, ‹value› passed before the server sent anything at all. Google's guidance is 800 milliseconds.

Why it matters

Every other timing on the page starts after this one. Time spent waiting for the first byte cannot be recovered by any amount of front-end optimisation — it is a fixed cost added to how long your visitors wait to see anything.

When the check passes, your report says: “The server sends its first byte promptly for real visitors”.

What it costs your score

When this check fails it removes 8 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.field family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity
medium
Default confidence
confirmed
Status when triggered
fail
Deduction
8 points
Family cap
performance.field · 35
Category
Performance
Module
Perf crux
Fix owned by
user
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Get the first byte to real visitors within 800 ms.

Every visitor currently waits ‹value› before the page can even begin to render, and no front-end change can win that time back.

  1. Remove redirects on entry. A redirect from http:// to https:// to www. costs a full round trip each, and they are inside this number. The redirect section of this report lists the chain.

  2. Cache the HTML at the edge where the page allows it. A CDN hit serves the document from near the visitor instead of from your origin.

  3. Profile the server-side request: slow database queries, uncached template rendering and synchronous calls to third-party APIs are the usual causes of a slow origin.

  4. Check the geography. If your visitors are far from your single origin region, the network time alone can exceed the budget; that is what a CDN or a multi-region deployment solves.

  5. Make sure the connection itself is not the cost — HTTP/2 or HTTP/3, session resumption, and a short certificate chain all shave setup time.

How to confirm it worked

  • Re-run this scan after the change has been live for several weeks — field data uses a trailing 28-day window.

  • curl -sSo /dev/null -w 'ttfb=%{time_starttransfer}s redirects=%{num_redirects}\n' https://‹host›/ — a synthetic lower bound, not what visitors see

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Technical detail

Time to First Byte at the 75th percentile: **‹value›** (‹band›).

This is **field data**: the experience of real Chrome users who visited ‹scope› over the trailing 28-day collection window, not a measurement we took ourselves. The number quoted is the **75th percentile** — Google's own choice of statistic, meaning three visits in four were at least this good. A site with a fast median can still fail here, and that is the point: the quarter of visits that are worst are real people on real networks and devices.

Field data also lags. A fix you deployed yesterday will not move this number until it has been in front of users for most of the window, so use the lab measurements alongside it to confirm the change landed.

Google's published guidance: **good at or below 800 ms**, needs improvement up to 1,800 ms, **poor above 1,800 ms**. TTFB is not itself a Core Web Vital, but it is a direct input to LCP and it is usually the first thing to check when LCP is poor.

Field TTFB measures the **whole journey**, and this is why it is often much worse than a synthetic test suggests: redirect time, DNS lookup, connection setup, TLS negotiation and the server's own processing are all inside it, measured from the visitor's own network. A synthetic check from a data centre — including the one this report performs under http.reachability — sees a well-connected single request and routinely reports a fraction of what real users experience. Where the two disagree, the field number is the one your visitors live with. ‹detail›

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the perf crux checker

Other perf crux checks