Time to First Byte (TTFB)
Also known as: TTFB
Time to first byte measures how long it takes for a browser to receive the first byte of a page from the server after making a request. It captures server response time, network latency, and any redirects along the way.
Key Takeaways
- Time to First Byte measures how long the browser waits for the first byte of a response after sending a request.
- TTFB captures server processing time, network latency, and any redirects that happen before content starts arriving.
- A slow TTFB delays every downstream metric, so front-end tuning cannot fully compensate for a slow backend.
- Common fixes include server-side caching, a faster host, a CDN, and eliminating unnecessary redirect chains.
- TTFB is a diagnostic signal for server health rather than a direct Core Web Vitals metric.
How It Works
When a browser requests a page, the server has to receive the request, process it, and start sending bytes back. Time to First Byte is the gap between the request going out and that first byte arriving. It includes DNS lookup, connection setup, redirects, and the time the server spends building the response.
Because TTFB happens before any rendering, a slow first byte pushes back everything that follows, including Largest Contentful Paint and the overall Core Web Vitals picture. No amount of image compression or script deferral can hide a backend that takes a full second to respond.
The usual levers are caching, a faster or closer host, and a CDN that serves content from the edge. On paid traffic, a sluggish server also weakens Landing Page Experience, since a slow response makes the whole visit feel heavy from the first moment.
Why It Matters
A slow TTFB delays everything that follows, dragging down Core Web Vitals and the perceived speed of the page. On paid landing pages a slow first byte raises bounce and lowers Quality Score.
Example
A local dentist runs a booking page on shared hosting with no caching. Each request rebuilds the page from the database, so the browser waits nearly a second before the first byte arrives. After moving to a faster host and adding page caching, the first byte returns in a fraction of that time, and the page starts painting sooner for every visitor.
Common Mistake
Optimizing images and scripts while ignoring a slow backend. If the server takes a second to respond, front-end tuning cannot compensate, and caching or a faster host is the real fix.
Frequently Asked Questions
What is a good TTFB?
A commonly cited target is under 800 milliseconds, with faster being better. Values depend on hosting, caching, and user location, so measure from real locations rather than trusting a single lab number.
How is TTFB measured?
It is the time from when the browser sends the request to when it receives the first byte of the response. Browser dev tools, Lighthouse, and field data tools like the Chrome User Experience Report all report it.
Is TTFB part of Core Web Vitals?
No. TTFB is a diagnostic metric that influences Core Web Vitals rather than one of them. A slow first byte still drags down metrics like Largest Contentful Paint that users and search engines care about.
How do I fix a slow TTFB?
Focus on the backend: add server-side caching, upgrade to a faster host, use a CDN to serve from the edge, and remove redirect chains. Front-end optimization alone will not fix a slow server response.