Reduce the waiting duration sub-part of the Time to First Byte

The waiting duration consists of redirects and other browser processes. Understand the sub-part of the TTFB to reduce the total time to first byte

Arjen Karel Core Web Vitals Consultant
Arjen Karel
linkedin

Reduce the waiting duration of the Time to First Byte

The Time to First Byte (TTFB) can be broken down into the following sub-parts:

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

Looking to optimize the Time to First byte? This article provides an in-depth analysis of the waiting duration part of the Time to First Byte. If you are looking to understand or fix the time to first byte and do not know what the waiting duration means please what is the time to first byte and fix and identify time to first byte issues before you start with this article

The waitingDuration part of the time to first byte consists of some time where the browser might be performing other tasks before it will start to connect to a webserver and redirect time. When Real User Monitoring (RUM) data shows a high waitingDuration  you can be pretty sure that the culprit is redirect time

Redirects can have a large impact on Time to First Byte (TTFB) because each redirect gets added to the time it takes for a browser to receive the first byte of data from a server. Here's how redirects influence TTFB:


How do redirects increase the Time to first byte?

Redirects are typically included in the full TTFB measurement (see blue box). This means that the time taken for all redirects is factored into the overall TTFB score, potentially making it appear higher than expected.

When a page is redirected these are the usual steps that occur:

  • The browser sends an initial request to the original URL.
  • The server processes this request and responds with a redirect status code (e.g., 301 or 302).
  • The browser then sends a new request to the redirected URL.The server processes this second request and begins sending the actual content.

Increased Server Processing Time

This additional processing increases the overall TTFB, as each step requires time for the server to handle the request and respond.

Redirect Chains

In some cases, multiple redirects may occur before reaching the final destination. This creates a "redirect chain" that can  increase TTFB. Each redirect in the chain adds its own processing time, adding to the the delay before the first byte of actual content is received.

Network Latency

Redirects often involve additional network round trips between the client and server. This introduces extra network latency, especially if the redirects involve different domains or servers. The physical distance between the client and server for each redirect can further impact the TTFB.

JavaScript redirects vs Server side redirects: Only server side redirects (that work with a 30x redirect header) get added to the Time to First Byte. JavaScript redirects do not get added to the Time to First Byte because a full response (200) has been send by the server.

One might think that JavaScript redirects should be preferred since they do not add ot the time to first byte. Unfortunately JavaScript redirects are a lot slower for real users and will be a cause of poor User Experience,

Impact on User Experience (and SEO)

While redirects are sometimes necessary, their impact on TTFB can have broader implications:

  • User Experience: Slower TTFB due to redirects can delay the initial rendering of the page, potentially frustrating users.
  • SEO: Although TTFB is not a direct ranking factor, it influences other metrics like Largest Contentful Paint (LCP), which is a Core Web Vital considered by search engines.

How to measure TTFB issues caused by redirects

To find the impact that real users experience caused by redirect you will need to use a RUM tool like CoreDash. Real user monitoring will let you track the Core Web Vitals into great detail.

In CoreDash simply 'click on redirect count' to visualize your data segmented by redirect count. Then, for example click on a the ' 1 redirect' segment to filter the RUM data by '1 redirect' and view all affected urls.  

ttfb coredash redirect count 3

How to minimizing Redirect Impact

As a general rule follow these 3 simple steps to avoid redirect issues:

  • Minimize the use of redirects where possible.
  • Avoid redirect chains by updating links to point directly to the final destination URL.
  • Use server-side redirects instead of client-side redirects when possible, as they are generally faster.

Same origin redirects. Same -origin redirects originate from links on your own website. You should have full control over these links and you should prioritize fixing these links when working on the Time to First Byte. The typical method of finding these internal redirect is by using any of the available tools out there that will let you check your entire website for redirects.

Cross-origin redirects. Cross-origin redirects originate from links on other websites. You have very little control over these. For high impact links that generate a lot of traffic consider contacting the webmaster of the site to update the linked URL.

Redirect chains. Multiple redirect or redirect chains occur when a single redirect does not redirect to the final location of the resource. These types of redirect put more of a strain on the Time to First byte and should be avoided at all costs. Again, use a tool to find these types of redirects and fix them!

HTTP-to-HTTPS redirects. One way you can get around this is to use the Strict-Transport-Security header (HSTS), which will enforce HTTPS on the first visit to an origin, and then will tell the browser to immediately access the origin through the HTTPS scheme on future visits.

In general we recommend to:

  1. Regularly check and update your internal links! Whenever you change the location of a page update your internal links to that page to ensure no references to the earlier page location remains.
  2. Handle redirects on the server level. Where the preferred redirect method is a 301 redirect.t. A 301 redirect is a permanent redirect, while a 302 redirect is a temporary redirect. Temporary redirects, for example ,might not get updated in search engines.
  3. Use relative URLs: When linking to pages on your own website, use relative URLs instead of absolute URLs. This will help prevent unnecessary redirects.
  4. Use canonical URLs: If you have multiple pages with similar content, use a canonical URL to indicate the preferred version of the page. This will help prevent duplicate content and unnecessary redirects.


Reduce the waiting duration sub-part of the Time to First ByteCore Web Vitals Reduce the waiting duration sub-part of the Time to First Byte