So I think in moving some of the service worker stuff around (and just trying to be aggressive about making sure a user has the latest version), we have this code block:

  const isFirstInstall = !navigator.serviceWorker.controller;
  if (isFirstInstall) {
    // Watch for the brand new Service Worker to be activated. We claim this foreground page
    // inside the Service Worker, so this event will fire when it is activated.
    navigator.serviceWorker.addEventListener('controllerchange', () => {
      ensurePartialCache(true);
    });
  } else {
    // This isn't the first install, but ensure some partials are up-to-date.
    ensurePartialCache();

    // We claim active clients if the Service Worker's architecture rev changes. We can't
    // reliably force a reload via the Client interface as it's unsupported in Safari.
    navigator.serviceWorker.addEventListener('controllerchange', () => {
      window.location.reload();
    });
  }

There's nothing wrong with this, except that in the second path, the 'controllerchange' event really does fire all the time a SW changes—not just on "version rev" like it used to.

Now this is actually pretty good, because pages like the web.dev/live have new JS and CSS, and in dev (or whatever) I often see the old version for a second before the SW updates and forces a refresh. But it means that for every new deploy where the SW data changes (master partial change?), we reload, which might be what you're seeing.

One other point: there's a post about SW registration best practices at https://developers.google.com/web/fundamentals/primers/service-workers/registration

It can often be a good idea to delay SW registration until after you've detected that all of the page's content has loaded (either via window.onload or some other event). That way, the process of starting up the SW thread and downloading the precached URLs won't contend with your main page's loading.

I had thought that Lighthouse tests start with an empty cache/SW registrations, but perhaps that has changed? Assuming it is still the case, it seems like isFirstInstall would always be true.

I like your suggestion, @jeffposnick. We don't need to rush into installing the SW.

I don't think #3171 is quite right @robdodson as I'd really like to keep the "major revision forces a reload" behavior. (Even though this issue is still valid, in that we're reloading all the time now.)

I'd really like to keep the "major revision forces a reload" behavior.

Were you thinking of enforcing that with the serviceWorkerArchitecture string in sw.js?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.

I think #3362 is the intended solution for this. My understanding is if the user is online we'll try to fetch the latest partial, and if it has a version mismatch with the assets, then we'll fetch the latest assets as well.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.

Closing this issue because it has been marked as stale for more than 7 days.