TTFB: Why Your Fast Site Still Feels Slow

Web Performance

A client messaged me last month, a little annoyed. Her PageSpeed score was 98 on mobile, green across the board, and yet the site felt sluggish every time she clicked through to a new page. “How can it score that high and still feel slow,” she asked. It is one of the most common questions I get, and the answer is almost always the same thing hiding in plain sight. The score measures how fast the page paints once it starts arriving. It says very little about the wait before anything arrives at all. That first silent pause, where you click and nothing happens yet, is usually time to first byte, and it is the part of speed that scores love to flatter and visitors feel the most.

The gap between a good score and a fast feeling

Here is the thing a lab score tends to hide. Tools like Lighthouse often measure your page from a well-connected machine, sometimes with the server warmed up and the response already cached. Your actual visitor is on a phone, on patchy mobile data, hitting a server that may be a few thousand miles away and may be cold. The score can be beautiful while the lived experience is a beat behind. I wrote about this split before in field data versus lab data, because it is the single most useful idea in web performance and the one people skip. If you are only ever looking at a lab number, you are grading the easy version of the test.

Time to first byte is simply how long the browser waits, after asking for a page, before the first scrap of the response comes back. Nothing can render until that byte lands. So TTFB is the floor under every other metric you care about. You cannot have a fast largest contentful paint sitting on top of a slow first byte, because the clock was already running during that quiet wait. When I am asked to fix a failing LCP, the first place I look is the first byte, which is why I keep coming back to the groundwork in how to fix a failing LCP. Half the time the paint is slow because the response was slow to start, not because the images were heavy.

What actually slows the first byte

Once you know to look, the usual suspects are not mysterious. The most common one I see on marketing sites is a server doing real work on every single request. A page that queries a database, renders a template, and assembles everything fresh each time a visitor arrives will always be slower than a page that was built ahead of time and is sitting ready to serve. This is why I am so fond of static and pre-rendered sites for marketing pages. There is no thinking left to do at request time, so the first byte comes back almost instantly.

Distance is the other quiet tax. If your server lives in one city and your visitor is in another country, their request has to physically travel there and back before anything happens. A content delivery network fixes this by keeping copies of your pages close to people, so the first byte comes from a nearby city instead of a far one. After that it is the ordinary housekeeping. Slow database calls, a crowded shared host, a heavy plugin stack, a redirect chain that adds a full round trip before the real page even loads. None of these show up as a bad score. They just quietly add fractions of a second to the wait that no visitor ever forgives.

Measuring it without guessing

You do not need a developer to find your TTFB. Most speed tools report it, usually tucked under the server response time, and the field data in a Core Web Vitals report will show you what real visitors experience rather than what a lab pretends. I walked through reading those reports in plain language in reading PageSpeed without a developer, and the same habit applies here. Look at the field numbers, not the lab headline. Test from a location that matches your actual audience, not the server room. And test a cold page, not one you just reloaded five times, because a warm cache will lie to you in the most flattering way.

The target is not complicated either. A first byte under a few hundred milliseconds feels instant, and once you cross past half a second or so, people start to register the hesitation even if they could not name it. This connects to a larger point about setting honest goals, which I made in how fast is fast enough. Pick a number your audience would actually feel, then measure against the real world instead of the easy one.

If you take one thing from this, let it be this. A green score is a good sign, not a finish line. The next time your site feels slower than its numbers claim, click a link and count the silent beat before anything moves. That beat is your first byte, and it is almost always the cheapest, most ignored second you can win back. Fix the wait before the paint, and the whole site stops feeling like it is thinking before it answers.