You open a page and nothing happens for a long time. No text, no logo, just an empty tab that waits. That is usually not because of the images or the scripts, since those only start loading once the first byte is in. The first part of that waiting time is called TTFB, time to first byte. This piece shows what we measure about that number, what you can do with it yourself and where the measurement stops.
What TTFB actually measures
TTFB is the time between the moment the browser sends a request and the moment the first byte of the response arrives. It includes the redirects, the lookup of the address, the encrypted connection and the work the server does before it sends anything back. TTFB is not a Core Web Vital, but web.dev calls 0.8 seconds or less good and more than 1.8 seconds poor (consulted October 4, 2026).
Why does that first moment count? A visitor who sees nothing does not know whether the page is coming. They wait or they click away. As long as nothing is on the screen, you have not convinced them of anything. That is why it makes sense to look at this number separately, even if the rest of the page looks fine.
What we measured
Between July 31, 2026 and October 3, 2026 we took 344 TTFB measurements across 22 sites that FWRD hosts. The measurements come from the browsers of real visitors, in the same way the Core Web Vitals are measured. The 75th percentile sits at 435.5 ms. That means three quarters of the visits got the first byte within 435.5 ms, well under the 0.8 seconds that web.dev calls good (consulted October 4, 2026).
Two limits to this number. It concerns a small group of sites, so it says something about those sites and not about the whole web. And the measurement sits in the visitor’s browser, so the distance between that visitor and the server counts too. The same site gives a different number for a visitor nearby than for someone far away.
What this measurement does not say: how long it takes until the page looks complete, and whether a visitor fills in the form. Those are different questions. This measurement answers one: does the first byte arrive fast enough not to block the rest of the visit? For three quarters of the visits on these sites, the answer is yes.
A short wait on the first byte does not make the rest of the page fast.
Where a high wait comes from
A high TTFB usually has one of three causes. The server is slow or overloaded. The page is rebuilt every time, while it could also have come ready from a cache. Or the browser first has to follow a few redirects, and every redirect is an extra round trip. Which cause it is, you cannot see from the page itself. You only see that if you measure it.
How to measure it yourself
Open your site in Chrome and press Ctrl+Shift+I to open the developer tools. Choose the Network tab and tick Disable cache. Reload the page and click the first request, which is the address of your own site. In it, open the Timing tab. The line Waiting (TTFB) is the number you are looking for. Do that a few times, because one measurement says little: a server can be busy at that exact moment. If the wait sits well above the 0.8 seconds that web.dev calls good (consulted October 4, 2026), then look first at the hosting and the redirects in the same list. It is usually not your images, since those only come after that first byte.
Measure again after every big change too, such as a different hosting party or a new redirect. Then you know which change shifted the number, instead of having to guess.
What this does not solve
A short wait does not make the rest of the page fast by itself. A large image or a heavy script decides when the page really looks finished, and that is a different measurement point. That was what the piece about speed you do not fix once was about. Hosting decides part of that wait at the first moment, and what we do for that is on the product page for hosting and domain.
Want to know where your site stands?
Take the free check. You'll see right away what your site needs to get found more often.
Do you want this measured for your own site? You can do that through the diagnosis.
Written with AI by FWRD. Sources and figures are linked in the text.