Fehlerhafte Service Worker entfernen

Manchmal wird ein fehlerhafter Service Worker bereitgestellt, und dann gibt es Probleme. Beispielsweise kann ein Service Worker bei der Registrierung geparst werden und die Installation erfolgreich abschließen. Fehlerhafter Code in einem fetch-Ereignis kann jedoch dazu führen, dass Anfragen nicht beantwortet werden. führt zu einer leeren Seite. Eine weitere Möglichkeit ist, dass Seiten-Markup oft im Cache gespeichert wird, und ein Service Worker gibt für nachfolgende Besuche nur veraltete Markup-Antworten von einer Cache-Instanz zurück.

Es gibt viele Möglichkeiten, wie ein Service Worker Backfire durchführen kann, und das ist ein beängstigendes Problem bei einer Produktionswebsite. Dennoch ist nicht alles verloren. Es gibt Möglichkeiten, das Problem zu beheben und wieder auf Kurs zu kommen.

No-Op-Service-Worker bereitstellen

Bei einem fehlerhaften Service Worker muss in der Regel lediglich eine einfache no-op-Service Worker, der sofort ohne fetch-Event-Handler 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 wird sofort installiert und aktiviert, indem er self.skipWaiting() im Ereignis install Optional kann im Ereignis activate zusätzlicher Code bereitgestellt werden, um das Aktualisieren aller anderen geöffneten Tabs mit einer WindowClient zu erzwingen, die der Service Worker steuert.

Es ist sehr wichtig, dass ein managementfreier Service Worker keinen fetch-Event-Handler enthält. Wenn ein Service Worker keine Anfragen verarbeitet, werden diese Anfragen an den Browser weitergeleitet, als wäre kein Service Worker vorhanden. Sobald ein managementfreier Service Worker bereitgestellt wurde, kann der fehlerhafte Service Worker behoben und später als Update bereitgestellt werden.

Dieser Ansatz funktioniert teilweise, weil die Browser starke Absicherungen gegen die Platzierung von Service-Workern im HTTP-Cache haben und dass sie Byte-für-Byte-Prüfungen der Inhalte eines Service-Workers auf Aktualisierungen durchführen. Diese Standardeinstellungen ermöglichen es, einen fehlerfreien Ersatz für einen fehlerhaften Service Worker bereitzustellen, um das Problem schnell zu beheben.

Weitere zu ergreifende Maßnahmen

Die Bereitstellung eines No-Op-Service-Workers sollte ausreichen, um einen fehlerhaften Service bei Bedarf können jedoch weitere Maßnahmen ergriffen werden.

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

Manchmal ist die URL eines zuvor installierten Service Workers unbekannt. Das könnte daran liegen, dass die Datei versioniert ist (z. B. enthält der Dateiname ein Hash). In diesem Fall kann es eine Herausforderung sein, einen managementfreien Service Worker bereitzustellen, der mit der URL jedes alten Service Workers übereinstimmt, der möglicherweise registriert ist. Das verstößt gegen die Best Practices, da Entwickler sich 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 No-Op-Service-Worker zu bedienen. Ob dies funktioniert, hängt vom verwendeten Webserver und Back-End-Stack ab. Eine entsprechende Anleitung finden Sie in der Dokumentation der jeweiligen Sprache.

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

Clear-Site-Data-Header festlegen

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

• Beachten Sie, dass dadurch der gesamte Speicher für den zugehörigen Ursprung gelöscht wird. Dazu gehören localStorage, IndexedDB, sessionStorage und andere Speicher (aber nicht der HTTP-Cache für den Ursprung).
• Dieser Header wird nicht in allen Browsern unterstützt.

Da dieser Header nicht vollständig unterstützt wird, kann das Problem nicht allein dadurch behoben werden. Daher ist es am besten, Clear-Site-Data nicht nur als Maßnahme anzusehen, die zusätzlich zur Bereitstellung eines managementfreien Service Workers erforderlich ist.

Der Schaden ist nicht dauerhaft

Es kann beängstigend sein, wenn die Nutzererfahrung durch einen fehlerhaften Service Worker gestört wird – insbesondere bei großen und bekannten Websites –, aber der Schaden ist nur vorübergehend und lässt sich rückgängig machen.

Wenn zur Behebung des Problems ein No-Op-Service-Worker bereitgestellt werden muss, um herauszufinden, was schiefgelaufen ist. Stellen Sie in Zukunft sicher, dass ein Service Worker nur die Anfragen verarbeitet, die er erwarten. Führen Sie regelmäßig Tests im Staging durch und stellen Sie Updates nur bereit, wenn Sie sicher sind.