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 plays an especially big role in websites that run on CMS', or display dynamic content via back‑end and database queries. This is because before your server can even send the first byte, it has to make all the necessary checks (for things like authentication) and queries and run all of the logic to fetch and assemble the content from your database (or databases). Obviously, this takes time ‑ time that delays that the first byte being delivered.

It is worth mentioning here that using a client‑side approach to dynamic content (such as using hydration or rehydration) offers a different set of performance concerns but does not impact TTFB specifically because the process of fetching and transforming data happens on the client side (via JavaScript), and after the page has already been delivered to the visitor's browser. The key differentiation is that with server‑side or back‑end data processing, it all has to occur before the browser receives any data.

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.

At the time this article was published, the advice for React applications included server rendering with renderToNodeStream() or renderToStaticNodeStream(). Those APIs could send HTML earlier, but they did not allow different parts of that markup to hydrate independently. React 18 later deprecated them in favour of its streaming server‑rendering APIs and selective‑hydration architecture.

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.