Unexpectedly low main thread time

[mattzeunert]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://twitter.com/migueldeicaza

What happened?

Run node ./cli/index.js --view https://twitter.com/migueldeicaza on master

The report says TBT and main thread activity are basically zero.

What did you expect?

The devtools trace artifact suggests quite a bit of main frame CPU activity.

What have you tried?

In trace-processor.js Chrome correctly identifies the main thread id, 259 in this case.

I don't really understand how threads work in Chrome. I tried testing another page and having multiple process ids per thread seems normal.

In my case these are the process IDs:

> new Set(trace.traceEvents.filter(e => e.tid === 259).map(e => e.pid))
Set(4) {40151, 40181, 40169, 40199}

The process Lighthouse filters by seems to come from the first main frame thread_name event. But there seem to be two of those:

This is one of the larger CPU tasks and it matches the second CrRendererMain process.

{"args":{},"cat":"disabled-by-default-devtools.timeline","dur":248954,"name":"RunTask","ph":"X","pid":40199,"tdur":246608,"tid":259,"ts":191377433302,"tts":210151},

How were you running Lighthouse?

CLI

Lighthouse Version

9.5.0 (though I don't think this issue is new)

Chrome Version

Chromium 106.0.0.0

Node Version

No response

OS

No response

Relevant log output

No response

[brendankenny]

I tried testing another page and having multiple process ids per thread seems normal.

Doesn't address the root issue, but for this, you need the (pid, tid) tuple to identify a thread. It's common for thread ids to be the same for different threads in different processes (edit: at least for Chrome threads. I don't know enough about thread IDs to make that claim generally :).

Can you share a trace by any chance?

[paulirish]

Brendan and I looked into it and found some issues. In short, our frameEvents is a small subset of all events happening on that frame... and more important to this issue.. our processEvents can pick the incorrect process if there was a cross-origin redirect during navigation. This latter item seems like a regression somehow at some point. We'll dig into it.

Thanks @mattzeunert mucho for reporting