Time to First Byte (TTFB) is the time between the start of navigation to a page and the moment the first byte of the response arrives. web.dev describes it as covering redirects, service worker start-up if present, the DNS lookup, connection and TLS setup, and the request up to the first response byte. MDN gives the same core idea and the formula responseStart from the Navigation Timing API.
At a glance
- Measures
- Time from the start of navigation until the first byte of the response arrives
- Unit
- Seconds
- Assessment
- 0.8 s or less is good, above 1.8 s is poor
- Data source
- Field: Chrome User Experience Report, web-vitals library; lab: DevTools, WebPageTest
- Core Web Vital
- No, helps diagnose LCP
Last checked:
What are the thresholds?
web.dev lists:
- Good: 0.8 seconds or less
- Needs improvement: 0.8 to 1.8 seconds
- Poor: more than 1.8 seconds
TTFB is not a Core Web Vital. It comes before First Contentful Paint (FCP) and Largest Contentful Paint (LCP), so a slow TTFB adds to both. For LCP, web.dev puts TTFB at about 40 percent of the typical total.
Assessed at the 75th percentile of page loads, mobile and desktop separately. Source: web.dev: Time to First Byte (TTFB). Last checked: .
| Metric | Measures | Core Web Vital? | Field or lab | “Good” per web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Render time of the largest image, text block or video visible in the viewport, from the start of navigation | yes (loading) | field and lab | 2.5 s or less |
| INP (Interaction to Next Paint) | Latency of interactions across the whole visit until the next paint; one value that all (or nearly all) interactions fall below | yes (interactivity), since 2024-03-12 | field; in the lab only with simulated interactions, Lighthouse does not measure INP | 200 ms or less |
| CLS (Cumulative Layout Shift) | Largest burst of unexpected layout shifts during the entire lifecycle of the page | yes (visual stability) | field and lab | 0.1 or less |
| TTFB (Time to First Byte) (this term) | Time from the start of navigation until the first byte of the response arrives | no (helps diagnose LCP) | field and lab | 0.8 s or less |
| FCP (First Contentful Paint) | Time from the start of navigation until any part of the page's content is rendered | no (helps diagnose LCP) | field and lab | 1.8 s or less |
| TBT (Total Blocking Time) | Total time after FCP during which the main thread was blocked long enough to prevent input responsiveness | no (lab proxy for INP) | lab; web.dev does not recommend field measurement | less than 200 ms on average mobile hardware |
| Speed Index | How quickly content is visually displayed during page load (from a video of the load) | no | lab (Lighthouse) | Threshold according to Lighthouse: mobile up to 3.4 s “fast” (web.dev gives no value) |
| FID (First Input Delay), historical | Time from the first interaction until the browser can begin processing event handlers | until 2024-03-12, replaced by INP | field only | 100 ms or less |
According to web.dev, the 75th percentile of page loads is assessed, mobile and desktop separately. A page passes the Core Web Vitals when LCP, INP and CLS are “good” at the 75th percentile. Chrome tools ended FID support on September 9, 2024. Sources: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Last checked: .
How is it measured?
In the field with the Chrome User Experience Report or the web-vitals library, in the lab with Chrome DevTools or WebPageTest. Tools do not all measure the same span. According to DebugBear, the Lighthouse audit for server response time leaves out connection setup. In JavaScript:
const ttfb = performance.getEntriesByType("navigation")[0].responseStart;
With HTTP 103 Early Hints, MDN notes that the value may reflect the early response and not the final one.
What causes a slow TTFB?
DebugBear groups the causes:
- Server work: heavy template rendering, many plugins.
- Database: slow or repeated queries, missing indexes.
- Network: distance between visitor and server.
- Dependencies: calls to third-party APIs, cold starts of serverless functions.
Typical fixes are caching HTML at a CDN, optimizing queries and reducing redirects.
Example
A shop page shows a TTFB of 1.2 seconds in field data, which is in the “needs improvement” range. Most of that time is spent waiting for the server to build the page. Caching the rendered HTML at the CDN edge lowers the wait.
Sources
- Time to First Byte (TTFB) – web.devweb.dev
- Time to First Byte – MDN Web Docsdeveloper.mozilla.org
- Time to First Byte – DebugBeardebugbear.com
- Optimize Time to First Byte – web.devweb.dev
- Web Vitals – web.devweb.dev
Last updated: