Update throttling/cache/js state on the SW target

[paulirish]

In Developer Diary #Day1 - YouTube @paullewis ran into a weird behavior that the Service Worker wasnt going offline, despite Lighthouse making the page offline. It was filed as crbug 648208, and duped into a WontFix, as the devtools frontend handles this case decently well. The frontend will connect to both targets and send the network throttling commands to each.

In our current behavior ...

• sw network requests are unaffected by the throttling
• sw doesn't go offline when the page goes offline.

Currently Lighthouse only sends the throttling stuff to the page's target. It'd make sense to also connect to the SW and flip it offline etc.

[paulirish]

Current status: SW not affected by network throttling status or JS disabling of host page.

update: Or disk cache

[brendankenny]

I believe this would also let us solve #2688 more easily, since we could more easily simulate a fetch with mode navigate and get the start_url fallback behavior

[paulirish]

⭐️ Re-read the comments on #3237, useful stuff there.

[paulirish]

Deferring until new sessionId param on all protocol methods.
https://bugs.chromium.org/p/chromium/issues/detail?id=775132

[abdonrd]

Any news about this? It's blocking #2688.

Thanks in advance!

[patrickhulce]

We finally have the pieces in place to make this happen with the basic driver target management we're doing. IMO, we should re-prioritize this after 5.0 :)

[wardpeet]

Thank you for opening this bug.

It looks like we've managed to merge #9451 which should fix this bug. I am closing it for now but please feel free to reopen this and comment if you would like to continue this discussion.

[brendankenny]

this is actually a big one even apart from the offline part of it. We should keep it around :)

[wardpeet]

Thanks for reopening :) I'm currently drafting a doc which i'll share soonish with all issues i'm unsure about.

[Joelsz]

Hi, is there any timeline for this to be resolved?

This is needed for Lighthouse in DevTools to properly show emulated mobile results when the navigation request is being served through the SW's fetch event.

Currently it loads the desktop site while emulating mobile due to sending the desktop user agent from the Service Worker.

[patrickhulce]

@Joelsz the offline check isn't computed by lighthouse anymore in 7.0 and later, so this issue shouldn't affect that result in latest.

[Joelsz]

Thanks @patrickhulce for your reply.

This is not only about the offline check, it's about all the audits being checked against the desktop site.

Even with LH 7 (in Chrome 90) the SW sends the desktop UA while emulating mobile, thus loading the desktop site and calculating the audit result against that instead of the mobile site.

I don't understand though why this is only happening during Lighthouse execution, while the mobile site is properly loaded when pressing the browser reload button even though it's also using the same SW "fetch" handler.

[patrickhulce]

Ah I see. Thanks for the clarification @Joelsz !