minValue not behaving as expected?

[gabe-lyons]

In the documentation minValue is described as "The lower bound to start forward-searching for the quiet window. If no value is set, the default is after the DOMContentLoaded event."

Looking at the code, it seems like the only time minValue is used is in the return value of computeFirstConsistentlyInteractive:

tti-polyfill/src/firstConsistentlyInteractiveCore.js

Line 36 in 4b5058e

return Math.max(maybeFCI, minValue);

Then that value is immediately resolved:

tti-polyfill/src/firstConsistentlyInteractiveDetector.js

Line 380 in 4b5058e

if (maybeFCI) {

In this case it seems like the forward-searching for the quiet window happens first, and then the evaluated tti is just compared with minValue at the end. Am I missing something? Ideally I would like a minValue parameter that behaved as per the description. A motivating example would be measuring tti on a client-side route, where a batch of activity would occur well after the initial page load.

[philipwalton]

@gabe-lyons thanks for the report! So after looking at the code and documentation, I think the documentation is wrong -- at least with respect to the original intention of the minValue option.

That being said, I've discussed with some of my colleagues and we do think there'd be value in exposing something like a searchStart option that does essentially what you're asking for. It would require a fairly big change to the current code though, because at the moment it stops detecting long tasks as soon as it finds an initial 5-second window, so we'd have to update it to keep listening for long tasks indefinitely if that option were passed.

[gabe-lyons]

@philipwalton thanks for your response. Would there be any performance implications to having the polyfill continue listening for long tasks? Another possibility could be having an API to tell the polyfill to start listening again, we could make a call to that just before we initiate a client-side route.

[philipwalton]

It's probably not a huge performance concern, though depending on how we implemented it, it could complicate the API. If we supported passing a startSearch value that was in the past, then obviously we'd need to listen all the time.

Another possibility could be having an API to tell the polyfill to start listening again, we could make a call to that just before we initiate a client-side route.

For your specific case, and if this is about simulating TTI for route changes in a SPA, then you might try experimenting with doing the following:

1. Add your own performance observer for long tasks immediately before loading a new route.
2. Assuming your router has some signal to indicate when the route has changed, wait for that signal.
3. Add a 5-second timeout.
4. In your long tasks callback, clear and restart the timeout any time a long tasks occurs.
5. After the 5-second timeout finishes, disconnect the performance observer and get the last long tasks that was emitted.

The end of the last long task will be your TTI value (if there's no long tasks, it'll be the point at which the router finishes loading the route).

[gabe-lyons]

@philipwalton okay, thank you that's super helpful! Any specific reason you aren't also using the 2-network heuristic in the 5 step example above?

[philipwalton]

The 2-network heuristic is intended for generic situations where we don't know whether additional scripts are about to be run (which may trigger additional long tasks). Waiting for the network to quiet is a guess that that's not about to happen.

But if you know what scripts you're loading, then you don't need to guess since you can just wait until you know you're done.

One possible exception is if you have third-party iframes where you don't know what they may be loading, but there's no way to polyfill that case anyway.

[mutdmour]

@philipwalton would you accept PR for this? we have a SPA we are interested in observing TTI as pages change.

A suggested api could be something like:

ttiPolyfill.getFirstConsistentlyInteractive({
     continueToListen: true,
     searchStart: 1569749878922 // epoch
  }).then((tti) => {
  // Use `tti` value in some way.
});