Support for JAMStack-style single page apps?

[xjamundx]

In JAMStack-style apps there is often a quick page load time followed by an immediate AJAX call to get the data needed to render the full application. This has, in my experience, resulted in a TTI being called much too quickly by Boomerang.

Even with the fairly recent support for largestContentfulPaint as part of the TTI calculation, it doesn't seem to wait long enough for the AJAX call to return before calling TTI, which means the correct LCP, which comes later, gets ignored.

We also added the AutoXHR plugin (version 1.720) and as far as we can tell it doesn't do anything to help this problem except for fire an extra beacon when the XHR comes back. There's not a clear way to calculate a new initial TTI from that second beacon. (I also noticed that the XHR Snippet provided overrides XHR, but not fetch?)

Within the JAMStack/React community there's a ton of emphasis on lighthouse scores and to a lesser extent chrome's web vitals suite. Does Boomerang provide a solution for apps like this? Would it like to? Is any work currently being done to provide support for them? Or did I just do something wrong?

[querymetrics]

@xjamundx Can you share your config settings?

You can enable Fetch API monitoring with AutoXHR.monitorFetch= true.

A good starting point for a SPA site config would be

History: {
    enabled: true
},
AutoXHR: {
    monitorFetch: true
},
instrument_xhr: true,
autorun: false

[xjamundx]

Thanks @querymetrics, let me break down my specific questions:

1. Is there a reason the auto-xhr snippet (The before boomerang load snippet) doesn't include support for fetch calls? Does it not need to for some reason?
2. If I have a 2s AJAX call at the start of my page that is required for critical content, and TTI is getting called at you know 400ms is there any way to adjust that to take into account my long AJAX call?
3. Is there anything we can do to ensure that LCPs that get fired after TTI is called, force a re-calculation of the TTI score?

My config looks very similar to what you have, but looking through the source I'm not seeing how the long AJAX call would be taken into account.

Thanks!

[querymetrics]

1. Is there a reason the auto-xhr snippet (The before boomerang load snippet) doesn't include support for fetch calls? Does it not need to for some reason?

That snippet is useful in cases where Boomerang is loaded asynchronously, loads late in the page timeline and misses some XHR calls that are important. It's also useful in cases where a 3rd party JS changes the XHR API and breaks Boomerang support. The snippet forwards the data gathered to AutoXHR once Boomerang loads. If Boomerang loads early enough it isn't needed. That snippet does not support Fetch.

XHR and Fetch monitoring are built into the AutoXHR plugin and that snippet isn't used in 99% of cases.

2. If I have a 2s AJAX call at the start of my page that is required for critical content, and TTI is getting called at you know 400ms is there any way to adjust that to take into account my long AJAX call? My config looks very similar to what you have, but looking through the source I'm not seeing how the long AJAX call would be taken into account.

SPA page load time and TTI time are different. TTI could happen before the page is loaded.

The XHR should be taken into account in the SPA page load time if Boomerang loads early enough and is properly configured.

TTI doesn't take network requests into account. You could use the Continuity.ttiWaitForFrameworkReady config option. See https://github.com/akamai/boomerang/blob/master/plugins/continuity.js#L333 to give a lower bound to the TTI calculation.

For examples of SPA page load time, you could take a look at the mPulse SPA documentation, most of it will apply to the open source Boomerang as well: https://developer.akamai.com/tools/boomerang/xhr-spa

[xjamundx]

Thank you so much @querymetrics!

I did edit and add a 3rd question about Largest Contentful Paint, though I think your answer mostly covered it.

We'll keep digging and see if we can find a way to achieve what we want!

[xjamundx]

It looks like the thing I want to measure is referred to in Boomerang as SPA Hard Navigations and that that beacon includes an updated LCP score as the following from the docs:

For SPA hard navigations,

Back-End time is calculated with the same timers as a traditional navigation, where the root HTML’s timestamps are used for calculation: NavigationTiming navigationStart until responseStart.

Front-End time is the Total time minus the Back-End time.

The main problem I have now is just that we don't start capturing these events soon enough in most cases, because we use the iframe snippet which can cause quite a delay, but that's something I can work out with my team.

Thanks a lot!