Enable detailed TTFB tracking

RUMvision did not stop at the default support of the web-vitals library. We have been experimenting with tracking TTFB's of soft navigations. We did this to prevent fetch requests and their timing from becoming a black hole.

Different fetch strategies per platform

For example, before actually painting new contents to the screen, your stack might have its own characteristics regarding what is being fetched on user interaction. It could fall in one of the categories described below.

API call on click

Your stack might call an API endpoint on user interaction, for example a click. This means that the next paint and potentially LCP depends on the response of that API call.

In this case, there is a direct relation. And as a sight owner, you want to have eyes on such performance.

Full prefetching

Fetching behaviour can even vary per platform/framework. Depending on your configuration, your site might prefetch all information in advance. As a result, no real fetch for actual contents will be done. Changing contents is then able to happen immediately.

However, you still want to be on top of regressions within prefetching behaviour. The amount of pages and thus prefetched resource might grow over time. This could harm overall performance within the first pagehit. If a user starts to interact immediately, the data might not be available yet, causing a delay towards the next paint and even LCP of the next page.

Other scenario's

We have even seen scenario's where two endpoints were called to get latest routing data, before fetching the contents of page that users tried to navigate to.

But the same applies: you want to stay in the loop. That's why we decided to work beyond the web-vitals library, and add support for TTFB tracking within SPA's. In a flexible way.

Enabling detailed TTFB tracking

In order to enable TTFB tracking within your SPA, you can start by sharing your tech stack via your domain settings. We might have integrated options for your platform already.

If not, you will be able to provide regular expressions for your templates, that will match the API endpoints of the fetch requests. That way, we will be able to pick the right resource that was related to the page navigation. Both out of the box configuration as well as other stacks are covered in the following sub-sections.

Tracking heuristics

To start with, we will report the TTFB of the related resouce that matched the provided regular expression or the heuristics of a platform that comes with support out of the box. Additionally, we introduced a priority flag for these files. We use the priority flag to expose the priority of a file. For example:

  • was it fully prefetched, even before the user interaction took place?
  • did it start to download on mouseover or touchstart, but was not finished yet during user interaction?
  • or did the request to an API endpoint start after user interaction.

Do note that the "metric debugging" feature needs to be enabled in your configuration settings in order to collect this data. Additionally, we will also report any waiting time between the start of a user interaction and when the fetch started to happen.

This allows for extensive debugging when your users are suffering from long delays between page transitions.