Guides

TTFB, or Time To First Byte, is the time between the moment your browser asks a server for a page and the moment the first byte of the response comes back. It is measured in milliseconds and covers everything that must happen before the browser can even start reading the page: resolving the domain, opening the connection, and - the part that usually dominates - the server doing its work and sending out that first byte.

It matters because TTFB is the tax paid on every single request before anything visible can happen. A browser cannot render a single pixel until bytes start arriving, so a slow TTFB delays the whole page by that amount, no matter how well optimised your images, CSS and JavaScript are. It is the floor under your loading speed.

What TTFB actually measures

Under the hood, TTFB is a sum of smaller waits: any redirects, the DNS lookup that turns your domain into an IP address, the TCP connection and TLS handshake that secure it, the time the request spends travelling to the server, and finally the server processing time until the first byte is written back. On most sites that last piece - how long the server takes to build the response - is the largest and the most fixable.

Crucially, TTFB is a back-end and network measurement, not a front-end one. If your TTFB is high, the problem is on the server, the hosting or the network path, not in your React or Vue code. That is a useful diagnosis: it tells you to look at your host, your caching and your database rather than at your bundle size.

What counts as a good TTFB

Google's guidance, published on web.dev, is that a good TTFB is roughly under 800 milliseconds for most sites, with anything above 1.8 seconds considered poor. These are field thresholds - measured on real visits - so they already account for real networks and devices rather than a lab test on fast hardware.

• Slow or overloaded hosting - a shared server straining under other sites' traffic
• Uncached dynamic pages regenerated from scratch on every single request
• Heavy database queries or slow back-end code inflating server processing time
• No CDN, so every visitor connects to one distant origin server
• Redirect chains that add extra round trips before the real response begins
• Slow TLS handshakes or a server located far from most of your audience

TTFB is not itself one of the three Core Web Vitals, but it feeds directly into Largest Contentful Paint. LCP can never be faster than the TTFB that precedes it, because the main content cannot appear until the response has started. Improving a slow TTFB often lifts LCP for free, which is why performance work so often starts here.

How to reduce TTFB

The biggest server-side lever is caching. Serving a page from a full-page cache or a CDN edge cache skips the work of regenerating it on every request, turning hundreds of milliseconds of processing into a near-instant hit. Beyond that, faster or less crowded hosting, leaner back-end code, and trimming slow database queries all cut the processing portion directly.

On the network side, a CDN shortens the physical distance between your server and each visitor, so the request and response travel less far. Modern connection handling - HTTP/2 or HTTP/3, keep-alive, and a well-configured TLS setup - reduces the handshake overhead, and where a page can be pre-rendered to static files, static hosting removes server processing from the critical path almost entirely.

The bottom line

In short, TTFB is the server-response tax on every page you serve, and it sets the ceiling for how fast the rest of your site can feel. A capable host, aggressive caching and a CDN are the three levers that move it the most - which is why fixing TTFB is usually the highest-leverage performance work you can do before touching a single line of front-end code.