Reduce the Waiting Duration Sub-part of the Time to First Byte

Reduce the Waiting Duration of the Time to First Byte

This article is part of our Time to First Byte (TTFB) guide. The waiting duration is the first sub-part of the TTFB and primarily consists of redirect time and browser queuing. A high waiting duration is almost always caused by unnecessary redirects that add round trips before the server can begin processing the actual request.

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 covers 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 read 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 is 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.

Types of Redirects and Their Impact

Not all redirects are equal. Understanding the different types helps you prioritize which redirects to eliminate first:

A single redirect typically adds 50 to 300 milliseconds to the TTFB depending on the network conditions and server response time. When two or three redirects chain together, those times compound and can push the TTFB well above the 800ms "good" threshold.

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 increases TTFB. Each redirect in the chain adds its own processing time, adding to the delay before the first byte of actual content is received.

A common example of a redirect chain:

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

In this example, three redirects occur before the browser receives any content. The first redirect (HTTP to HTTPS) can be eliminated with HSTS. The second and third redirects can be eliminated by updating internal links to point directly to the final URL.

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 sent by the server.

One might think that JavaScript redirects should be preferred since they do not add to the Time to First Byte. Unfortunately JavaScript redirects are a lot slower for real users and will cause 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.
• Crawl budget: Search engine crawlers follow redirects, which means each redirect consumes additional crawl budget. For large websites this can slow down the discovery of new or updated content.

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 in great detail.

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

How to Audit Your Site for Redirects

A systematic redirect audit involves three steps:

Step 1: Crawl Your Site

Use a crawling tool (such as MarketingTracer, Screaming Frog, or Sitebulb) to crawl your entire website. The crawler will report all internal URLs that respond with a 3xx status code. Export the list and sort by the number of incoming internal links pointing to each redirected URL.

Step 2: Identify Redirect Chains

Filter the crawl results for any URL that redirects to another URL that also redirects. These chains should be fixed first because they multiply the TTFB penalty.

Step 3: Fix and Verify

Update your internal links to point directly to the final destination URL. After updating the links, re-crawl to verify that the redirects are no longer triggered from internal navigation. Use the following JavaScript snippet to detect redirects from the browser:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

How to Minimize 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 redirects or redirect chains occur when a single redirect does not redirect to the final location of the resource. These types of redirects put more 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 and HSTS

HTTP to HTTPS redirects are one of the most common redirect types. Every visitor who types your domain without "https://" or follows an old HTTP link will experience a 301 redirect. The Strict-Transport-Security header (HSTS) eliminates this redirect for returning visitors by telling the browser to always use HTTPS.

To enable HSTS, add the following header to your server response:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Here is what each directive means:

• max-age=31536000: the browser will remember to use HTTPS for this domain for one year (31,536,000 seconds).
• includeSubDomains: applies the HTTPS requirement to all subdomains as well.
• preload: allows your domain to be included in the browser's built-in HSTS preload list, which means even the very first visit will use HTTPS without a redirect.

To submit your domain to the HSTS preload list, visit hstspreload.org. Once your domain is on the preload list, browsers will never make an HTTP request to your domain, completely eliminating the HTTP to HTTPS redirect for all visitors.

In Apache, you can add HSTS with:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

In Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

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 remain.
2. Handle redirects on the server level. The preferred redirect method is a 301 redirect. 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.

Further Reading: Optimization Guides

Related guides:

• 103 Early Hints: reduce perceived TTFB by sending resource hints while the server processes the full response.
• Configure Cloudflare for Performance: optimize your CDN configuration to reduce redirect chains and improve global TTFB.

TTFB Sub-parts: Complete Guides

The waiting duration is one of five sub-parts of the TTFB. Explore the other sub-parts to understand the full picture:

• Fix and Identify TTFB Issues: the diagnostic starting point for all TTFB optimization.
• Cache Duration: service worker performance, browser cache lookups, and bfcache.
• DNS Duration: DNS provider selection, TTL configuration, and dns-prefetch.
• Connection Duration: TCP handshake, TLS optimization, HTTP/3, and preconnect.
• Request Duration: server processing time, database queries, and backend optimization.