Time To First Byte Test
What is it?
Time to First Byte (TTFB) measures the delay between the browser requesting your page and the first byte of the response arriving. TTFB reflects backend, network, and CDN performance, and it effectively sets the floor for every other loading metric: rendering cannot begin until bytes start flowing.
Why TTFB still matters in 2026
TTFB is the metric that captures how fast your server is to respond, which is one of the few performance levers that no amount of front-end optimization can fix. A page can ship perfectly minified JavaScript, AVIF images, and inline critical CSS, and still feel slow if the server takes two seconds to send the first byte. Google recommends keeping TTFB under 800 milliseconds at the 75th percentile of users, which is the threshold for a "good" experience.
TTFB is also the foundation under every other Core Web Vital. Largest Contentful Paint cannot complete until rendering starts, which cannot start until the response begins arriving. First Contentful Paint similarly waits on TTFB. Improving server response time therefore tends to improve every loading metric simultaneously, which is why edge caching and origin performance work pay disproportionate dividends.
Common causes of slow TTFB
- Slow server processing from expensive database queries, N+1 loops, or synchronous third-party API calls.
- No edge caching: caching HTML at the CDN reduces TTFB to a single edge round trip for cacheable pages.
- Long redirect chains adding latency before the response starts flowing.
- Origin in a distant region from your audience, which a CDN or multi-region origin solves.
- HTTP/1.1 with no keep-alive, which adds connection setup overhead per request.
This test measures your TTFB. The fix guide below covers profiling slow endpoints, configuring edge caching, collapsing redirect chains, and the protocol upgrades (HTTP/2 and HTTP/3) that reduce TTFB on every request.
Pass rate:
-
Top 100 websites: 99%This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 79%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | N/A |
|---|---|
| 2022 | 98% |
| 2023 | 98% |
| 2024 | 99% |
100
75
50
25
0
How do I fix it?
Time to First Byte (TTFB) measures the delay between the browser requesting the page and the first byte of the response arriving. TTFB reflects backend, network, and CDN performance and effectively sets the floor for every other loading metric, since rendering cannot begin until bytes start flowing. Fixing this issue usually means improving server response time, adding edge caching, or reducing redirect chains.
Where to make the change
- Server and hosting: upgrade to a faster host plan, move to a region closer to your users, and enable HTTP/2 or HTTP/3.
- CDN: putting the site behind a CDN dramatically reduces TTFB for users far from the origin server. Cache HTML responses at the edge whenever possible.
- Application code: profile slow endpoints, cache expensive database queries and external API calls, and use streaming or partial responses.
Common causes and how to resolve them
- Slow server processing: profile the slowest controllers or routes. Database queries, N+1 loops, and synchronous third-party API calls are typical culprits.
- No edge caching: caching HTML at the CDN reduces TTFB to a single edge round trip. Use rules to bypass cache for logged-in users.
- Long redirect chains: each hop adds latency before bytes flow. Collapse chains so the URL the user requests resolves to its final destination in one step.
- Origin in a distant region: a US-only origin makes Asian users wait. Add edge regions or move the origin closer to the audience.
- HTTP/1.1 or no keep-alive: upgrading to HTTP/2 or HTTP/3 reduces connection setup overhead.
Best practices
- Target sub-800 millisecond TTFB at the 75th percentile: Google's recommended threshold for a "good" experience.
- Cache aggressively: the cheapest server work is the work you never do. Static and semi-static pages should be served from cache.
- Use HTTP/3 where supported: it eliminates head-of-line blocking and reduces handshake latency, especially on mobile networks.
- Stream the response when possible: sending the head before the rest of the body lets the browser start fetching subresources earlier.
