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
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
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:
Table of Contents!
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 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 redirects 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.
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 redirects 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:
- 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 remain.
- 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.
- Use relative URLs: When linking to pages on your own website, use relative URLs instead of absolute URLs. This will help prevent unnecessary redirects.
- 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.
Stop Guessing, Start Measuring
I use Core/Dash to optimize my clients sites. So Should You.
- Easy set up.
- Over 5000 happy clients
- Free trial, No strings attached