Add support for First CPU Idle

[hakimelek]

I have been recently doing some tests with the continuity plugins and really enjoyed the new set of metrics it is adding. I have noticed that Time To First Interactive (ttfi) is being added to the list of metrics but actually referring to Time To First Interaction.

boomerang/plugins/continuity.js

Line 671 in 085fd45

* * `c.ttfi`: Time to First Interactive (Base-10)

boomerang/plugins/continuity.js

Lines 409 to 417 in 085fd45

	* ### Time to First Interaction
	*
	* Time to First Interaction (TTFI) is the first time a user interacted with the
	* page. This may happen during or after the page's `load` event.
	*
	* Time to First Interaction will add `c.ttfi` to the beacon.
	*
	* If the user does not interact with the page by the beacon, there will be no
	* `c.ttfi` on the beacon.

Time To First Interaction is defined in another part of the page as when was the first time the user tried to interact (key, click or scroll) with the site, however a more popular definition by the Chrome Dev team for Time To First Interactive is being the time when a page is minimally interactive.

Also, note that Time To First Interactive is being renamed to First CPU Idle for better clarity.

I think it makes sense to rename the Time To First Interactive to Time To First Interaction in line 671 to remove the confusion and also consider supporting First CPU Idle as a new metric to measure when a page is minimally interactive.

[nicjansma]

@hakimelek glad you're using the plugin, and good feedback!

Good catch, Time to First Interactive was a typo in the beacon parameters section, I've fixed it to say Time to First Interaction.

Our RUM Time to Interactive (c.tti) metric is a bit closer to the First CPU Idle definition from Lighthouse. However, it's important to note that while our RUM metrics are similar to the synthetic metrics, we will always differ a bit as RUM doesn't have the same insights (level of detail) that synthetic does. Two main difference between our RUM TTI and Lighthouse TTCI/FCI:

• We don't wait for the network to be quiet
• We declare TTI after just 500ms of CPU idle (waiting for longer periods of idle can cause "lost" beacons)

So we think that while the Lighthouse definitions/names have evolved from Time to Interactive to Time to Consistently Interactive and First CPU Idle, our definition of (RUM) Time to Interactive will probably stay the same for the moment -- the first time the CPU was Idle / no long paints / etc for ~500ms.

[hakimelek]

@nicjansma Thanks for the response!

Your explanation makes sense. Do you think that it is fair to say that even though Synthetic First CPU Idle and Time to Consistently Interactive could happen at two different times of the page load like in the picture below, Boomerang Time to Interactive is probably happening somewhere in between?

I have also seen a lot of cases where First CPU Idle and Time to Consistently Interactive in Lighthouse having the value, probably because the work was done all at once in the beginning leaving the page fully responsive afterwards.

Image Reference

[nicjansma]

@hakimelek Based on our algorithm, I'd expect our RUM Time to Interactive metric to land at either around the Synthetic First Interactive slot above, or, possibly even earlier near ~13-18s (depending on how long there were idle periods there).

It depends on some of the specifics of what else is happening though, and where the RUM Time to Visually Ready metric lands. More details are in https://akamai.github.io/boomerang/BOOMR.plugins.Continuity.html#toc10__anchor.

Looking for feedback, so if you have any thoughts on improving it, please let us know!

[hakimelek]

@nicjansma Great, so maybe this issue should not be about First CPU Idle, since we can say that it is supported if we focus on the definition being a metric to measure when a page is minimally interactive. On the other hand, it might be interesting to add a new metric to measure when the page is consistently interactive. I believe that tti-polyfill could probably a good candidate to implement it.

[nicjansma]

Agreed, adding some sort of RUM Consistently Interactive metric would be nice!

Though one of the challenges with it would be we might have to "wait" a lot longer for it to happen, and each additional waiting second causes an ever-increasing rate of cases where we "miss" the beacon and measurements entirely, due to the browser being closed before we send our beacon.

Still it could be covered by waitAfterOnload -- we'd wait that long for TTI / TTCI, and if it's not ready, just send the beacon without it.

[hakimelek]

I think having the option to measure that is still very nice to have, I am closing this in favor of #250 if further discussion is needed.