Fehlerhafte Service Worker entfernen

Manchmal werden fehlerhafte Service Worker bereitgestellt und dann treten Probleme auf. Ein Service Worker kann beispielsweise bei der Registrierung geparst werden und die Installation erfolgreich abschließen. Fehlerhafter Code in einem fetch-Ereignis kann jedoch dazu führen, dass er nicht auf Anfragen antwortet, was zu einer leeren Seite führt. Eine weitere Möglichkeit besteht darin, dass das Seiten-Markup intensiv im Cache gespeichert wird und ein Service Worker nur für nachfolgende Besuche veraltete Markup-Antworten von einer Cache-Instanz zurückgibt.

Es gibt viele Möglichkeiten, wie ein Service Worker nach hinten losgehen kann, und das ist bei einer Produktionswebsite ein beunruhigendes Problem. Dennoch ist nicht alles verloren. Es gibt Möglichkeiten, das Problem zu lösen und wieder auf Kurs zu kommen.

Betriebslosen Service Worker bereitstellen

Normalerweise müssen Sie für einen fehlerhaften Service Worker lediglich einen einfachen no-op-Service Worker bereitstellen, der ohne fetch-Event-Handler sofort installiert und aktiviert wird:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

Dieser Service Worker installiert und aktiviert sofort durch Aufrufen von self.skipWaiting() im Ereignis install. Optional kann zusätzlicher Code im activate-Ereignis bereitgestellt werden, um das Neuladen aller anderen geöffneten Tabs mit einer WindowClient zu erzwingen, die der Service Worker steuert.

Es ist sehr wichtig, dass ein No-Op-Service Worker keinen fetch-Event-Handler enthält. Wenn ein Service Worker keine Anfragen verarbeitet, werden diese an den Browser weitergeleitet, als ob kein Service Worker vorhanden wäre. Nachdem ein No-Op-Service Worker bereitgestellt wurde, kann er korrigiert und als Update bereitgestellt werden.

Dieser Ansatz funktioniert zum Teil, da Browser starke Sicherheitsmaßnahmen haben, um Service Worker im HTTP-Cache zu platzieren, und weil sie Byte für Byte die Inhalte eines Service Workers auf Updates prüfen. Diese Standardeinstellungen ermöglichen es Ihnen, einen managementfreien Ersatz für einen fehlerhaften Service Worker bereitzustellen, um das Problem schnell zu beheben.

Weitere zu ergreifende Maßnahmen

Die Bereitstellung eines managementfreien Service Workers sollte ausreichen, um fehlerhafte Vorgänge zu neutralisieren. Bei Bedarf können jedoch auch zusätzliche Maßnahmen ergriffen werden.

Was passiert, wenn Sie die URL des alten Service Workers nicht kennen?

Manchmal ist die URL eines zuvor installierten Service Workers unbekannt. Das liegt möglicherweise daran, dass die Datei versioniert ist (z. B. einen Hash im Dateinamen). In diesem Fall kann es eine Herausforderung sein, einen No-Op-Service Worker bereitzustellen, der mit der URL jedes alten Service Workers übereinstimmt, der eventuell registriert ist. Dies verstößt gegen die Best Practices, da sich Entwickler wahrscheinlich nicht jeden Hash für jede bereitgestellte Service Worker-Version merken.

Glücklicherweise wird ein hilfreicher HTTP-Anfrageheader mit einer Anfrage für ein Service Worker-Skript gesendet: Service-Worker. Suchen Sie auf dem Webserver nach diesem Header und fangen Sie die Anfrage ab, um stattdessen einen managementfreien Service Worker bereitzustellen. Die Umsetzung hängt vom verwendeten Webserver und Back-End-Stack ab. Lesen Sie daher in der Dokumentation der jeweiligen Sprache nach, wie Sie vorgehen müssen.

Bleiben Sie bei zukünftigen Service Worker-Bereitstellungen bei nicht versionierten Asset-Namen (z. B. sw.js). Dadurch wird die Sache später viel einfacher.

Clear-Site-Data-Header festlegen

Einige Browser heben die Registrierung aller Service Worker für einen Ursprung auf, wenn ein Clear-Site-Data-Antwortheader mit dem Wert 'storage' festgelegt ist. Bei diesem Ansatz sind jedoch einige Dinge zu beachten:

Da diese Überschrift nicht vollständig unterstützt wird, reicht es nicht aus, sich bei der Lösung des Problems allein darauf zu verlassen. Daher empfiehlt es sich, zusätzlich zur Bereitstellung eines managementfreien Service Workers Clear-Site-Data als Maßnahme zu betrachten.

Der Schaden ist nicht dauerhaft

Es kann beängstigend sein, wenn die User Experience durch einen fehlerhaften Service Worker gestört wird – insbesondere bei großen und bekannten Websites –, aber der Schaden ist vorübergehend und kann rückgängig gemacht werden!

Wenn es erforderlich ist, einen No-Op-Service Worker bereitzustellen, um die Situation zu beheben, nehmen Sie sich danach Zeit, um herauszufinden, was genau schiefgelaufen ist. Sorgen Sie in Zukunft dafür, dass ein Service Worker nur die erwarteten Anfragen verarbeitet. Testen Sie häufig im Staging und stellen Sie Updates nur dann bereit, wenn sie sicher sind.