How to reduce Time to First Byte (TTFB)
TTFB is how long the server takes to start answering. Every other metric waits for it. Under 800 ms is fine; page caching and a CDN usually cut it in half.
Step by step, with screenshots: How to choose a web host: compare measured speed, not reviews →
Check your own site
Runs these 2 checks and the other 191, free, in about 45 seconds.
Or run only this check with the free TTFB test, the free Web hosting speed test or the free Core Web Vitals checker.
What it is
Time to First Byte (TTFB) is the time between a browser requesting a page and receiving the first byte of the response. It includes redirects, the DNS lookup, connecting, the TLS handshake and the time the server spends building the page.
Google rates TTFB as good at 800 ms or less and poor above 1.8 s, at the 75th percentile of real visits. It is not a Core Web Vital, but every other metric waits for it: a 1.5 s first byte leaves only 1 s for the rest of a 2.5 s LCP. getReport shows the real-user TTFB from the Chrome UX Report and the server's own response time from Lighthouse, which should stay under 600 ms.
What a passing site looks like
- Real-user Time to First Byte: passesfail · −5 ptseffort M
- Time to First Byte: passesfail · −5 ptseffort M
1. Real-user Time to First Byte
Why it matters. How long real visitors wait for the server's first byte, including their own network and distance. It is the first-byte number Google uses, and everything else on the page waits for it. Google's threshold for "good" is 800 ms; above 1.8 s is poor.
- Turn on full-page caching, so the server sends a ready-made page instead of building it for every visit.
- If a CDN such as Cloudflare sits in front, let it cache the HTML too, with a rule that skips logged-in users, the cart and checkout. The hosting speed test shows whether it does.
- If the page cannot be cached, find what makes the server slow, such as heavy plugins or slow database queries, or move to a faster plan or a server closer to your visitors.
2. Time to First Byte
Why it matters. TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).
- Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
- Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
- Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.
Questions people ask
How much of Largest Contentful Paint should Time to First Byte take?
Roughly 40 %, following Google's web.dev guidance on optimising LCP. Google splits LCP into four parts, TTFB, resource load delay, resource load duration and element render delay, and suggests TTFB and load duration take about 40 % each, with each delay under 10 %. For the 2.5 s LCP target that leaves about 1 s for the first byte, so a slower server squeezes every other part of the page load.
Why is Time to First Byte higher on mobile?
Mostly because of the network, not your server. Real-user TTFB includes the DNS lookup, the connection and the TLS handshake, and each round trip takes longer over mobile data than on a fixed line. Google's field data separates phones from desktops, so a server that passes on desktop can still miss 800 ms on phones. Fewer redirects, a CDN close to your visitors and HTTP/3, which needs fewer round trips to connect, all narrow the gap.
What is a good Time to First Byte?
800 ms or less for real visitors is good and over 1.8 s is poor, according to Google's web.dev guidance. For the server's own share, without the visitor's network, aim for under 600 ms, the point where Lighthouse flags it. Cached pages served from a CDN usually answer in well under 200 ms.
Does TTFB affect SEO?
Indirectly. TTFB is not a ranking signal on its own, but a slow first byte delays Largest Contentful Paint, which is a Core Web Vital. Very slow server responses can also reduce how many pages Googlebot crawls, because Google slows its crawling when a server responds slowly or returns errors.