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 Beispielpath/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 wiepath/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 hypothetischepath/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.