lighthouse

lighthouse copied to clipboard

The following issue is caused by Lighthouse ignoring targets of type worker:

https://github.com/GoogleChrome/lighthouse/blob/d13a91961b63885031acaa1a3e4ad36fd0376c03/lighthouse-cli/test/smokehouse/test-definitions/oopif-scripts.js#L69-L75

This is a simple fix for legacy driver, we just treat worker targets the same as iframe here: https://github.com/GoogleChrome/lighthouse/blob/d13a91961b63885031acaa1a3e4ad36fd0376c03/lighthouse-core/gather/driver.js#L299

Unfortunately, things get dicey in FR mode. Puppeteer doesn't give us the target info on 'sessionattached' events so we normally call Target.getTargetInfo on the session puppeteer gives us. However, Target.getTargetInfo isn't allowed (throws an error) for worker targets which is a bug according to @caseq.

https://bugs.chromium.org/p/chromium/issues/detail?id=1344293

Ideally we will have Target.getTargetInfo working on all targets and add worker to the list of important target types.

Honestly I haven't figured out why this is working in DevTools in the first place.

Update: pausing workers doesn't work the same way as pausing frames:

Links: https://gist.github.com/adamraine/3cc8ac108ff1667cad8d10c994cd317b https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/common/features.cc;drc=97f94c6631e327c2c1a9891774b44fbba9e8e3bf;l=201

There are actually 2 upstream issues blocking this I guess: https://bugs.chromium.org/p/chromium/issues/detail?id=1352175

Both crbugs are resolved on ToT now. Should be pretty simple to fix this now, but we should wait until the changes reach stable.

Both fixes have landed in stable (M110) so we should consider attaching to worker targets now.

Seems good, though like iframes, the impact isn't entirely clear outside of simple stuff like bytes downloaded. e.g. is it bad for performance if nytimes downloads 10 MiB in a worker?

Lantern will calculate network contention (assuming it gets the timing right...might need an explicit worker creation node since it won't have a network root like an iframe does?), but will there be any other effect except as bandwidth sinks?

How are worker network protocol messages differentiated from the page's? Do they share a frameId and for same-frame checks should we also be looking at sessionId or something else?

For the frameId/sessionId/source question, should consider implementing alongside https://github.com/GoogleChrome/lighthouse/issues/14157 so we have explicit target information per request

is it bad for performance if nytimes downloads 10 MiB in a worker?

It's certainly not good, and I think we should be reporting the complete network story either way.

but will there be any other effect except as bandwidth sinks?

I would expect bandwidth sinks to be the primary concern. Workers always run in a separate thread.

How are worker network protocol messages differentiated from the page's? Do they share a frameId and for same-frame checks should we also be looking at sessionId or something else?

There are a couple ways to identify them on the Network.requestWillBeSent event:

• loaderId will be an empty string
• frameId will be undefined

I was testing https://github.com/GoogleChrome/lighthouse/pull/14212, and ran into issues for Lighthouse in DevTools, looks like it's another Chrome bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=1423096