wish: better debugging of the "Service worker does not successfully serve the manifest's start_url"

[RichardNeill]

I get the error in Lighthouse that: "Service worker does not successfully serve the manifest's start_url" This error message is not as informative as I would like it to be.

There is no further debugging in Lighthouse, nor does there appear to be any helpful linked documentation. What would be really useful is: "Service worker does not successfully serve the manifest's start_url...
This error message occurs: XXXX" combined with a link: " Here is a list of the things you should check".

---

Aside: in my own case, the manifest contains: "start_url": "../index.php?pwa=1 ", (though I've tried other permutations, a full URL, or just "index.html"). Lighthouse flags no problem with it on localhost; only goes wrong on the (https) production site. Everything else in the PWA audit is passing (other than the custom splash screen). I'm using this service worker, literally unaltered. https://github.com/GoogleChrome/samples/blob/gh-pages/service-worker/custom-offline-page/service-worker.js

[RichardNeill]

Incidentally, isn't the whole point that the service worker should not be serving the start_url, except in offline mode?

[patrickhulce]

Thanks for filing @RichardNeill! This is a good point that debugging why the service is not serving the start URL is quite painful and adding some info to our docs to help would be great.

Also as an FYI, we do only test that the service worker is serving the start URL in offline mode so you hit the nail on the head there :)

In your specific case, it looks like you might be trying to have the service worker serve a file for a parent directory ../index.php which it won't be able to do since service workers are scoped to their directory and children only. You'll need to move the app files up a level or index.php down a level to get this done.

From the useful MDN article that may help a bit

The service worker will only catch requests from clients under the service worker's scope. The max scope for a service worker is the location of the worker.

[dalyr95]

I'm getting this flagged as well in Chrome 64 on https://robert-daly.com/

Even though I can see '/' in the SW cache, get the install prompt on Android and the site works in offline mode.

[FaberNa]

I've the same problem, this is the manifest { "name": "PagineGialle", "short_name":"PagineGialle", "start_url": "/", "display":"standalone", "orientation":"portrait", "background_color":"#FFFFFF", "theme_color":"#FDC100", "icons": [ { "src": "/favicons/android-chrome-192x192.png?v=3", "sizes": "192x192", "type": "image/png" }, { "src": "/favicons/android-chrome-256x256.png?v=3", "sizes": "256x256", "type": "image/png" }, { "src": "/favicons/android-chrome-512x512.png?v=3", "sizes": "512x512", "type": "image/png" } ] } And in sw.js i've load two types of files, const files = [ '/?pwa=true', '/', And in the report of lighthouse report i have this screen : This is the version of chrome is 63.0.3239.132

[oliviertassinari]

I'm also intrested in having an actionnable message around this error. I have no clue around what's wrong with the Material-UI documentation website (using workbox v3.0.0-beta0).

[paulirish]

We could enumerate all the things we know, during this test

• You have a manifest
• It has a start_url
• You have a populated cache available to the service worker
• ...

And hopefully explain the things we know are good, know are bad, and don't know.

[markusv]

any progress on this? I have the same problem. My service worker response with 200 OK (with a offlien-html) for the start_url. Still lighthouse gives me this error

[JosefJezek]

I have the same problem. :-( I am using polymer cli and sw-precache.

[yonathan9669]

Hello, I have exactly the same issue. I can´t find out what's the problem.

here is my sw-precache-config.js file

module.exports = {
  staticFileGlobs: [
    'bower_components/webcomponentsjs/webcomponents-loader.js',
    'manifest.json',
    'images/fool-logo.png',
    'images/favicon.ico',
    'src/scripts/tmf-utils.js'
  ],

  navigateFallback: 'index.html',
  navigateFallbackWhitelist: [/^(?!\/__)/],
...
};

and my manifest

{  ...
  "Scope": "/",
  "start_url": "/news-feed",
  "serviceworker": {
    "src": "service-worker.js",
    "scope": "/",
... },

I already check the generated SW and the index.html file it's been dynamically cached but yet the lighthouse audit it's throwing the error.

I did check the offline usage for the app and everything seams to be fully working.

[charlesrocket]

can't pass the audit as well

https://stackoverflow.com/questions/50710520/jekyll-service-worker-failure-service-worker-does-not-successfully-serve-the

[bkawk]

Same issue here

[yonathan9669]

I solved this several time ago, I'm sorry I didn't post the solution before.

You just need to use in the start_url a valid file for example index.html in my case. That will solve the AUDIT issue.

[sudomann]

Yeah @yonathan9669 , well what about sites that load at website.com/ ? I have such a site, and i refuse to use the ugly link styling that is website.com/file.html, website.com/file.php, etc. Despite getting that failed audit in LH, I can add my site as a PWA just fine. On Android, chrome and chrome dev both ask to add the site to homescreen.

[yonathan9669]

Well, LH only use your start_url key to test the service-worker it's properly caching the resources, I don't like either the file.xyz style, but that's within the manifest and it won't hit your app UX.

Yes even if you don't use the file to approve the LH test you would be able to load the PWA, because when the embed browser loads the start_url the SW it will redirect the traffic if needed.

[yonathan9669]

@sudomann here you could check the manifest and a simple PWA example we did for a client.

As you can see the app loads as you suggest website.com/ but the manifest have the start_url as I already described. So you would have both needs, a better score on LH and a better UX for your app.

Happy coding 👍🏼

[westonruter]

Looping back on this. In https://github.com/xwp/pwa-wp/issues/115 the @aristath says that Lighthouse is complaining with:

Service worker does not successfully serve the manifest's start_url, No usable web app manifest found on page.

This is coming from the PWA WordPress plugin we're working on. It generates a web app manifest with a start_url with an absolute URL like https://example.com/. Apparently this violates a requirement that the URL be relative to the path where the web app manifest is located? The bug reporter is saying a start_url of / is also violating this audit, and yet MDN uses as an example "start_url": "/?utm_source=a2hs".

He's saying that the start_url of . is what fixes the audit, but that seems strange as that would mean that if the web app manifest is located at https://example.com/wp-json/wp/v2/web-app-manifest that it would need a start_url of ../../../../. He cites MDN:

start_url: The URL that loads when a user launches the application (e.g. when added to home screen), typically the index. Note that this has to be a relative URL, relative to the manifest url.

But the example shows:

"start_url": "/pwa-examples/a2hs/index.html"

Is MDN wrong to use / in its example?

[connorjclark]

Is the scope set to the root? The default value won't work in your use case since your manifest file is not at the root of the domain. That's the standard place to keep it, but I understand Wordpress may have other thoughts :)

[brendankenny]

@westonruter the message you mention includes "No usable web app manifest found on page", so it sounds like that might be the first step to fix.

But can you run Lighthouse from the command line or in Chrome Canary? There have been some updates to the error messages that may help give more precise insight as to what's going on (like any SWs that are found for an origin and what the controlling scopes are).

[westonruter]

I'm not able to reproduce the problem myself. I've asked the original reporter to follow up via https://github.com/xwp/pwa-wp/issues/115#issuecomment-459812044

[adrianaixba]

As per Chrome’s updated Installability Criteria, Lighthouse will be deprecating the PWA category in the next upcoming release. For future PWA testing, users will be directed to use the updated PWA documentation. Marking this as closed!