Sometimes a page sits blank for a moment before anything shows up. That pause often happens before a single pixel is drawn. It is the browser waiting for the server to respond. This wait has a name, Time to First Byte, and it sets the ceiling for how fast the rest of your page can feel.
We see this a lot when we audit slow sites. The images are fine and the code is clean, yet pages still feel sluggish. The delay is hiding on the server side, before the browser has anything to work with. In this guide we explain what Time to First Byte is, what counts as good, and the steps we take to improve it.
Time to First Byte, or TTFB, measures the time between starting to load a page and when the first byte of the response arrives. Google's web.dev defines it as the wait that covers redirects, DNS lookup, connection and TLS setup, and the server's time to start replying.
Think of it as the gap between knocking on a door and hearing the first word back. During that gap, the browser has asked for your page and is simply waiting. Nothing can be drawn yet. A long TTFB means every other part of the load starts late.
It is a server-side story more than a design one. The browser cannot speed this up on its own. The response has to travel to your server, get processed, and come back. That is why TTFB is often the first thing we check when a site feels slow to start.
Google's web.dev states that most sites should strive for a TTFB of 0.8 seconds or less. A value above 1.8 seconds is considered poor. The goal is to give the browser a fast start, so the visible parts of the page can appear quickly after.
These numbers are a helpful target, not a hard pass or fail. Some pages that do heavy work on the server will run higher, and that can be fine if the rest of the load is quick. But for most content sites, staying under 0.8 seconds is very achievable with the right setup.
Across our projects we treat that 0.8 second mark as a baseline. For one client, Sachem Hill, we reached a median load time of 0.8 seconds for the whole page, which starts with a fast first byte. Getting the server to respond quickly is where that speed begins.
TTFB matters because it comes first and shapes everything after it. Google's web.dev notes that TTFB precedes user-centric metrics like First Contentful Paint and Largest Contentful Paint. A slow first byte delays those metrics, which affects both user experience and rankings.
The impact on visitors is real. Google research with SOASTA found that the chance of a bounce rises 32 percent as load time goes from one to three seconds. A slow TTFB eats into that budget before the page even starts to draw, so it can push you past the point where people leave.
TTFB is not itself a Core Web Vital, but it feeds the ones that count. If your Largest Contentful Paint is poor, a high TTFB is often part of the reason. You can read how these scores affect rankings in our guide to Core Web Vitals and SEO.
A high TTFB usually comes from slow hosting, distance to the server, too many redirects, or heavy work on the backend. Each request has to travel, connect, and be processed. Any step that drags, from a busy database to a far-away data center, adds to the wait.
Slow or shared hosting is a common culprit. If your server is underpowered or crowded with other sites, it takes longer to respond. Distance is another. A visitor far from your single server waits longer for each round trip, no matter how fast the server itself is.
Backend work adds up too. A page that runs many database queries or builds everything fresh on each visit responds slower than one that serves a ready-made file. Redirects pile on extra trips before the real response even begins. All of these are fixable once you know where the time is going.
You can measure TTFB with free tools like Google PageSpeed Insights, WebPageTest, or your browser's developer tools. Open the network tab, load your page, and look at the timing breakdown for the first request. The waiting portion is your TTFB.
PageSpeed Insights is a good starting point because it uses real-world data where available. WebPageTest gives a detailed waterfall that shows exactly where the time goes. In the browser, the network panel breaks each request into stages, so you can see the wait before the first byte.
Measure from a few locations if your audience is spread out. A fast TTFB near your server can hide a slow one across the world. Testing from different regions shows the real picture and tells you whether distance is part of the problem.
The two biggest wins for TTFB are stronger hosting and a content delivery network. Good hosting responds faster, and a CDN serves your site from a server near each visitor. Together they cut both the processing time and the travel time that make up TTFB.
Upgrading from cheap shared hosting to a solid platform often helps right away. A server that is not overloaded simply answers sooner. Modern hosting built for speed also handles connections and security setup more efficiently, which trims the early steps of the wait.
A CDN attacks the distance problem. By serving cached files from a nearby edge location, it slashes the round trip for far-away users. We covered this in depth in our guide to what a CDN is and whether you need one. For many sites, adding a CDN is the single fastest TTFB fix.
Caching reduces TTFB by storing a ready-made copy of your page so the server does not rebuild it for every visitor. Instead of running queries and assembling the page each time, the server hands over a saved version instantly. That skips most of the backend delay.
There are a few layers of caching. Page caching saves the whole rendered page. A CDN cache stores files at the edge, close to users. For sites built ahead of time as static files, the page is essentially pre-cached, which is why prerendered and static sites often have excellent TTFB.
This is one reason we favor build-time rendering where it fits. When the page is already built and cached, the first byte comes back almost instantly. The server is not thinking, it is just delivering. That is the fastest kind of response you can give a browser.
Redirects and heavy backends hurt TTFB by adding extra work before the real response. Each redirect is a full round trip that must finish before the true page loads. A heavy backend spends time on queries and logic while the browser waits for the first byte.
Redirect chains are sneaky. A link that bounces from one URL to another, then to a third, stacks up delays a visitor never sees but always feels. Cleaning up redirects so each URL resolves in one step removes that hidden tax on every affected page.
For backends, the fix is to do less work per request. Cache results, simplify queries, and avoid rebuilding the same content over and over. Cutting third-party code helps too, since extra scripts can slow the server and the page. Our guide on third-party scripts and performance digs into that side.
Yes, in most cases TTFB is the right place to start. It comes first in the load, so fixing it lifts every metric that follows. There is little point optimizing images and code if the server keeps the browser waiting a second and a half before it even responds.
Start by measuring your current TTFB from a few locations. If it is well over 0.8 seconds, look at hosting, caching, and a CDN before anything else. Once the first byte is fast, your work on images, fonts, and scripts will have a much bigger effect.
If you want a clear read on where your speed is leaking, we do this every day. Reach out through our contact page at phoenix.studio, and we are happy to look at your site's TTFB and map out the fixes that will move the needle.
Tell us where you want to go. We'll tell you how we'd get you there.