Fix & Identify Time to First Byte (TTFB) issues

Find and Fix Time to First Byte (TTFB) issues

In our previous article we talked about the Time to First Byte. If you would like to read up on the basics this is a great place to start!

In this article I will focus on identifying the different Time to First Byte issues and then explain how to fix them!

TTFB TIP: most of the time the TTFB will be much worse for first time visitors since they do not have a DNS cache for your site. When tracking the TTFB it makes a lot of sense to distinguish between first time and repeat visitors

Step 1: Check the TTFB in search console

"The first step to recovery is admitting that you have a problem". So before we do anything to fix the Time to First Byte let's make sure that we really have a problem with the TTFB.

Unfortunately the Time to First Byte is not reported in Google Search console so we need to fall back to pagespeed.web.dev to query the CrUX data of our site. Fortunately the steps are easy: just navigate to pagespeed.web.dev, enter the url of your page and make sure the 'origin' button is checked (since we need site-wide data and not just homepage data). Now switch between Mobile and Desktop and check the Time to First Byte for both device types

In the example below you will see a site that is failing the core web vitals because of a high TTFB.

Step 2: Set up RUM tracking

The Time to First Byte is a tricky metric. We cannot simply rely on synthetic tests to measure the TTFB because in real life other factors will contribute to fluctuations in the TTFB. To get answers to all questions above we need to measure the data is real life and log any of the problems that might happen with the Time to First Byte. This is called Real User Monitoring and there are several ways to enable RUM tracking. We have developed Core/Dash just for these use cases. Core/Dash is a low cost, fast and effective RUM tool that just gets the job done! Of course there are many RUM solutions out there and they will also do the job (at a higher price though)

How to think about the TTFB: Imagine a web server is a restaurant kitchen, and a user requesting a webpage is a hungry customer placing an order. Time to First Byte (TTFB) is the span of time between the customer placing their order and the kitchen starting to prepare the food.
So the TTFB is NOT about how fast the entire meal is cooked (First Contentful Paint) and served (Largest Contentful Paint), but rather how responsive the kitchen is to the initial request. 
RUM Tracking compares to surveying the customers to understand their dining experience. You might find that seated further away from the kitchen receive less attention from the waiter and get served later or that repeat customers get a preferred treatment while new visitors have to wait longer for a table 

Step 3: Identify Time to First Byte issues

While Google's Chrome User Experience Report (CrUX) provides valuable field data, it doesn't offer specific details about the causes of high TTFB. To effectively improve TTFB we need to know exactly what is going on at a more detailed level. At this point it makes sense to distinguish between overall failing TTFB and TTFB failing under specif conditions (although in reality there will always be a mix).

3.1 TTFB is failing overall

1. Check for general poor 'request times': Poor request times means that the 'problem' is with the time it takes the server to generate the page. This is the most common cause for poor TTFB scores! 
2. Check for other poor TTFB subparts: The TTFB is not just a single metric but can be broken down into multiple parts that have their own optimization potential. If the waiting duration, cache duration, DNS lookup duration or the connection duration are slow you would likely need to tune your server settings or start looking for better quality hosting. 

3.2 TTFB is failing under specific conditions

1. Country segmentation: Understanding the geographical distribution of high TTFB is important, especially for websites with a global audience. If you are serving your pages from 1 server in just one country (without CDN edge caching ), the physical distance between the user's location and the server hosting the website will cause all sorts of delays and will impact the TTFB. 
   
2. Cache segmentation: Caching can reduce TTFB, by skipping the server side generator of the HTML Unfortunately it is common that caching is disabled or bypassed for many reasons. For example caching can be disabled for logged-in users, shopping carts pages, pages with query strings (e.g., from Google Ads), search result pages, and checkout pages. If your website uses (edge) caching use RUM tracking to check the cache hit ratio!
   
3. Page (cluster) segmentation: The difference in Time to First Byte performance (or the lack of difference) between pages or page types is another thing we need to determine. Knowing which pages fail the TTFB metric will give valuable insights in how to improve the time to fist byte. 
   
4. Redirect segmentation: Redirect time gets added directly to the TTFB. Each redirect adds extra time before the web server can start loading the page. Measuring and eliminating unnecessary redirects can help to improve the TTFB.
   
5. Other segmentation: While segmenting by the above variables covers the usual suspects every site is unique and has its own challenges. Fortunately RUM tracking is designed to allow segmentation by many more variables like Device RAM, Network Speed, Device Type, Operating system, custom variables and much much more. 

Step 4: Zoom in to problems and fix!

The sub-parts of the Time to First Byte (TTFB) are:

• Waiting + Redirect (or waiting duration)
  
• Worker + Cache (or cache duration)
• DNS (or DNS duration)
• Connection  (or connection duration)
• Request (or request duration)