Short code snippet to track both redirect time and full TTFB

Short code snippet to track both redirect time and full TTFB

Here are ways to log the redirect time and TTFB. Just copy & paste it into Chrome's JS Console to see the complete waiting time (including redirect time) when clicking on your own Google + FB Ads, for example.

There are multiple ways to track waiting time and TTFB. Using the official web-vitals library is a great one, for example. You might then want to use their attribution build when pulling its JS from a CDN.

If you're going to end up using the web-vitals library, be sure to use:

  • Load the "attribution" build (using a classic script)
  • and add webVitals.onTTFB(console.log); to the function calls list.

But there's a shorter way:

Short TTFB tracking code snippet

The getEntriesByType method will return a PerformanceEntry object. We want to learn more about navigational characteristics, so we'll be grabbing navigation from the data, and then specifically want to learn more about the main initiaror (the HTML document). So we should use the 0 index.

View to copy the source code

TTFB breakdown

With that in mind, we can pull in numbers. Let's break down the above code snippet.

Waiting time

the web-vitals library is describing this as following:

The total time from when the user initiates loading the page to when the DNS lookup begins. This includes redirects, service worker startup, and HTTP cache lookup times.

To grab this, we need to know the time from initial click (or JS redirect) to the domainLookupStart of the destination page.

Full TTFB

Although not commonly known, the TTFB doesn't only capture the server response time. It also contains DNS lookup time, connection time and waiting time for example. To get the overall TTFB, we want to know the time from the user click (nav.activationStart) to the start of the response of the current page (nav.responseStart).

Additionally, when it comes to the TTFB, it really is only about the "first byte", hence Time to First Byte. The document download time doesn't matter anymore. The reason is that although full HTML might not have been received yet, those first bytes likely already contains valuable information for the browser to start working on.

Timing pane in DevTools Network

You can also spot the timing charactertics per document in the Network pane of DevTools. See below, which you will be able to see when clicking on any resource in your Network panel, and then going to the "Timing" tab.

So, whenever comparing your TTFB with the timing characteristics in your DevTools, be sure to ignore the Content Download. The Content Download value might still be an indicator to towards your page health, inlined assets and discoverability of resources for example.But that's a topic that is not within the scope of this article.

Additional thoughts

A fair question I received on LinkedIn was as following:

is this script going to capture the full waiting time from the source URL to the very end destination of a redirect chain?

And yes it is! But only when all redirects happened server side.

Client side redirects

Client side redirects are not part of waiting time. For example, when a client side redirect via either JavaScript or meta refresh comes in between, then the nav.activationStart is being reset. An interesting example here is how Twitter is performing their outbound redirects. They are actually using JavaScript.

Query strings in your URLs

When clicking on Google Ads, Facebook Ads or (email)campaign links, URL's will come with query strings. For example gclid, fbclid and utm_* para­meters.

When not taken care of before hand, those query strings related to ads and campaigns are likely to impact your TTFB and then also Core Web Vitals. To prevent this from happening, be sure to properly set up your server side caching strategy.

Saving code snippets

You might forget about this blogpost. But you might actually want to use the code snippet from time to time. To allow you to do so, you can add any code snippet to the DevTools of your browser. A few years ago, I discussed how you can do this in a LinkedIn post. You might want to benefit from this as well.

Tracking waiting time and TTFB of your real users

It can be valuable to track delays during your own page clicks and navigations. For example to analyze what is happening. However, delays might not be as severe on your end, depending on your conditions. Probably a fast device and office WiFi.

However,you're not representative for the masses. To learn if both redirect time, response time and overall TTFB is continuously impacting your business and real user experiences, you should use Real User Monitoring tools.

Via the web.dev pages, Google is also advising to use additional RUM to be able to draw better conclusions. Which is why I started RUMvision as public pagespeed monitoring solution, to be used by any website or webshop owner.