What Is TTFB?

Category: Performance & CDN · Updated 2026-10-31

TTFB (Time to First Byte) is the time between a browser sending an HTTP request and receiving the very first byte of the response, covering DNS lookup, connection setup, server processing and the trip across the network. A lower TTFB means the server started responding sooner, which gives every later step of page loading, including rendering, more time to finish within a visitor's patience.

What TTFB actually measures

TTFB bundles together everything that happens before a browser sees any content at all: looking up the domain's IP address through DNS, opening a TCP connection, completing the TLS handshake for HTTPS, sending the request, and waiting for the server to process it and start sending a reply. Only once that first byte arrives does the browser have anything to begin rendering.

DNS lookup: translating the domain name into an IP address
Connection setup: the TCP handshake, and the TLS handshake for HTTPS
Server processing: the application generating the response, often the biggest and most variable chunk
Network transit: the physical round trip between the visitor and the server

TTFB vs. other speed metrics

Metric	What it measures	Depends mainly on
TTFB	Time until the first byte of the response arrives	Server, DNS, connection setup, distance
First Contentful Paint	Time until any content appears visually	TTFB plus how fast the browser can render it
Largest Contentful Paint	Time until the largest visible element finishes loading	TTFB, image and font loading, page weight

A slow TTFB pushes every later metric back, since nothing downstream can start until the first byte shows up, while a fast TTFB does not by itself guarantee a fast-feeling page if heavy scripts or large images follow it.

What commonly causes a slow TTFB

Slow database queries or uncached application logic that the server has to run before it can respond
A shared hosting account under heavy CPU load from other accounts on the same server
No page or object caching, so every request regenerates the full page from scratch
A server located far from the visitor, adding pure network travel time
Slow or misconfigured DNS, or an unnecessary redirect chain before the real request happens

How to measure TTFB

Browser developer tools show TTFB directly in the Network tab's timing breakdown for any request. From the command line, curl can report the same figure for a quick check without a browser:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

Online tools such as WebPageTest and Google PageSpeed Insights also report TTFB as part of a fuller waterfall of a page's load.

How to improve TTFB

Google's published guidance for the web generally treats a TTFB under about 800 milliseconds as good, with anything over roughly 1.8 seconds considered poor, though the number that matters most is whether it is fast enough for your actual visitors.

Add or improve server-side caching (page cache, object cache, or an opcode cache like OPcache for PHP) so pages are not rebuilt from scratch every time.
Put a CDN in front of the site so static and cacheable content is served from a location near the visitor.
Upgrade hosting resources, or move off an overloaded shared server, if CPU contention is the bottleneck.
Optimize slow database queries and add appropriate indexes.
Remove unnecessary redirects between the visitor's request and the final response.

Frequently asked questions

What is a good TTFB?

Under about 800 milliseconds is generally treated as a good TTFB, and under roughly 1.8 seconds is considered acceptable, though the right target depends on your audience and how much time is left for the rest of the page to load.

Does TTFB affect SEO?

TTFB is not a direct ranking factor by itself, but it feeds into Core Web Vitals metrics like Largest Contentful Paint that do influence search ranking signals, so a slow TTFB can hurt rankings indirectly.

Why is my TTFB slow even with a fast server?

A fast server does not help if DNS lookups are slow, the visitor is far from the server with no CDN in front of it, or the application itself spends time running uncached database queries before it can respond.

Can a CDN reduce TTFB?

Yes, for cacheable content a CDN can serve the response from a location physically closer to the visitor, cutting network transit time, and it can also serve cached pages without hitting the origin server at all.

Is TTFB the same as page load time?

No. TTFB only measures the time until the first byte of the response arrives; page load time includes everything after that, such as downloading images, running scripts and finishing rendering.

What tools show TTFB?

Browser developer tools (the Network tab), command-line tools like curl with timing flags, and online testing services such as WebPageTest and Google PageSpeed Insights all report TTFB.