Progressive Web App - Service Worker Not Serving Start_Url

Progressive Web App - Service Worker not serving start_URL

Noted from Register A service worker,

If we register the service worker file at /example/sw.js, then the service worker would only see fetch events for pages whose URL starts with /example/ (i.e. /example/page1/, /example/page2/).

Inline with the shown error and given in this documentation, check the following:

1. Define a start_url property in your manifest.json file.
2. Ensure that your service worker properly caches a resource that matches the value of start_url.

Also, check this tutorial and see if it will help you.

Manifest start_url is not cached by a Service Worker

Let's look at Lighthouse's source code

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

  if (!hasOfflineStartUrl) {
    result.failures.push('Manifest start_url is not cached by a service worker');
  }

}

We can notice, that it's not checking your cache, but response of the entry point. The reason for that must be that your service worker is not sending proper Response on fetch.

You'll know that it's working, if in DevTools, in your first request, there'll be (from ServiceWorker) in size column:

There're two problems with the code you've provided:

First one is that you're messing service worker code with service worker registration code. Service worker registration code should be the code executed on your webpage.

That code should be included on your page:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/worker.js').then(function(registration) {
      console.log('ServiceWorker registration successful with scope: ', registration.scope);
    }, function(err) {
      console.log('ServiceWorker registration failed: ', err);
    });
  });
}

and the rest of what you've pasted should be your worker.js code. However service worker get installed, because you've files in cache, so I suspect you just pasted this incorrectly.

The second (real) problem is that service worker is not returning this cached files. As I've proved earlier, that error from lighthouse means that service worker is not returning start_url entry file.

The most basic code to achieve that is:

self.addEventListener('fetch', function(event) {
  event.respondWith(caches.match(event.request));
});

Service worker is event-driven, so when your page wants to get some resource, service worker reacts, and serves the one from cache. In real world, you really don't want to use it like that, because you need some kind of fallback. I strongly recommend reading section Serving files from the cache here

Edit: I've created pull request in Lighthouse source code to clarify that error message

Start_url not in ServiceWorker's scope for lighthouse PWA audit "localhost"

My bad :-( or, at least, My Disbelief!

The only "problem" is the "b" in the browser navigation/URL bar. This works on Windows/IIS: -

http://localhost:3333/Brotkrumen/travelmanager.html

It's as simple as that. And, before you ask, yes it was one of the first things I tried but I didn't realize that Chrome Browser History would see a case-insensitive "exact" match and replace what I typed with the "old" lower-case version. (And, yes, I wasn't paying attention) Once I deleted the "old" url from history and entered the new one, all lighthouse audits were passed.

I enetered a bug with Lighthouse but they disagreed.

For me Windows' and Chrome's case-insensitivity needs to be respected/honoured with a case-INCENSITIVE compare by Lighthouse. Linux/GitHub won't find the sub-folder in the first place, and all other URL case checks (caching etc) are enforced so there is no regression here?

Or Chrome become case sensitive?

Anyway, all's well that ends.

Manifest.json Does not register a service worker that controls page and start_url

You must add service-worker.js script

---

Related Topics