Minimize main-thread work Other category

[ghost]

What is it that makes up the Minimize main-thread work Other category? I keep getting this warning when testing my site.

Tested URL: https://www.tomasmoberg.org Lighthouse version (PageSpeed Insights): 6.3.0 Simulation: Mobile

Lab Data: First Contentful Paint 1.0 s Speed Index 1.0 s Largest Contentful Paint 1.1 s Time to Interactive 1.0 s Total Blocking Time 0 ms Cumulative Layout Shift 0

Minimize main-thread work 5.5 s

Other | 4,668 ms Rendering | 0 ms Script Evaluation | 0 ms

[patrickhulce]

Thanks for filing @gottfridsberg! This appears to be a bug as nothing is happening in the trace of this page. We'll look into it.

tomasmoberg.zip

[patrickhulce]

Two incredible things happening in this trace:

1. There's a random RunTask B event without a matching E 😱 (RunTask to my knowledge up until now was always an X event unless it legitimately wasn't completed when the trace ended).

2. We picked the wrong main thread 😱

For the first one, I grepped my grab-bag directory of old runs and I do see some other stray RunTask B events in a few other traces I had lying around. The problem for us is that this is in fact a legitimate interpretation of these events, DevTools and Chrome seem to just represent these RunTask B events as I events instead, which feels wrong, but I guess we could do that too instead if the extension would be significant.

The second one is more fundamental and concerning. We start tracing on about:blank and use the TracingStartedInBrowser to find the renderer main thread. In this case, the page ended up in a completely new process, not the about:blank one! This has been a theoretical possibility for a long-time, but never actually seen it in person. I guess it's time to finally consider the other event volume approaches.

[connorjclark]

anyway to know how common this is? looking at a bunch of LHRs and seeing if Other is >0 and all the rest is 0?

[thestinger]

It happens with https://grapheneos.org/features and other pages on the site too. I'm curious if there's some common cause leading to it being more common. Tried disabling HTTP/2 and that didn't really seem to impact it.

[shgysk8zer0]

I'm seeing similar issues on multiple sites. Lighthouse 7.3.0 on Chrome 88.0.4324.202

• Minimize main-thread work 4.6 s
• Reduce JavaScript execution time 3.4 s

Until about a month ago, I was getting ~90% or better on my sites. Now, and with practically nothing changed, I was getting low 10% scores. Posted script timings are from after tons of work to improve results (but not really affect real-world performance). I've managed to get back up to 63% by catering to my findings from performance profiling and other tests.

To the best of what I can gather, idle time counts towards script execution/evaluation, which affects Time To Interactive and Total Blocking Time. So using requestIdleCallback() to wait to load an analytics script has tremendous negative effects, as does customElements.whenDefined(). Using a performance profiler with 6x CPU slowdown shows me that my scripts are only taking 100ms - 40ms.

I suspect this might have something to do with the recent addition of top-level await into Chrome, as all of my issues stem from async functions and promises. This applies to someAsyncFunction().then(/*...*/), not just await someAsyncFunction().

Example of "offending" code:

// Wait until load event and browser idle to load non-essentials
loaded().then(() =>  requestIdleCallback(loadAnalyticsScript));

[patrickhulce]

Can you share your URL @shgysk8zer0 ?

[shgysk8zer0]

@patrickhulce Sorry for the false report. It ended up being my bad in implementing a shim for AbortSignal for event handlers. Since I had disabled console.*, I wasn't seeing the "Maximum call stack exceeded" errors, and I also wasn't experiencing the error in any current version of Chrome or Firefox as AbortSignal is supported.

[patrickhulce]

No worries, glad you got it figured out @shgysk8zer0 :)

[connorjclark]

related: https://bugs.chromium.org/p/chromium/issues/detail?id=1021571#c25 (addressed the "got a B but no E")

[bgooren]

We are seeing something similar:

https://developers.google.com/speed/pagespeed/insights/?hl=nl&url=https%3A%2F%2Fwww.regiobloemist.be

Minimize main-thread work 17.3 s

Other | 17,278 ms Rendering | 1 ms Script Evaluation | 0 ms

--> Strange detail: for desktop it doesn't show main thread work (0.0s, 7ms in "Other" category)

While a site that runs on the exact same server, with the exact same config (and actually more javascript) gives the following scores:

https://developers.google.com/speed/pagespeed/insights/?hl=nl&url=https%3A%2F%2Fwww.regiobloemist.nl%2F

main-thread work 0.0 s

Other | 15 ms Rendering | 1 ms Script Evaluation | 0 ms

--> Strange detail: for desktop it does show main thread work of 13.8s, all in the "Other" category.

Perhaps related or unrelated, it's unclear at this point: we also have issues with what appears to be an incorrect First Input Delay score on the second domain (.be, 244ms, only visible in the origin summary, greyed out for the homepage), while on the first domain (.nl) the FID scores are in the green (12 - 13ms). We have been using a third-party tool to get live web vitals data, and see <50ms FID across all devices (both desktop and mobile) on both domains. So we are completely baffled at this point as to why these scores differ (both the main thread work and the FID scores). Both websites target and have most visitors from western Europe, people with fast internet connections.

In conclusion, the data seems inconsistent at this point. Could this be related to the issue I'm replying to? I would expect any excessive main thread work to be javascript, but since it's all lumped into "Other" it's rather hard to debug.

[odin-vm]

We're also having huge load time lumped up inside the Other category ~120,000ms for the https://vividmotion.co/ website. Can't wrap our heads around it.

This is odd, the result above is from Pagespeed Insights, in Lighthouse however, the Other category shows ~1000ms.

Does anyone have an explanation?

[alexnj]

This seems to be related to #6708. I can repro on PSI with vividmotion.co. Looking further into it.

[iamakulov]

Another case: https://pagespeed.web.dev/analysis/https-framer-relocately-com/g0se2jfja0?form_factor=mobile

• Website: https://framer.relocately.com/
• Main thread work: 135.4s; other accounts for 131.3s
• TBT is also unusually high: 117.5s

[futtta]

If only to keep this on the radar: 11,038 ms of unhelpful "Other" main-thread waiting time at https://pagespeed.web.dev/analysis/https-craiasa-eu-ro/estzystgeu?form_factor=mobile

[alexnj]

This seems to be another instance of GPU/animation time being counted as main-thread due to software rendering (The page has 300ms duration fullscreen fade animation). We should close and fold this issue into #6708, @paulirish ?

[trazyn]

This seems to be another instance of GPU/animation time being counted as main-thread due to software rendering (The page has 300ms duration fullscreen fade animation). We should close and fold this issue into #6708, @paulirish ?

im stuck with this issue long time, ty save me, it seems a bug, im test on my site, https://pagespeed.web.dev/analysis/https-www-dearplayers-com-my/b5gpxhcfp1?form_factor=mobile

• website: https://www.dearplayers.com/my
• main thread work: 22.0s, other for 8407ms

after remove css animation: https://pagespeed.web.dev/analysis/https-www-dearplayers-com-my/ajtnd0atgq?form_factor=mobile main thread work 9.3s, other for 1781ms