Time to Interactive and requestIdleCallback (lazy-loading third-party scripts)

[rkyoku]

Hi there! 👋

I am trying to optimize a website, and my last step is to lazy-load some third-party scripts (and also some first-party code, but it does not matter).

Technical information is hard to find online, so what I did is create a script that triggers the lazy-loading on either user-interaction (mouse move, touch start, ...) or requestIdleCallback, whichever comes first.

const opts = {capture: false, passive: true};
let _idle = null;

document.addEventListener('mousemove', _lazyLoad, opts);
document.addEventListener('mousedown', _lazyLoad, opts);
document.addEventListener('keypress', _lazyLoad, opts);
document.addEventListener('touchstart', _lazyLoad, opts);
document.addEventListener('touchmove', _lazyLoad, opts);
document.addEventListener('scroll', _lazyLoad, opts);

if ('requestIdleCallback' in window)
	_idle = window.requestIdleCallback(_lazyLoad, {timeout: 3000});
else
	_idle = setTimeout(_lazyLoad, 3000);

Problem is, requestIdleCallback is fired first, but it actually increases my TTI.

What I don't understand, is that:

• Browser being idle means that it should be interactive, right? Which means that TTI should be final/unmodified by now, and whatever happens next should not be increasing TTI
• I checked the "Performance" tab and I could see nothing related to my website's first-party code (or any other work, for that matter) triggered after the "idle" callback

Still, my TTI increased, which decreased my overall performance score in Lighthouse 😭
However, based on the capture above, it seems my actual TTI should be 1.4s and not 6.0s

I even tried adding a 2,000ms timeout in the idle callback to make sure that no other work was in progress for the browser, and that TTI was done calculating. But nope, it actually increased my TTI by another 2 seconds...

Do you please have any technical information that I could read on how to lazy-load third-party code so that it doesn't worsen TTI (or any other rating for that matter)? More widely, how to optimize a website for each Lighthouse intermediary score? I did already read multiple Google articles on the topic, and I already optimized so many things, but I reckon I still lack some information.

Some nice guy on the Google forum seemed to advise me not to use requestIdleCallback for lazy-loading scripts as it was supposedly unreliable, but to only check for user interaction (which seems to also be the option chosen by some widely used WordPress performance plugins).

Still, I don't understand why requestIdleCallback would not be a fit for this, and why it would not be reliable.

I can confirm that removing it and only using user-interaction detection works fine... but I would like to understand why... why is it not reliable, and what would be the official, built-in method (like requestIdleCallback and requestAnimationFrame) for lazy-loading scripts when browser is idle/interactive.

Thank you so much in advance for any enlightenment 🙏

PS: I cannot use a web worker because 1) it will still count in my performance rating and 2) the aforementioned third-party script modifies the DOM.

[adamraine]

However, based on the capture above, it seems my actual TTI should be 1.4s and not 6.0s

This is expected when using Lighthouse's default throttling settings. We have a doc for this: https://github.com/GoogleChrome/lighthouse/blob/master/docs/throttling.md.

By default, Lighthouse will apply the throttling settings after a trace is taken (simulated throttling), so the TTI reported by Lighthouse will not match the TTI taken from a normal performance trace. This is why Lighthouse reports a TTI of 6s when your trace shows a TTI of ~1.4s.

Throttling also increases the length of tasks, which could push additional tasks over the 50ms threshold to be considered "long tasks".

Browser being idle means that it should be interactive, right? Which means that TTI should be final/unmodified by now, and whatever happens next should not be increasing TTI

I don't think this is true. The function doesn't seem connected to TTI.

According to mozilla docs the callback is executed when the event loop is idle, not necessarily when the browser is 5s removed from the last "long task". Additionally, I don't think it checks for any in-flight network requests (max of 2 in-flight requests are allowed to reach TTI).

I even tried adding a 2,000ms timeout in the idle callback to make sure that no other work was in progress for the browser, and that TTI was done calculating. But nope, it actually increased my TTI by another 2 seconds...

The timeout parameter doesn't delay the callback by an extra 2s, it forces the callback to be executed after a 2s timeout regardless of the idle status.