-->

Manifest start_url is not cached by a Service Work

2020-08-11 10:40发布

问题:

I'm using Lighthouse to audit my webapp. I'm working through the failures, but I'm stuck on this one:

Failures: Manifest start_url is not cached by a Service Worker.

In my manifest.json I have

"start_url": "index.html",

In my worker.js I am caching the following:

let CACHE_NAME = 'my-site-cache-v1';
let urlsToCache = [
    '/',
    '/scripts/app.js',
    '/index.html'
];

Which lines up with what I see in the Application tab in Chrome Dev tools:

So... why is it telling me start_url is not cached?


Here is my full worker.js file:

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);
    });
  });
}

let CACHE_NAME = 'my-site-cache-v1.1';
let urlsToCache = [
  '/',
  '/scripts/app.js',
  '/index.html'
];

self.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open(CACHE_NAME)
    .then(function(cache) {
      console.log('Opened cache');
      return cache.addAll(urlsToCache);
    })
  );
});

回答1:

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



回答2:

It seems to be that Chrome lighthouse (chrome v62) performs a generic fetch(). See discussion on https://github.com/GoogleChrome/lighthouse/issues/2688#issuecomment-315394447

In my case, an offline.html is served after an "if (event.request.mode === 'navigate'){". Due to the use of lighthouse´s generic fetch(), lighthouse will not get served this offline.html, and shows the "Manifest start_url is not cached by a Service Worker" error.

I solved this problem by replacing:

if (event.request.mode === 'navigate'){

with

if (event.request.method === 'GET' ){