Lighthouse: start_url fetched via an "offline" SW not considered good enough

[ondras]

Provide the steps to reproduce

1. Run LH on https://ondras.github.io/sw/

What is the current behavior?

start_url does not respond with a 200 when offline. The start_url did respond, but not via a service worker.

What is the expected behavior?

This configuration shall be considered okay.

The problem is related to the SW's caching strategy. The current worker works online-first, i.e. it always tries to fetch the resource. It looks like it succeeds, even when "simulating offline in Lighthouse", so the reply is not considered via a service worker.

If I change the if (cached) implementation to simply return cached (not trying any network interatction), Lighthouse works correctly.

Environment Information

• Affected Channels: DevTools
• Lighthouse version: 5.5, 5.7
• Chrome version: 79, 81
• Operating System: Linux

[patrickhulce]

Thanks for filing @ondras! I'm able to reproduce this in DevTools as well (though everything seems to work fine from CLI)

Related #709

[paulirish]

another repro from #10262 https://www.stop-it.be/

[hdlion]

@ondras:- I'm also facing same problem? Any solution ? Below is my Service Worker code.

function networkOnly(request) {
  return fetch(request).then(function (response) {
    return response;
  }).catch((error) => {
    console.log('Network Only fetch failed', error);
    return caches.match(OFFLINE_URL);
  });
}

[derykmarl]

Same in gatsby-plugin-offline / gatsby-plugin-manifest

The generated manifest file contains start_url of '/' and on most pages it passes, but on the home page it fails. I don't know if it's the same issue though as this is using 6.1.0 via Chrome Canary - the current 6.0.0 Lighthouse works fine.

[surajtambe]

"files": [
"/",
".html",
"/favicon.png",
"/manifest.json",
"/.css",
"/*.js"
]

my configuration
"/" is not being cache in service worker cache causes no offline application.

[SimonHogstromRonbol]

i've made a minimal example in AMP, that has the same issue:
https://www.pwamp.dk/

[psabharwal123]

same issue with https://preactjs.com/repl/

[psabharwal123]

strange thing is, it is actually being served by service worker, bug in chrome?

[Jimmydalecleveland]

I've been fighting this same problem for over a week. My problem is similar to what @derykmarl described, except reversed: My sites homepage passes the check, but all other pages do not. I have an older Gatsby site that is passing this check, but despite the many combinations of code and package version changes I cannot get any other site using gatsby-plugin-manifest and gatsby-plugin-offline to pass this check.

[akrmontoya]

I've been fighting this same problem for over a week. My problem is similar to what @derykmarl described, except reversed: My sites homepage passes the check, but all other pages do not. I have an older Gatsby site that is passing this check, but despite the many combinations of code and package version changes I cannot get any other site using gatsby-plugin-manifest and gatsby-plugin-offline to pass this check.

I have the same problem

[JacobDB]

I believe I'm having the same issue – Lighthouse in Chrome's dev tools reports that start_url isn't available offline, but Chrome on Android still displays the "Add to home screen" prompt just fine, and the app does function offline after a second page load. I think the issue is that the service worker can't cache the current page until the second load because it's not installed until the initial load finishes (and thus cannot intercept the loading to cache it).

Very frustrating, it's preventing me from achieving a perfect score... would love a resolution.

[garygreen]

Having the same issue. So it looks like it's failing for everyone who basically uses a "Network First" then fallback to "Cache" approach?

Kinda suprising there's not more attention on this tbh.

[patrickhulce]

Kinda suprising there's not more attention on this tbh.

FYI everyone there's not much public attention here because the intent is to loosen the strictness of this check to match browser checks rather than fix it :)

The primary question is around the timeline which requires coordinating with many consumers and stakeholders of the PWA category, which is where we're currently held up.

[SalahAdDin]

Here, me too, using next-offline.

[kkoss89]

same here https://impulsioneme.com

[brendankenny]

fixed in #11745

[JacobDB]

Fantastic news! Any idea when this will be integrated in to Chrome?