TTI is reported as ~10 times what main thread work is

Not sure if this is the right place to ask, it’s about the score at https://developers.google.com/speed/pagespeed/insights/ and not with a local LH. Sorry if this is the wrong place for this question!

Provide the steps to reproduce

1. Run LH on http://scope.northeurope.cloudapp.azure.com/

What is the current behavior?

TTI is reported as 26s when main thread work is 3.3s and JS execution time is 2.0s

What is the expected behavior?

I’d expect our TTI to be a bit more than the total of main thread work. If I look at other sites TTI seems to be around main thread work * 0.1 but for us it’s almost main thread work * 10. One thing reported is that we don’t serve images in next gen formats which has a potential saving of 13s, but image loading shouldn’t impact TTI, right?

Environment Information

• Affected Channels: https://developers.google.com/speed/pagespeed/insights/
• Lighthouse version: -
• Node.js version: -
• Operating System: -

EDIT: Pin code is 2016 if you want to look at the site, we automatically let the LH user agent through.

[andersekdahl]

Big thanks for your quick answers, now I know how to tackle this!

[patrickhulce]

So if we have these large images that aren’t optimized and take 20s to load and we also have an onload event listener on them, that wait time gets included in TTI?

Roughly, yes.

That is, even if nothing happens between 5s and 25s except for image loading our TTI will be 25s?

Assuming you don’t reach network quiet before then, yes 😃

We have a bunch of prefetch directives for additional JavaScript files. Could it be that these are downloaded in the background but affects TTI since the network isn’t quiet?

I only briefly looked at this page, but I would guess that contributes significantly, yes.