Service worker does not successfully serve the manifest's start_url.

[gauntface]

This error is actually pretty hard to fix if you think you are.

At the moment I'm caching the index.html page and I've set the start_url to index.html and I still get this error.

I can even go from DevTools > Application > Manifest > start_url link to the page, switch to offline in network panel and reload the page and get the full page from the service worker.

Any ideas how to debug this?

[patrickhulce]

Potentially a case of #2688?

[gauntface]

The project is the wsk-next branch of web-starter-kit https://github.com/google/web-starter-kit/tree/wsk-next

in the directory run:

1. npm install
2. gulp prod

[icyJoseph]

Hi,

I have encountered the same issue, when using create-react-app, out of the box because the service worker fails to serve the start_url, as you can see in this image:

In order to fix this, I've fetched a service worker script from: http://www.manifoldjs.com/ using the Service Worker for offline pages.

self.addEventListener("fetch", function(event) {
  event.respondWith(
    fetch(event.request).catch(function(error) {
      console.log(
        "[Service Worker] Network request Failed. Serving content from cache: " +
          error
      );
      //Check to see if you have it in the cache
      //Return response
      //If not in the cache, then return error page
      return caches
        .open(
          "sw-precache-v3-sw-precache-webpack-plugin-https://silent-things.surge.sh"
        )
        .then(function(cache) {
          return cache.match(event.request).then(function(matching) {
            var report =
              !matching || matching.status == 404
                ? Promise.reject("no-match")
                : matching;
            return report;
          });
        });
    })
  );
});

Then I use cra-append-sw to append this code to the Create-React-App default Service Worker. Set start_url in manifest to "./index.html" and it passes the audit. Note that the index.html is server anyway, so this might just be a Lighthouse bug.

Hope this hopes with the investigation. I have made a repo with the code that should work here: https://github.com/icyJoseph/test-worker/blob/master/src/service-worker.js

[JustFly1984]

I'm not using CRA, but I've copied whole code concerning SW to my project based on react-static

Can you please explain the meaning of "sw-precache-v3-sw-precache-webpack-plugin-https://silent-things.surge.sh" string?

Can I copy this code to my register service worker file safely?

[JustFly1984]

I've navigated to https://silent-things.surge.sh/, used Audit, and get the same Service worker does not successfully serve the manifest's start_url. error

[icyJoseph]

Hej,

That's the name of the cache, aka cacheName, replace it with yours, that string is the url of project I used to test CRA, combined with some CRA defaults.

EDIT

I have now deployed to https://silent-things.surge.sh

I would just like you to say that without this add-on to the CRA service worker, the app does serve index.html in offline mode, it is just lighthouse that flags it.

[JustFly1984]

Ok, so as I understand, this peace of code has no real value, except making lighthouse to stop false negative warning?

[icyJoseph]

I could of course be wrong, but yes. There seems to be a false negative. Please refer to:

• https://developers.google.com/web/tools/lighthouse/audits/cache-contains-start_url
• Lighthouse doesn't send Accept request header in start_url audit #4312
• https://stackoverflow.com/questions/45330087/manifest-start-url-is-not-cached-by-a-service-worker

The blame seems to come from:
https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/webapp-install-banner.js

In line 78,

static assessOfflineStartUrl(artifacts, result) {
    const hasOfflineStartUrl = artifacts.StartUrl.statusCode === 200;

    if (!hasOfflineStartUrl) {
      result.failures.push('Service worker does not successfully serve the manifest\'s start_url');
      if (artifacts.StartUrl.debugString) result.failures.push(artifacts.StartUrl.debugString);
    }

    if (artifacts.StartUrl.debugString) {
      result.warnings.push(artifacts.StartUrl.debugString);
    }
  }

Hopefully this gives you more insight on to how to fix your problem. For me this is as far as I go to jump over a false negative.

[mclamanna]

Yeah I've pretty much given up on fixing this error:
Service worker does not successfully serve the manifest's start_url.

When you view my site www.mlamannadev.com from an android device a banner does pop up so I don't know why I'm still getting this error in lighthouse.

[JosefJezek]

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

[Stefany93]

Same here. The banner does pop up on android device but the stupid error makes my Lighthouse has 82 points.

[stefanklokgieters]

@Stefany93 same thing here... I assume that Google Lighthouse is not their top priority looking at the speed of development and improvement

[corysimmons]

@icyJoseph seems to have pinpointed the piece of code responsible for this pretty serious bug #4541 (comment)

@patrickhulce @wardpeet @paulirish @karolklp Could one of you review and confirm if he's correct (that it's a false positive) and suggest or implement a fix?

It's causing fresh create-react-app projects to fail—as well as fresh Google projects.

[patrickhulce]

The piece of code that @icyJoseph pinpointed is where the display string is being added to the set of errors but not the cause of the bug.

@brendankenny didn't you recently discover something w.r.t manifest parsing that might help here?

[corysimmons]

Thanks for the info @patrickhulce and helping move this along.

[wardpeet]

The service worker issue got resolved here #4070

it more or less comes to this bug #4898 i'll try to figure something out somewhere this week.

I might be completely wrong here.

[wardpeet]

does this work for you people? #5067
Honestly it just gives a better error message. If not could you give me a good test url that's still broken with the #5067 patch.

[corysimmons]

The user is prompted to install the PWA though.

The problem, for me anyway, is I ran Lighthouse with a fresh CRA app, and this error made me think it wouldn't install a PWA. When I opened the url on Android, it did prompt to install...

If Lighthouse is determining XYZ makes something not a PWA, when it is a PWA, then Lighthouse needs to be fixed to not determine that.

[wardpeet]

going to try a fresh CRA, thanks for the feedback

[wardpeet]

I tested this one and seems to be good.
wdyt @patrickhulce @patrickhulce @gauntface ?

yarn start (dev mode) - no Service Worker

yarn build (prod mode) - with Service Worker

[patrickhulce]

@wardpeet out of curiosity wanna test real quick with/without 30eb6ce? I'm wondering if that fixed things by chance

[wardpeet]

@patrickhulce it's the same result with just fetch. The fix was actually the one #5067 as the messages were just messed up as the service worker is not registered on yarn start

you can test it here https://build-zzbfraodkg.now.sh/

[patrickhulce]

Oooooooh, gotcha so it was always working with CRA then?

[wardpeet]

Not entirely 😛

the bug was fixed when #4710 landed as there was a race condition when the manifest wasn't cached on time. After that one it was just a wording error in the audit.

[madmoizo]

index.html is cached by Workbox and there is start_url: / in the web app manifest

About error message:

• Service worker does not successfully serve the manifest's start_url: Acceptable. index.html is not equal to / but in fact, the install banner appears and after installation, the PWA works as expected, so the browser understands that index.html === /, why the audit can't ?
• No usable web app manifest found on page ... : Misleading. There is a web app manifest (visible in Application tab > Manifest)
• No start URL to fetch : Misleading. There is a start URL

[patrickhulce]

@frlinw we totally agree! on latest LH I don't see any of those issues on your site though so hopefully fixed in the past couple months 👍

[madmoizo]

@patrickhulce thanks ! I ran the audit on canary (v68) because I tought it was the latest lighthouse version but with the chrome extension it's all good.

[patrickhulce]

we're rolling the latest lighthouse to canary as we speak, look out for it next week :)

[mrtnmgs]

I'm still having this issue in Chrome 67.0.3396.79. (it seems to be the same issue, as my app passes the Lighthouse audit in Chrome Canary 69.0.3455.0). Is there any workaround?

[wdiechmann]

hmmm - I get the Service worker does not successfully serve... when auditing, but from the Application tab, with Manifest selected, I am able to Add to Homescreen then select Service Workers and go Offline, then select Manifest and click the start_url and see the browser window flicker just noticeable (which I guess will equal a '200')

This happens in Chrome (Version 66.0.3359.181 (Officiel version) (64-bit)) and Chrome Canary (Version 69.0.3455.0 (Officiel version) canary (64-bit)) on macOS

I added the outputs of lighthouse https://app.localhost --verbose 2>log&
log.txt
Lighthouse_Report.pdf

[fry2k]

It depends on the Lighthouse version and not at the Chrome version. Just a short overview from myself with my website:

• Integrated Lighthouse 2.9.1 from Chrome 67.0.3396.79 (Windows) shows the error
• Lighthouse extension 3.0.0-beta.0 which could be installed at Chrome 67.0.3396.79 fixes the error
• Integrated Lighthouse 3.0.0-beta.0 from Chrome Canary 69.0.3457.0 (Windows) fixes the error

An interessting point is that the Lighthouse extension is tagged as version 2.10.1.3000 and the Lighthouse itself shows version 3.0.0-beta.0.

@wdiechmann
which Lighthouse version do you have at your mac Chrome Canary? I'm on windows here at work and can't check the mac version.
Your PDF report was build with version 2.9.4. You may could try to install the extension?

[Drag13]

Chrome: Version 67.0.3396.87 (Official Build) (64-bit)
Create-react-app: Version 1.5.2
Integrated Lighthouse: Version 2.9.1

Manifest is present but I got the same error:

[patrickhulce]

@Drag13 does using latest LH (3.0.0-beta.0) fix your issue?

[Drag13]

@patrickhulce I am sorry, but could you point me where I can get beta-version. On the market, I see only 2.10.1.3000

[patrickhulce]

@Drag13 that you should be using 3.0.0-beta under the hood :)

[wardpeet]

@Drag13 @wdiechmann @mrtnmgs
Chrome 67 (current stable) does not have the latest lighthouse which not holds the fix for this audit.
Chrome 69 (current canary) does has the fix and latest lighthouse. Could you try that one.

You could also try the chrome extension from the chrome store.

it's actually just a @fry2k said :)

[Drag13]

Chrome: Version 69.0.3466.0 (Official Build) canary (64-bit)
Failures: No manifest was fetched.

Same for the latest official Chrome and LH latest extension.
Do you need link to the app?

[fry2k]

@Drag13
Yes a link to your app would help me.
In my opinion it seems to be really a problem with fetching the manifest because the brand color is also missing. Or didn't you define the brand color at your manifest?

[wdiechmann]

would a somewhat clearer error-message aid all of us "earthlings" to squelching your 'in-tray' ?

like:

parsing manifest.json failed: brand color missing

Another thing:
When I see a 404 and Lighthouse tells me that a manifest was not fetched, and a manifest.json is in fact present at the correct place - where would I start looking?

Reflexion:
The entire PWA thing seems (to me) to collide with other client strategies, like caching for one. While developing it would be very welcomed to somehow flip-a-switch and suddenly Chrome would load fresh copies of all assets on every reload. No emptying of caches, deleting content, and what-not - just my 2cent

[Drag13]

App was here
Manifest is here

{
  "short_name": "Upload",
  "name": "UploadPage",
  "icons": [
    {
      "src": "favicon.ico",
      "sizes": "64x64 32x32 24x24 16x16",
      "type": "image/x-icon"
    }
  ],
  "start_url": "./index.html",
  "display": "standalone",
  "theme_color": "#000000",
  "background_color": "#ffffff"
}

Could this be connected with no force redirect from http to https?

[wardpeet]

@wdiechmann
there is such an option in devtools -> application tab. This option is handy while developing and ignoring the Service Worker but it has nothing to do with Lighthouse itself.

@Drag13
I get a 404 on http://makephoto.azurewebsites.net/manifest.json or https://makephoto.azurewebsites.net/manifest.json

you can see if the manifest gets loaded correctly in the application tab

[Drag13]

Manifest is definitely there

Seems problem is in hosting permissions. I will check later and return. Thanks for the help!

[wdiechmann]

@wardpeet great! I was of the impression that checkbox would only reload the serviceworker

[Drag13]

Problem was on the my side.
Azure doesn't serve static json files without proper web.config.

Chrome 67.0.3396.87 - All works fine
Chrome 69.0.3466.0 - All works fine

@wardpeet Thanks a lot for the help!

[patrickhulce]

@wdiechmann the magic checkbox that makes this mode work is actually "Bypass for network", between that and "Disable cache" in the network tab you should be getting fresh assets from server every time :)

[wardpeet]

@patrickhulce yeah correct sorry! :)

[wdiechmann]

@patrickhulce @wardpeet affirmative :)

thx!

[wardpeet]

I'm closing this issue, I'm pretty sure this one got fixed. if not please create a new ticket with new information.