Why is Time to First Byte (TTFB) Important?

Time To First Byte (or TTFB as it is acronymised) measures the time from starting a request until the first byte of the response arrives. It is a useful diagnostic for connection and server delay, and it can affect later loading milestones, but it is not itself a Core Web Vital or a simple, direct ranking signal.

Google's Page Experience Metric work did not make TTFB a standalone Core Web Vital. TTFB remains useful when diagnosing a page, and application and infrastructure decisions can both influence it.

What is Time to First Byte?

When a user visits your website, their browser makes a request to your server for the page and its content so that it can then display it to the visitor. This is all very much 'Web Development 101', and whilst it might seem simple, plenty of developers and website owners overlook how important the actual server and infrastructure their application sits upon is when it comes to speed.

Time To First Byte can be particularly useful when diagnosing a CMS or other dynamic page. Any authentication, database queries or rendering work that blocks the first response flush delays that first byte. The server does not necessarily need to finish the whole page first: a streaming response can send an initial shell and deliver later HTML as more work completes.

Fetching data in the browser after the document arrives does not change that document's already‑recorded TTFB. Those later requests have their own response timings, and the work can still delay useful content. Hydration is the step that attaches application behaviour to server‑rendered HTML; it is not another name for client‑side data fetching. On the server, the question for TTFB is which work must finish before the first flush, rather than whether any server work remains afterwards.

A quicker initial response gives later loading work an earlier start, but it does not guarantee a fast page. Response size, client‑side work, render‑blocking resources and how quickly the largest element is discovered can still dominate the experience.

How Important is Time to First Byte?

Time To First Byte is a useful diagnostic. Largest Contentful Paint is measured from navigation until the largest qualifying content element is rendered in the viewport, so it includes TTFB delays. In a performance breakdown, TTFB is the first of four elapsed‑time portions rather than a measure of how much content has arrived.

If you've got this far, then we all already know how important speed is when it comes to the web, and building for the web. TTFB is a diagnostic input rather than a promise about rankings or the complete user experience. In simplest terms: a slow initial response can delay everything that follows, but it is only one part of the page's loading behaviour.

When I worked with John Lewis, one of our key performance indicators was loading time. When we became involved, the platform was significantly bloated, particularly by unnecessary third‑party extensions, which meant the pages loaded slowly. Aside from many other things, our work reduced the average page loading time by more than 75%, which in turn showed a reduction in bounce rates and a pronounced upsurgence in sales.

Google provides some specific guidance when it comes to optimising Time To First Byte on particular stacks. For instance, when it comes to WordPress, the recommendation is to select a good optimisation plugin and to pick (or build) a well‑optimised theme. You should also look to strip back and use as few plugins as possible (as each plugin has its own bits of logic that will need to run before that first byte can be delivered), as well as utilise the cache.

For React applications at the time of publication, renderToNodeStream() could stream server‑rendered HTML for later hydration. renderToStaticNodeStream() also produced a stream, but its static HTML could not be hydrated at all. Neither provided the later selective‑hydration behaviour; the two APIs should not be treated as interchangeable.

Caching (on both the server and client sides) obviously really cuts down on Time To First Byte. We already know that TTFB is influenced by all of the logic and queries that have to be made to load a dynamic site, so setting a level of caching in‑between server and end‑user allows the server to generate less and less frequently. Alongside this, the cache can serve the content statically (even improving this further by the use of a CDN), drastically cutting down on response times. The team over at Kinsta managed to reduce TTFB by 90% for the WordPress sites that they host by leveraging a combination of caching and distributed CDN. Of course ‑ and without dismissing what an amazing achievement that is ‑ it does also say an awful lot about the (poor) state of your average WordPress website!

Fortunately, if you're using a static site generator like Gatsby, then a lot of this is already taken care of for you out of the box, although there are any number of further community plugins that can be used to optimise performance even further.

I intend to delve a little more in‑depth into how you can take steps to reduce the Time To First Byte of your website in a future article, but for now, it's worth checking your site with PageSpeed Insights to get an idea of how your site is performing at the moment. Largest Contentful Paint is a separate Core Web Vital with a recommended threshold of 2.5 seconds or less; a slow TTFB consumes part of that elapsed‑time budget before the largest element can render.

* I realise that I've been very narrow in my definitions here today, namely only focusing on Google and their metrics for search engine performance/rankings. The fact is that at the time of writing, Google makes up more than 92% of the Worldwide Market Share, and has been consistently above 90% for the past decade. What this means is that if you are going to expend time and effort into improving TTFB for SEO purposes (rather than just for your users, although the two often go hand‑in‑hand), then Google is really where your focus has to be placed.