Analyzing your SPA TTFB data

Once you've enabled SPA tracking and set up TTFB tracking, you want to analyze the data. Within a non-SPA, the LCP will depend on the TTFB in order for the browser to detect other resources, LCP included.

However, within SPA's, the response of a fetch request might be important for some parts of the page. But the LCP candidate might be known in time already.

SPA TTFB dimensions

We are exposing such information in different ways, helping site owners to understand what happened.

To collect the information below, metric debugging needs to be enabled within your domain's snippet configuration.

Resource priority

Just like with LCP images, we are exposing a file's priority via the resource priority dimension. You will get to see one of the following values:

  • prefetch (finished)
    When the startTime and responseEnd of the detected TTFB resource already happened before user interaction.
    When your site is prefetching many routes, this will help to identify if the resource beloning to the navigations on your site were actually done downloading in time.
  • prefetch (unfinished)
    When the startTime of the detected TTFB resource already happened before user interaction, but the and responseEnd wasn't there yet at that time.
    When this happens, it could slow down follow-up work in your techstack. As a result, we are categorizing this differently.
  • default (x)
    This will indicate that the detected TTFB resource only started to dispatch after user interaction.
    That could indicate a (user input) delay between the user interaction and start of the resource.
  • (+lcp)
    When you see this, it means that the LCP did not start before the detected TTFB resource's responseEnd.
    This could indicate that the LCP detection depended on the full download of the TTFB resource.

Metric element

The metric element will tell you the pathname of the resource that was detected as the TTFB. For NextJS sites, this should be a .json file where the pathname of the resource is matching the URL.

If there are too many false positived, you might want to change your SPA TTFB tracking rules.

SPA TTFB submetrics

Additionally, you can utilize breakdown metrics to further debug your SPA's behaviour.

TTFB waiting time

When it comes to non-SPA TTFB's, there could be a waiting time as the result of redirects, service worker startup, and HTTP cache lookup times. That might not apply in the same way to the TTFB resource that RUMvision will detect.

However, the first dimension discussed above is in fact illustrating that there could be a delay. If such delay happens, it will be exposed via the breakdown's  waiting time sub metric.

TTFB resource download time

Technically, the Time to First Byte metric only measures the time until responseStart, as that's when the first bytes were arrived. This makes sense, as a browser could already start to work with those first bytes.

However, this might be different when it comes to fetch requests. It's often the full response that is needed before your stack's JavaScript is able to act on the response. But you would still like to know about that as well.

Within RUMvision, this information is exposed via the metric loadtime.


The LCP TTFB is part of the so-called metric sub-parts of metric breakdown. Within your domain's technical tab, we will automatically show a breakdown of such sub-parts at the bottom of the page.

Typically and unlike your non-SPA LCP images, your SPA LCP breakdown will not contain any TTFB value as the web-vitals library won't record any TTFB value either. But in reality, there might be a dependency.

However, based on a combination of the data you provided and own reasoning, RUMvision is able to capture the TTFB. When it sees that the TTFB's responseEnd happened after the LCP startTime, we will calculate the TTFB dependancy and collect this as such.