TTFB Above Target, The Long Pause Before the Page Starts

Nothing has loaded yet when TTFB runs, the browser is still waiting for the server to answer, and that wait is Time to First Byte. When the report shows TTFB above target, the pause stretched past 800 milliseconds, and because the first byte starts everything, the whole page pays for it. The report names the value and the device, and the same site can answer fast on one run and slow on another, which is often the first clue about what is wrong.

A real record from August in our files shows how it plays out. The page took 1.9 seconds to send its first byte on desktop against the 800 millisecond target, flagged high and costing five points on the desktop performance score. At nearly two seconds the server is rebuilding the page on every visit or answering from far away, and no front-end optimisation fixes that, the fixes below, page cache first, are what cut the number.

What TTFB measures

Time to First Byte measures the gap between the browser asking for the page and the first byte of the answer arriving. It is not a page speed metric in the usual sense, it never measures content, it measures whether the server is there and how fast it starts talking. The time includes the network trip to the server, the server’s own processing, and any waiting the request does in a queue.

The line the report checks is 800 milliseconds. Inside it the page earns the full TTFB credit, between 800 milliseconds and 1.8 seconds it keeps partial credit, and past 1.8 seconds the finding escalates to high, since at that point the server itself is the bottleneck and no front-end work will save the page. A fast first byte does not make a page fast, the content still has to render, but a slow first byte guarantees the whole page is slow, because nothing can load before it.

Why the first byte holds everything back

Every other metric in the report starts after the first byte. The HTML cannot be parsed before it arrives, so the stylesheets and scripts it names cannot be discovered, and nothing can paint, which is why first paint and largest content carry the TTFB delay with them. A page that answers in two seconds will show a slow FCP and a slow LCP no matter how well optimised the front end is, and the report usually flags several metrics at once when the server is the cause.

The report’s watch note names the tell, cold versus warm. Test the page twice, if the first run is slow and the second is fast, caching is doing its job and the slow run was the server rebuilding the page from scratch, while a page that is slow on every run has no cache to save it. That single test separates a caching problem from an origin problem.

Where the pause actually lives

Location matters more for TTFB than for any other metric, because the network trip is inside the measurement. The test fleet sits mostly in Cape Town, with a share of runs from Europe and North America, so a site hosted in South Africa answers a Cape Town run faster than one hosted overseas, all else equal, and the same distance cost applies to your own visitors.

Part of the trip is pure distance, and part of it is the getting-acquainted round trips. Before a new visitor’s request reaches the server, the browser resolves the domain, opens the connection, and negotiates the encryption, and each of those steps is a round trip to the server. TLS 1.3 cut the handshake to a single round trip, and HTTP/3 goes further with instant resumption for repeat visitors, both of which are host and CDN settings rather than page code. Our global data shows the modern versions are already the norm, 91 percent of tested sites negotiate TLS 1.3 and close to half answer over HTTP/3, so a site still using the old handshake has a question worth asking its host.

When the server is not far away and the first byte is still slow, the work is happening server side. An uncached page rebuilds itself on every request, running the application and querying the database before it sends anything, and heavy plugins, page builders, and slow queries stretch that work into seconds. Redirects add their own round trips, every hop from one URL to the next is a fresh request before the real page can start.

Cache, edge, and a lighter origin

Turn on page caching. The single biggest fix for a slow first byte is stopping the server from rebuilding the page on every visit. WordPress sites get this from a caching plugin or from the host’s own cache, hosts on LiteSpeed pair the server with the LiteSpeed Cache plugin, whose page cache serves the stored HTML without running the application or querying the database, and most control panels expose the same idea as a host-level cache setting. After it is on, the cold and warm test above shows the difference on the spot.

Let a CDN answer from the edge. A CDN such as Cloudflare keeps copies of the site at points around the world and answers requests from the closest one, which removes most of the network trip from the first byte. The catch is that CDNs cache images and scripts by default but pass the HTML through to the origin unless a cache rule says otherwise, so the page itself needs to be cached at the edge too, and once it is, a repeat visitor gets the page from the edge even when the origin is slow, which is exactly the cache hit the finding’s fix note describes. A newer edge feature, 103 Early Hints, does not shorten the wait for the first byte itself, but it sends the page’s critical file hints while the HTML is still being rendered, so the browser starts fetching them instead of sitting idle.

Give the origin less to do, then look at the host. Deactivate plugins nothing uses, avoid themes and builders that assemble the page on every request, and let the host turn on the fast PHP mode and an object cache, which are usually one-click settings in the control panel. Page caching only covers the pages every visitor sees in the same form, personalised pages, a logged-in view, a checkout, have to be built per request, and for those the object cache is the real fix, it stores the expensive database results so each build skips the slow queries, with the database itself as the next suspect when those pages stay slow. If the first byte stays slow after all of that, the answer is the hosting itself, a shared plan that is oversold, a server in the wrong country, or an origin that is simply underpowered, and that becomes a question for the host, with this finding from the report as the evidence.

One route will not help here, compression. Shrinking the stylesheets and scripts makes those files arrive faster once the server has started answering, but it does nothing for the wait before the first byte, which is why the compression fix belongs to the FCP guide in this series and the caching fix belongs to this one.

Watching the first byte get faster

Run the test again after each change, and run it twice so the cold and warm difference is visible. The value appears on every run, which makes the slide toward the 800 millisecond line easy to follow. Our own site answers in about 200 milliseconds on desktop and slightly less on mobile, comfortably inside the target, and the TTFB finding has not appeared in our reports.

The global analytics page aggregates every test we run, and its averages show the typical first byte at about half a second on desktop and just over that on mobile, inside the 800 millisecond target, with the slowest ten percent of sites averaging around one second, past the line but short of the worst cases. Slow TTFB in the seconds is the exception rather than the rule, so when a report flags it high the cause is usually structural, the caching, the CDN, or the host itself, and those are exactly the fixes above.