Time to First Byte
Time to First Byte measures how long it takes from starting the navigation to receiving the first byte of the response. It covers redirects, DNS resolution, the TCP connection, the TLS handshake and the time the server spent producing the page.
Good
Under 800ms
Needs work
800ms to 1.8s
Poor
Over 1.8s
Why it matters
Nothing can happen until the first byte arrives. Every other metric on the page inherits this delay, so a 1.5 second TTFB means Largest Contentful Paint cannot be better than 1.5 seconds no matter how well optimised the front end is. It is also the metric front end work cannot fix, which makes it worth measuring before spending a week on images.
How it is measured
The clock starts at navigation and stops when the first byte of the document response is received. That means it includes anything that happens before the server even sees the request, which is why redirect chains and slow DNS show up here rather than anywhere else.
What makes it slow
Slow application code
Uncached template rendering, N+1 database queries and synchronous calls to third party APIs inside the request path are the usual culprits. Profile the request server side before assuming it is infrastructure.
No caching layer
If every request regenerates the same HTML, the server does the same work over and over. Even a short cache lifetime on anonymous pages removes most of it.
Geographic distance
A visitor in London hitting an origin in Mumbai pays the round trip on every connection. Distance is physics, and the only remedy is to serve from somewhere closer.
Redirect chains
Each redirect is a complete request and response before the real one starts. Three hops on a mobile connection can add several hundred milliseconds before the server has done anything useful.
Cold starts
Serverless platforms and containers that scale to zero pay an initialisation cost on the first request after idling, which lands entirely inside TTFB.
How to improve it
Ordered roughly by return on effort. The quick wins are usually worth doing first even when the deeper problem is elsewhere.
Put a CDN in front of the HTML
Quick winEven a short cache lifetime on anonymous pages moves the response to an edge location near the visitor and removes the origin from the critical path entirely for most requests.
Remove redirect chains
Quick winCollapse the http to https and non www to www rules into a single redirect, and make sure internal links point at the final URL.
Cache expensive work
ModerateCache rendered fragments, query results and API responses. The goal is that a typical request does no work that a previous identical request already did.
Profile and fix the slow queries
ModerateLook for queries running inside loops, missing indexes and joins over unbounded tables. A single missing index routinely accounts for most of a slow response.
Pre-render pages that are not per visitor
InvolvedIf the content does not vary by user, generate it ahead of time and serve it as a static file. This turns server response time into a file read, which is as fast as it gets.
How Pulse reports this
Pulse measures TTFB from the region the audit runs in, which is stated on every report. That location matters when reading the number: a site hosted in India measured from Virginia will show a worse TTFB than its actual visitors experience, and the report tells you where the measurement was taken so you can account for it.
Common questions
What is a good TTFB?
Under 800 milliseconds is good, 800 milliseconds to 1.8 seconds needs improvement, and over 1.8 seconds is poor. Fast origins with a CDN routinely achieve under 200 milliseconds.
Is TTFB a ranking factor?
Not directly. It is not a Core Web Vital. But it sets the floor for LCP, which is a ranking signal, so a slow TTFB harms your ranking indirectly and unavoidably.
Why does my TTFB vary between tests?
Caching is the usual reason. A cold cache pays for full page generation, a warm one does not. Distance from the test location, connection setup and origin load also vary between runs.
Related metrics
Measure TTFB on your own page
An audit runs in a real Chromium browser and reports TTFB alongside every other metric, with the measured saving behind each recommendation.