What is TTFB (Time to First Byte)?
TTFB measures how long it takes for the browser to receive the first byte of the page response. Learn why it matters, what causes a slow TTFB, and how to fix it.
Time to First Byte (TTFB) measures the time between a browser requesting a page and receiving the first byte of the response. It’s the earliest possible indicator of server and network performance — before any content has been rendered.
While TTFB isn’t a Core Web Vital itself, it’s a foundational metric. A slow TTFB delays everything else: parsing HTML, loading resources, rendering content. If TTFB is poor, improving your LCP or FCP becomes much harder.
What TTFB Includes
TTFB encompasses three phases:
- DNS lookup — resolving the domain name to an IP address
- TCP connection — establishing the connection to the server (including TLS handshake for HTTPS)
- Server processing time — the time the server spends generating and starting to send the response
The total is: DNS + TCP + TLS + server processing time.
TTFB Thresholds
| Score | Time |
|---|---|
| Good | Under 800ms |
| Needs improvement | 800ms – 1800ms |
| Poor | Over 1800ms |
Google recommends a TTFB under 800ms to give downstream metrics (LCP, FCP) a good chance of hitting their own targets.
What Causes a Slow TTFB?
Server processing time The most common culprit for dynamic sites. If your server needs to query a database, generate HTML, and wait for external APIs before sending any response, TTFB will suffer. A WordPress site hitting a slow database or running too many plugins is a classic example.
No caching Without caching, every request hits the origin server and runs through the full application stack. With proper caching (full-page cache, object cache, edge cache), most requests can be served without any application processing.
Physical distance HTTP requests travel at the speed of light, which isn’t instantaneous. A server in the US serving users in Australia will have a baseline latency of 150–250ms before any processing.
Slow DNS Cheap DNS providers can add 100–500ms to every new connection. Most users won’t experience this (DNS is cached), but first-time visitors and crawlers will.
SSL/TLS overhead While TLS is necessary, a slow TLS handshake can add significant time. HTTP/2 and HTTP/3 reduce this through connection reuse.
How to Improve TTFB
Enable server-side caching For dynamic sites, a full-page cache is the highest-impact change. Platforms like WordPress have object caching (Redis, Memcached) and full-page caching plugins. A cached response can be served in under 50ms even from the origin.
Use a CDN A content delivery network caches your pages at edge nodes close to your users. For static content, TTFB from a CDN is typically 10–50ms. Even for dynamic content, CDNs can reduce latency through connection reuse and protocol optimization.
Move to edge computing Platforms like Cloudflare Workers, Vercel Edge Functions, and Deno Deploy run your application code in the region closest to the user. This can reduce TTFB to under 100ms globally for dynamic content.
Optimize your database queries If your server is slow due to database lookups, add indexes, use query result caching, and eliminate N+1 query patterns.
Switch DNS providers Cloudflare, AWS Route 53, and Bunny DNS all offer faster DNS resolution than most registrar-provided DNS.
Diagnosing TTFB
Run a test on debugutils.dev. The waterfall chart shows each request with TTFB clearly marked — you can see exactly how much time the server is spending before it starts sending the page.
Compare your TTFB against the thresholds and look at how much of your LCP time is spent waiting for the server versus loading resources.