Time to First Byte

mediumperformance-ttfbreviewed 19 September 2026

TTFB measures everything before the first byte of HTML arrives — DNS, TLS, and the server's own thinking. Why it caps every other metric.

What it is

Time to First Byte is the interval between the browser asking for a page and the first byte of the response arriving. It covers DNS resolution, the TCP and TLS handshakes, and whatever the server did before it started answering — database queries, template rendering, an upstream API call.

It measures nothing about rendering. A page can have an excellent TTFB and still paint slowly, and a page cannot paint quickly with a bad one.

Why it matters

Every other loading metric starts counting from this one. First Contentful Paint and Largest Contentful Paint are both bounded below by TTFB — a second spent before any HTML exists is a second no amount of front-end work can recover.

It is also the metric most likely to be invisible to the people who built the site. A developer on a fast connection near the origin sees a fraction of what a visitor two continents away experiences, and TTFB is the part of the budget that distance and cold serverless starts consume.

How to fix it

with a reference doc

what to reach for, in order

1. Cache the rendered response (a CDN edge cache, or a full-page cache at the origin)
2. Cache the expensive query behind it
3. Move the origin closer to visitors, or put a CDN in front of it
4. Check for a cold start: serverless platforms pay it on the first request after idle

nginx

# serve a cached response and refresh it in the background
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=pages:10m;
location / {
  proxy_cache pages;
  proxy_cache_valid 200 10m;
  proxy_cache_background_update on;
}

Reference documentation

Related checks

highLargest Contentful Paint (LCP)Largest Contentful Paint (LCP) measures the time from navigation start until the largest image or text block in the viewport has rendered — a stand-in for 'when does this page feel loaded' rather than 'when did the first byte arrive'. It's one of Google's three Core Web Vitals.lowCache headers on static assetsThis check looks at the static assets a page loaded — stylesheets, scripts, images, fonts — and asks whether each one came back with a Cache-Control header that lets the browser keep it.mediumText compressionThis checks whether text resources — HTML, CSS, JavaScript — are served with gzip or brotli compression via the Content-Encoding header. Resources under about 1.4KB are excluded, matching Lighthouse's own threshold: below that size, compression's header overhead costs more than it saves.mediumRender-blocking resourcesA render-blocking resource is a stylesheet or synchronous script in <head> that the browser must download and process before it can paint anything — the page stays blank until every one of them resolves. This check looks specifically at resources in the document head, the ones the browser encounters before it can render a single pixel.

This is one of the 75 checks the scanner runs. See what we check for the full list, every severity weight, and how the score is computed from them.

What it is

Why it matters

How to fix it

Related checks

See whether your own site passes time to first byte.