> ## Documentation Index > Fetch the complete documentation index at: https://docs.37audits.com/llms.txt > Use this file to discover all available pages before exploring further. # TTFB Auditor > Measures the server's time to first byte over several requests against the 800 ms / 1800 ms targets **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. Nothing renders until the first byte arrives, so TTFB is added to every other speed metric of the page. Follows the [web.dev Time to First Byte guidance](https://web.dev/articles/ttfb): 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. | CheckCode | Status | When it fires | Recommendation | Why it matters | | - | - | - | - | - | | `37A-TTFBAuditor-400` | `FAIL` | The average time to first byte over the samples is more than 1800 ms. | Bring the average time to first byte of `{url}` down from `{avg}` ms to 800 ms or less: cache rendered pages on the server, serve them through a CDN close to your visitors and speed up the backend (slow database queries, heavy middleware, undersized hosting). | Every page view waits on the server's first byte before anything renders, so a slow server response delays all other metrics, hurts search rankings and makes visitors leave before the page appears. | | `37A-TTFBAuditor-300` | `WARNING` | The average time to first byte over the samples is more than 800 ms but not more than 1800 ms. | Bring the average time to first byte of `{url}` down from `{avg}` ms to 800 ms or less: cache rendered pages on the server, serve them through a CDN close to your visitors and look for slow backend work (database queries, middleware) on this page. | The browser cannot start rendering until the first byte arrives, so a slow-ish server adds its delay to every page load and holds back every other speed metric, which costs search rankings and visitor patience. | | `37A-TTFBAuditor-200` | `SUCCESS` | All rules passed. Message is `Time to first byte of {url} averaged {avg} ms over {n} requests (min {min} ms, max {max} ms), within the 800 ms target.` | — | — | | `37A-TTFBAuditor-500` | `ERROR` | One of the samples could not be fetched: timeout, DNS or TLS failure, an HTTP status other than 2xx (other than a block), an empty response body, or an interruption between samples. | Make sure `{url}` answers every request with HTTP 2xx and a body, then run the audit again. Sample `{sample}` failed with: `{error}`. | — | | `37A-TTFBAuditor-590` | `ERROR` | The audited page answered HTTP 403, HTTP 429 or a Cloudflare challenge, so 37AuditsBot was blocked before it could read the page. | Allow 37AuditsBot in your firewall or bot protection: allowlist its user agent, or verify its Web Bot Auth signature. See [https://www.37audits.com/bot](https://www.37audits.com/bot). | While 37AuditsBot is blocked this audit cannot look at the site, so problems on it go unreported. | ## Output documentation | Status | Description | Test logic | | - | - | - | | **SUCCESS** | The server answers fast | Average TTFB of 800 ms or less (`200`). | | **WARNING** | The server answer needs improvement | Average TTFB above 800 ms and up to 1800 ms (`300`). | | **FAIL** | The server answers slowly | Average TTFB above 1800 ms (`400`). | | **ERROR** | The auditor could not complete the measurement | A sample could not be fetched or had an empty body (`500`); site blocked 37AuditsBot (`590`). | ## 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.