Aktuellere Service-Worker (Standard)

Jeff Posnick

Kurzfassung

Ab Chrome 68 werden HTTP-Anfragen, die nach Aktualisierungen des Service Worker-Skripts suchen, nicht mehr länger durch den HTTP-Cache ist standardmäßig aktiviert. Damit lässt sich ein häufiges Problem für Entwickler umgehen, Das könnte dazu führen, dass ein versehentlicher Cache-Control-Header in Ihrem Service Worker-Skript bis hin zu verzögerten Updates.

Wenn Sie HTTP-Caching für Ihr /service-worker.js-Skript bereits durch Bereitstellung deaktiviert haben mit Cache-Control: max-age=0 sind, sollten Sie aufgrund der neuen Standardeinstellung verhalten.

Außerdem wird der Byte-für-Byte-Vergleich ab Chrome 78 auf Skripts angewendet, die in einem Service Worker über importScripts() Bei jeder Änderung, die an einem importierten Skript vorgenommen wird, wird das Ereignis Update-Ablauf des Service Workers genau wie bei einer Änderung des Service Workers der obersten Ebene.

Hintergrund

Rufen Sie jedes Mal, wenn Sie eine neue Seite im Bereich eines Service Workers aufrufen, explizit registration.update() auf. oder wenn ein Service Worker "aufgeweckt" wird. push- oder sync-Ereignis gesendet wird, fordert parallel die JavaScript-Ressource an, die ursprünglich an die navigator.serviceWorker.register(), um nach Aktualisierungen des Service Worker-Skripts zu suchen.

In diesem Artikel nehmen wir an, dass die URL /service-worker.js lautet und die URL einen einzelnen Aufruf von importScripts() enthält, Dadurch wird zusätzlicher Code geladen, der im Service Worker ausgeführt wird:

// Inside our /service-worker.js file:
importScripts('path/to/import.js');

// Other top-level code goes here.

Was ändert sich?

Vor Chrome 68 erfolgte die Aktualisierungsanfrage für /service-worker.js über den HTTP-Cache wie die meisten Abrufe. Wenn das Skript also ursprünglich mit Cache-Control: max-age=600 gesendet wurde, wurden innerhalb der nächsten 600 Sekunden (10 Minuten) keine Aktualisierungen an das Netzwerk gesendet. -Nutzer erhalten möglicherweise nicht die aktuelle Version des Service Workers. Wenn max-age jedoch größer als 86.400 (24 Stunden) ist, wird es so behandelt, als wäre es 86.400, damit Nutzer nicht hängen bleiben. immer mit einer bestimmten Version.

Ab Version 68 wird der HTTP-Cache ignoriert, wenn Aktualisierungen für den Service Worker angefordert werden -Script sein, sodass bei vorhandenen Webanwendungen die Häufigkeit von Anfragen für ihre Service Worker-Skript. Anfragen für importScripts werden weiterhin über den HTTP-Cache geleitet. Aber das ist nur die Standardeinstellung – eine neue Registrierungsoption, updateViaCache, die Kontrolle über dieses Verhaltens.

updateViaCache

Entwickler können jetzt beim Aufrufen von navigator.serviceWorker.register() eine neue Option übergeben: den Parameter updateViaCache. Hierfür sind drei Werte zulässig: 'imports', 'all' oder 'none'.

Die Werte bestimmen, ob und wie der standardmäßige HTTP-Cache des Browsers bei der HTTP-Anfrage zur Überprüfung aktualisierter Service Worker-Ressourcen eine Rolle.

  • Wenn 'imports' festgelegt ist, wird bei der Suche nach Updates für den /service-worker.js-Skript wird jedoch beim Abrufen importierter Skripts konsultiert. (in unserem Beispiel path/to/import.js). Dies ist die Standardeinstellung und entspricht dem Verhalten in Chrome 68.

  • Wenn 'all' festgelegt ist, wird bei Anfragen für den des übergeordneten /service-worker.js-Skripts sowie aller innerhalb des Dienstes importierten Skripts Worker wie path/to/import.js. Diese Option entspricht dem vorherigen Verhalten in Chrome, Chrome-Version 68.

  • Wenn 'none' festgelegt ist, wird der HTTP-Cache bei Anfragen für die /service-worker.js auf oberster Ebene oder importierte Skripts, wie das hypothetische path/to/import.js

Mit dem folgenden Code wird beispielsweise ein Service Worker registriert und sichergestellt, dass der HTTP-Cache nie konsultiert, wenn nach Aktualisierungen für das /service-worker.js-Skript oder Skripts, auf die in /service-worker.js über importScripts() verwiesen wird:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js', {
    updateViaCache: 'none',
    // Optionally, set 'scope' here, if needed.
  });
}

Sucht nach Aktualisierungen für importierte Skripts

Vor Chrome 78 konnten Service Worker-Skripts über importScripts() würde nur einmal abgerufen werden (zuerst mit dem HTTP-Cache oder über die Netzwerk, abhängig von der updateViaCache-Konfiguration). Nach dieser Anfangswahrscheinlichkeit abgerufen werden, werden sie intern im Browser gespeichert und nie erneut abgerufen.

Die einzige Möglichkeit, einen bereits installierten Service Worker dazu zu zwingen, Änderungen die URL des Skripts ändern, in der Regel entweder durch Hinzufügen eines semver-Wert (z.B. importScripts('https://example.com/v1.1.0/index.js')) oder durch Einfügen eines Hashwerts von den Inhalt (z.B. importScripts('https://example.com/index.abcd1234.js')). A Die Änderung der importierten URL hat zur Folge, dass der Service Worker der obersten Ebene ändert sich der Inhalt des Skripts, wodurch Updateablauf für Service Worker.

Ab Chrome 78 wird jedes Mal, wenn eine Updateüberprüfung für eine oberste Ebene durchgeführt wird, durchgeführt. Service Worker-Datei bereitgestellt, werden gleichzeitig überprüft, ob sich der Inhalt der importierten Skripts geändert hat. Je nach Cache-Control-Header verwendet, werden diese importierten Scriptprüfungen möglicherweise durch den HTTP-Cache, wenn updateViaCache auf 'all' oder 'imports' (also auf Andernfalls erfolgt die Überprüfung möglicherweise direkt im Netzwerk, wenn updateViaCache ist auf 'none' eingestellt.

Wenn eine Aktualisierungsprüfung für ein importiertes Skript zu einem Byte-für-Byte-Unterschied führt im Vergleich zu den Daten, die zuvor vom Service Worker gespeichert wurden, den vollständigen Service Worker-Update-Ablauf auslösen, auch wenn der Worker-Datei unverändert bleibt.

Das Verhalten von Chrome 78 entspricht der implemented von Firefox vor einigen Jahren in Firefox 56. Safari implementiert dieses Verhalten bereits als gut.

Was müssen Entwickler tun?

Sie haben das HTTP-Caching für Ihr /service-worker.js-Skript durch Bereitstellung deaktiviert. mit Cache-Control: max-age=0 (oder einem ähnlichen Wert) enthält, sollten Sie aufgrund der zum neuen Standardverhalten.

Wenn Sie das Skript /service-worker.js mit aktiviertem HTTP-Caching bereitstellen, entweder absichtlich oder weil es nur die Standardeinstellung für Ihre Hosting-Umgebung ist, sehen Sie möglicherweise einen Anstieg der zusätzlichen HTTP-Anfragen für /service-worker.js, die Server – dies sind Anfragen, die vom HTTP-Cache erfüllt wurden. Wenn Sie lassen Sie weiterhin zu, dass der Cache-Control-Headerwert die Aktualität Ihrer /service-worker.js festgelegt haben, müssen Sie updateViaCache: 'all' explizit festlegen, Service Worker registriert haben.

Da es viele Longtail-Nutzer mit älteren Browserversionen geben kann, ist es sinnvoll, Setzen Sie den Cache-Control: max-age=0-HTTP-Header für Service Worker-Skripts fort, werden sie möglicherweise von neueren Browsern ignoriert.

Entwickler können diese Gelegenheit nutzen, um zu entscheiden, ob sie ihre importierten Daten explizit aktivieren möchten. aus HTTP-Caching entfernen und updateViaCache: 'none' ihrem Service Worker hinzufügen Registrierung.

Importierte Skripts bereitstellen

Ab Chrome 78 erhalten Entwickler möglicherweise mehr eingehende HTTP-Anfragen für Ressourcen über importScripts() geladen, da sie jetzt auf Aktualisierungen.

Wenn Sie diesen zusätzlichen HTTP-Traffic vermeiden möchten, legen Sie Cache-Control-Header beim Bereitstellen von Skripts, die semver oder Hashes in ihre URLs und verwenden das updateViaCache-Standardverhalten von 'imports'.

Alternativ können Sie möchten, dass die importierten Skripts Stellen Sie sicher, dass Sie sie entweder mit Cache-Control: max-age=0, oder updateViaCache: 'none' verwenden.

Weitere Informationen

Der Service Worker-Lebenszyklus und „Best Practices für das Caching und max-age gotchas beide von Jake Archibald, werden allen Entwicklern empfohlen, die etwas im Web bereitstellen.