I'm not able to reproduce this behavior. On the first run, LH found a service worker.

If you wait a while to register a service worker, then it could be flaky based on if your registration happened yet before we moved on.

@patrickhulce , in your case the "manifest" is missing?

I'm not sure what is going on, but this is what I get:

+1 for this issue. Finding the same with https://m.jungleerummy.com/ . Lighthouse is reporting that the site doesn't register service worker, but in-fact it does on the landing page load itself. Attached the lighthouse report and SW registration registration screenshots.

I'm having the same issue when I run Lighthouse on https://thesession.org (using the Audit tab in Chrome).

But interestingly, this problem only occurs if throttling is set to the default "Simulated Fast 3G, 4x CPU Slowdown".
If I choose "Applied fast 3G, 4x CPU Slowdown", the service worker is registered just fine.

And looking at #5782, it seems that the problem doesn't happen with the command line interface.

So it seems that the issue is isolated to:

• Lighthouse running from the Audit panel in Chrome's dev tools, with
• Throttling set to "Simulated Fast 3G, 4x CPU Slowdown".

Same issue, and I confirm @adactio diagnostic. Using Chrome Canary 71 with Lighthouse 3.0.3, on the same app, the "no service worker is registered" error happens with default audit options (Simulated fast 3G...), while it's OK when using option "No throttling". It's also OK in Chrome stable (v68 and Lighthouse 3.0.0-beta.0).

This issue is now in Chrome stable (70). Any plans on fixing it?

The behavior you're describing then @cyrilletuzi and @adactio is #599/#2924. The difference between those throttling options is how long we wait for the page to "settle" and in those cases it seems that the service worker doesn't have complete time to register.

@patrickhulce Do you mean the problem is on the app side (wrong service worker)?

Because my app is just using the official Angular service-worker, so if the problem is on the app side, an issue should be reported as soon as possible in Angular.

@cyrilletuzi not really, it's something on the LH side we'll need to figure out how to handle, just an explanation for why. We're not failing to detect, we're just not waiting long enough to detect it.

@patrickhulce OK. For info, the app I'm auditing is a small Angular app, so if it's already a problem in a small app, maybe there is something on the Angular side to manage better about the service worker?

Related #6626

FWIW, we started running into this on angular.io. It happens intermittently on the locally served app (using http-server) - i.e. it doesn't happen when testing the app on Firebase hosting - and it happens much more often on CI than on my machine. (We are tracking this in angular/angular#29910.)

angular.io is using the Angular SW (obviously 😁), which is intentionally waiting for the app to stabilize (as far as Angular in concerned) before registering.

Is there a way to specify a larger timeout for Lighthouse or something?

Update: For us, it turned out to be related to the old Chrome version used on CI (v70). Switching to a new version of Chrome/Chromium (v75), via puppeteer@1.14.0, makes the SW be reliably detected by Lighthouse. 👇

Update (2): Or maybe not: angular/angular#29921 (comment) 😞

I have put any info I have in angular/angular#29910 (although it's mostly specific to the Angular repo/CI).
Any help debugging this would be very much appreciated 😁

Is there a way to specify a larger timeout for Lighthouse or something?

@gkalpak yes! You can use a custom config that increases pauseAfterLoadMs in the defaultPass, the default is only 1s.

Run Lighthouse with custom config

lighthouse --config-path=./foo-config.js <url>

foo-config.js

module.exports = {
  extends: 'lighthouse:default',
  passes: [
    {passName: 'defaultPass', pauseAfterLoadMs: 10000},
  ]
}

Thx, @patrickhulce ❤️
It worked for us 🎉

_{(Is this documented somewhere? If not, it totally should, because I suspect most of the many similar issues reported about SW not being detected would be solved by this.)
NVM, I found out it is documented in docs/configuration.md, which is linked to from README,md. No idea why I didn't find it on my own 😇}

Anytime @gkalpak! :)

Yeah we might want to consider raising those specific docs up to a FAQ level of some sort as I've seen this fairly often with angular apps.

Original URL (kinoseed.com) works in Chrome stable now.

https://www.jungleerummy.com/ (from @prash-mi) seems to no longer have a SW.

https://thesession.org/ (from @adactio) works in Chrome stable now.

https://angular.io/ works in Chrome (but the issue was only reported for local dev / CI).

Since the URLs provided work now, we can close this issue. Please open a new issue if LH fails to detect your SW.

@patrickhulce think we could detect angular on the page -> use a higher timeout for pauseAfterLoadMs? or is that crazy