Pages are slow to send their first byte

Why it matters

web.dev describes time to first byte as a measure that precedes every other meaningful loading metric, and says most sites should strive for 0.8 seconds or less. It also notes that it is not a Core Web Vitals metric, so meeting the threshold is not strictly necessary when the other metrics are good.

What to do

1. Read the recorded groups, page addresses and first-byte measurements. Each group is assessed separately; additional fast pages do not cancel an older group's slow result.
2. Review database queries, calls to other services and server-side rendering before the response starts. Check whether server or CDN caching is appropriate for these pages.
3. Compare slow and fast pages within the recorded group. A problem concentrated in one kind of page may come from how those responses are generated.

When to leave it as it is: if your field data, for example in Search Console or a real-user monitoring tool, shows good loading times for visitors, you can leave it. The audit measures from one location.

What we read

For a directly requested HTML page that answers 200, the measurement runs from the recorded request start to the first response byte. It includes connection and TLS setup when needed, and excludes DNS lookup, the audit's own pacing and any preceding redirect. Missing, redirected or otherwise unqualified measurements cannot prove a pass or a fix.

With ten or more qualified pages on an origin, the initial group is a sample. If its nearest-rank 75th percentile exceeds 800 milliseconds, a deterministic selection of at least three of the same pages is measured again later. Both measurements must exceed 800 milliseconds for that group to be reported.

With one to nine qualified pages, the audit must first establish that discovery and its entire page scope completed without a limiting blocker. This group is assessed as a complete small population, and a slow initial result requires a later measurement of every page in it. A capped, interrupted or incompletely discovered small sample does not receive this treatment.

Groups retained from a previous finding are assessed separately using their own pages and repeat requirements. Overlapping groups are not pooled into a larger, faster population. Above 1800 milliseconds the result is marked as poor.

Example & evidence

Illustrative example — one audit, not a live result.

An audit measures twelve pages of bakery.example. Sorted by time, the ninth is the 75th percentile:

https://bakery.example/                      410 ms
https://bakery.example/recipes/              980 ms
https://bakery.example/recipes/sourdough/   1240 ms   <- 75th percentile of 12 pages
...
second measurement of 3 pages: 75th percentile 1190 ms

Both measurements exceed 800 milliseconds, so this sampled group is reported. A complete three-page population would use the largest of the three recorded first-byte measurements as its 75th percentile and would require a later measurement of all three pages to confirm a slow result. If a group's first measurement is 800 milliseconds or less, it needs no new confirmation unless an earlier finding still requires that group's comparison.

Confirm & check again

Check for yourself: open one of the listed pages with your browser's developer tools on the Network tab and read the waiting time of the page request, then repeat it a few times.

Check again: Full audit — Run a new full audit. Every retained group must be checked against its own recorded pages and repeat requirements. The finding closes only when every required comparison is checked and clean. A missing, redirected, unread or unmeasured member keeps its comparison unconfirmed; newly added fast pages cannot dilute an older group.

Limits & sources

These are measurements from one audit location, not your visitors. They exclude DNS lookup and preceding redirects, so they may differ from browser or field measurements.

A group of fewer than ten pages is checked only when the audit establishes a complete small population within its discovered scope. This does not prove that every URL on the site was discoverable. Crawl limits, incomplete discovery, missing measurements or insufficient repeat coverage leave the affected comparison unconfirmed.

The later-request budget is shared across current and retained groups. A group whose required repeat was not completed remains unconfirmed. A storage or subject-size limit also leaves the check incomplete; it does not prove that an earlier finding was fixed.

The check does not measure Largest Contentful Paint or other loading metrics and makes no claim about search position. Pages are grouped by origin, not by page type.

Confidence: Medium The audit uses its own qualified request timings and later measurements of the required same pages. The result still describes one audit location and its recorded population or sample.

Sources

• web.dev, Time to First Byte (TTFB) — says good TTFB values are 0.8 seconds or less and poor values are greater than 1.8 seconds, that TTFB is not a Core Web Vitals metric, and that it is the sum of redirect time, DNS lookup, connection and TLS negotiation, and the request up to the first byte of the response. Checked 14 October 2026.

Editorial review: 19 October 2026