"URL responds with a 200 when offline": initial URL or final URL?

[brendankenny]

This is an interesting case where a developer using Lighthouse might be looking for a strict or loose interpretation of their question:

• if you've visited a URL before, does loading that exact URL when offline load content? Or:
• if you've visited a URL before, does reloading that page (or running from the homescreen) while offline load content?

The difference is in the second case the URL being visited while offline may not be the initial URL entered if a redirect occurred. Two cases I have in smokehouse are

• https://www.airhorner.com, which redirects to https://airhorner.com, which does work offline. We report it as not working offline because we reload the original URL and the redirect doesn't happen.
• https://www.chromestatus.com/ which redirects to https://www.chromestatus.com/features, which does work offline, but we again report the initial URL as not working offline.

When interpreting the question literally (does https://www.airhorner.com work while offline?) the answer is correct right now, but, again, this may be a surprising result if what you're really asking is if the page was open and you go offline, or it's refreshed while offline, does the page still work.

Two possible solutions:

• multiple offline tests
• warn when the initial URL changes due to redirects. "You tested https://example.com which redirected you to https://example.com/awesomePWA. You may want to test the second URL directly for complete results" or whatever

[brendankenny]

Other dimensions to this question:

• What about a different start_url than either the initial or final URLs? (does my PWA work offline when launched from the homescreen?)
• redirects. https://www.airhorner.com actually has a 301 redirect to https://airhorner.com. When I test it manually by loading the www version, going offline, then loading the www version again, Chrome remembers the redirect, redirects me, and the site actually does work offline when accessing the www URL. Is there something different to using Page.navigate on the debugger protocol that doesn't cache the redirect, or is this a LH bug?

[ebidel]

This is a tough question. When using lighthouse, I tend to test the final URL of my app (the one I end up on after redirects). However, I can see users typing in an initial URL and expect sane results.

FWIW, this is the same problem the start_url has when using Add to Homescreen. If that page isn't cached offline, ATHS does not work when offline. We've already seen a few cases of this.

"warn when the initial URL changes due to redirects. "You tested https://example.com which redirected you to https://example.com/awesomePWA. You may want to test the second URL directly for complete results" or whatever"

Seems 👍

[brendankenny]

another aspect of this is that the CLI and the extension are out of sync on this question, so you'll get different results in practice.

The extension can't test https://www.airhorner.com because it'll redirect before you can press the Lighthouse extension button, so you'll see it always as working offline, while the CLI will show it as not working offline. Again, each is technically testing a different URL, but to a user it's "I entered a URL and this is the report I got for it"

[paulirish]

I think we should just issue a warn-level log if the finalURL has a diff
origin than initial URL and list a few things that we may not have been
able to do successfully.

​

[brendankenny]

Sounds good. To close the loop: another issue with initial vs final URL is clearing storage, which is done per origin. If a redirect goes cross origin the cache, SW, etc are not cleared.

In the CLI this is only a problem if not using the default clean Chrome. In the extension you're usually already on the final (possibly redirected) URL, except when sites redirect you to a different origin due to mobile emulation.