pwa - Service worker does not successfully serve the manifest's start_url

Question

I am trying to add PWA functionality to an existing website that is hosted on Azure and uses Cloudflare CDN.

I have run the lighthouse testing tool on the site and it passes everything in the PWA section (e.g. service worker installed, served over https, manifest installed etc.) except:

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

My manifest.json has '/' as the start URL and "/" as the scope.

The '/' is actually default.aspx which I have cached as well.

My service worker caches '/', e.g.

var cacheShellFiles = [
  '/',
  '/manifest.json',
  '/index.html',
  '/scripts/app.js',
  '/styles/inline.css'
   ...
]

// install - cache the app shell
self.addEventListener('install', function (event) {
console.log('From SW install: ', event);

// calling skipWatiing() means the sw will skip the waiting state and immediately 
// activate even if other tabs open that use the previous sw
self.skipWaiting();

event.waitUntil(
    caches.open(CACHE_NAME_SHELL)
        .then(function (cache) {
            console.log('Cache opened');
            return cache.addAll(cacheShellFiles);
        })
);
});

When I view the Cache Storage files in dev tools however, the Content-Length of the / and the .css and .js files is 0:

Image of Chrome Developer tools showing cache storage with Content-Length=0 Is the Content-Length = 0 the reason that it is saying it can't serve the manifest's start URL ?

Answer 1

This is an issue with your service worker's scope (different from the scope option in manifest.json).

Your start_url is set to /, but most likely your service worker file is served from a deeper path, e.g. /some-path/service-worker.js. In this case, your service worker's scope is /some-path/, therefore it will not be able to handle requests to paths outside of it, such as the root path /.

To fix this, you need to make sure that your service worker's scope covers your start_url. I can think of two ways to do this:

1. In your case, serve the service worker file directly from the root path, e.g. /service-worker.js.

2. Use the Service-Worker-Allowed response header, which overrides the service worker's scope, so that it wouldn't matter from which path the service worker file is served from.

Choose the one that is more appropriate to your setup.