c.tti + c.ttivr not showing up on spa beacons

[quintenp]

Hi there I have a simple angularjs app, what I have noticed is with the continuity plugin, on spa initiators I dont get the c.tti or c.ttivr data points on my beacon.

Any ideas as to why that might happen? I understand you might not trigger domcontentloaded but should c.tti not still show up and use lt?

I have afteronload set to 1 second any tips here?

[quintenp]

Actually looking into it, it seems that the check below blocks it from getting set again, we only ever reset tti when we create a new timeline, in a spa app the only way this seems to happen is on a spa_hard(full reload) is there a configuration to track tti for spa?

https://github.com/akamai/boomerang/blob/master/plugins/continuity.js#L1562

if (tti) {
  return;
}

[nicjansma]

Hi @quintenp!

We do not currently calculate Time to Interactive (TTI), or Time to Visually Ready (TTVR) metrics for SPA Soft Nav beacons, as we do not believe the Page Load / SPA Hard Nav definition of TTI smoothly translates to a similar metric for SPA Soft Navs.

A Page Load or SPA Hard navigation starts out with the entire world (page) needing to be constructed. During the initial navigation, there is no presented view to the user (aka the page is blank) until around TTVR (DCL, First [Contentful] Paint or Hero Images). During and after this stage, the browser is still working hard to fetch/parse/execute the HTML/JavaScript/CSS, which can lead to periods where the page is unresponsive to the user – and thus, the need for a metric like TTI, which helps measure the user's experience and captures when the page is finally Visually Ready and Responsive.

The challenge with SPA Soft Navigations is that at the start of a Soft Nav, the page is already Visually Ready (since the user has clearly clicked on something) and probably Responsive (from the Hard Nav). Since we're starting from a "good" state, what would we report for TTI then? While it's true that a Soft Nav may cause the view to change, and the browser may do some work where the page is briefly unresponsive from fetching/parsing/executing new and old resources for that view, we think it would be hard to come up with a concrete definition of what a Soft Nav's TTVR or TTI would mean, starting from a place that was already Visually Ready and Responsive.

Open to thoughts though!

[judwhite]

@quintenp @nicjansma FWIW on SPA soft navigations I use t_done from RT as an approximation. I detect a soft nav with this bit of code on the server side: if (rt.HTTPInitiator == "xhr" || rt.HTTPInitiator == "spa") && nt.DOMComplete > 0.

[judwhite]

EDIT: Moved details to another issue to prevent issue hijacking

[quintenp]

@judwhite @nicjansma What I found here was quite odd, c.tti was added to spa type beacons. However what happens is the startTime does not reset based on the logic (due to it being a soft nav). This essentially turns the start time into a ever running stopwatch hence you seeing insane tti values @judwhite

You can actually test this @judwhite start your app next to a stop watch and do a few navs you will notice it matches as you soft nav, each nav will have a incremented tti based from your initial page load.

The defect is the c.tti should not be added to the beacons if the reset functions have not been invoked. (in this case spa soft navs) or well reset the start time on soft nav, but things like the framerate monitor would have to be reworked a bit

[nicjansma]

Yeah that sounds like a bug. We'll work on a fix to remove c.tti from all Soft Nav beacons.