Skip to main content
Performance Auditor — fetches the audited URL five times, two seconds apart, measures how long the server takes to send the first byte of each answer and judges the average against the web.dev targets: 800 ms or less is good, more than 1800 ms is poor.

First paint

Nothing renders until the first byte arrives, so TTFB is added to every other speed metric of the page.

Standards

Follows the web.dev Time to First Byte guidance: good up to 800 ms, poor above 1800 ms.
Time to First Byte (TTFB) is the time between sending a request and receiving the first byte of the response. It covers DNS, the TCP and TLS handshakes, any redirects and, above all, the time the server spends building the page. A slow TTFB delays First Contentful Paint and Largest Contentful Paint by the same amount, so a fast server response is the floor under every other Core Web Vital. This auditor measures it from the 37 Audits infrastructure with several requests, so one unlucky sample does not decide the verdict.

​
How it works

  1. Sample — sends a GET to the audited URL as 37AuditsBot five times, two seconds apart, downloading at most one byte of each body. A blocked request ends the audit with 590.
  2. Measure — records, for every sample, the time from sending the request (of the last redirect hop) until the response arrived.
  3. Verify — a sample that cannot be fetched (timeout, DNS or TLS failure, HTTP 4xx/5xx other than a block, an empty response, or an interruption between samples) ends the audit with 500: the measurement is incomplete, which is not a verdict on the site.
  4. Summarize — computes the integer average, the fastest and the slowest sample; all samples are kept in the check data (ttfbMs, minTtfbMs, maxTtfbMs, numberOfTests, allMeasurements).
  5. Rules — an average above 1800 ms fails (400); an average above 800 ms but not above 1800 ms warns (300).
  6. Aggregate — FAIL wins over WARNING; an average of 800 ms or less is SUCCESS (200).

​
What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​
Output documentation

​
Risks and considerations

​
Why TTFB matters

  • The browser cannot paint anything before the first byte arrives, so every millisecond of TTFB is added to First Contentful Paint and Largest Contentful Paint, two of the metrics search engines use to rank pages.
  • Visitors on slow mobile connections feel a slow server twice: once waiting for the HTML and again waiting for the assets it references.

​
What drives the number

  • Server-side work dominates: uncached database queries, heavy templating, slow third-party calls made during rendering, or an undersized host.
  • Network distance adds up: a CDN or an edge cache close to your visitors removes the round trips to the origin.
  • Redirect chains count: the measurement covers the last hop only, but every earlier hop delays the visitor before it.

​
How the measurement is taken

  • Five samples two seconds apart smooth out a single slow answer; the verdict uses the average, and the fastest and slowest samples are reported with it.
  • Requests come from the 37 Audits infrastructure, so the absolute value differs from what a visitor in another region sees. Treat the trend across audits as the signal, not a single run.
  • The first sample may hit a cold cache; later samples usually show the cached answer. A large gap between minTtfbMs and maxTtfbMs points at caching that only works part of the time.

​
What this auditor does not check

  • Only the audited URL is measured; other pages of the site, and the assets the page loads, may be slower.
  • It does not measure how long the page takes to render in a browser; the Lighthouse Performance auditor covers the lab Core Web Vitals.