Ein Service Worker kann wiederkehrende Besuche robuster machen und wiederholte Netzwerkarbeit vermeiden. Seine Installation verbessert die Core Web Vitals jedoch nicht automatisch. Entscheidend ist, welche Anfragen er bearbeiten soll, wie aktuell die Antworten sein müssen und was bei einer neuen Veröffentlichung geschieht. Beginnen Sie mit einer begrenzten Auswahl öffentlicher Ressourcen. Erweitern Sie den Umfang erst, wenn Tests einen Nutzen zeigen, der den Pflegeaufwand rechtfertigt.
Worker und Cache getrennt betrachten
Ein Service Worker ist ein ereignisgesteuertes Skript, das Anfragen der von ihm kontrollierten Seiten abfangen kann. Cache Storage speichert davon getrennt Paare aus Anfragen und Antworten. Beides ersetzt nicht den HTTP Cache des Browsers. Auch ein Abruf durch den Worker kann den gewöhnlichen HTTP Cache nutzen. Prüfen Sie deshalb zuerst, welche Ebene die Antwort geliefert hat, bevor Sie eine Beschleunigung Ihrem Code zuschreiben.
Cache Storage setzt die HTTP Regeln zur Aktualität nicht automatisch durch. Ihre Anwendung entscheidet, wann Einträge gespeichert, aktualisiert und entfernt werden. Ein Serverheader ersetzt diese Regeln nicht. Wenn Sie lediglich öffentliche Stylesheets und Bilder wiederverwenden möchten, prüfen Sie zunächst die bestehende Konfiguration des Browsercaches, bevor Sie eine programmierbare Ebene ergänzen.
Für jede Ressource eine Strategie wählen
Bei öffentlichen Dateien mit einem Inhaltsfingerabdruck in der URL ist es sinnvoll, zuerst im Cache und erst danach im Netzwerk nachzusehen. Eine unveränderte URL steht dabei für unveränderte Inhalte. Diese Logik eignet sich nicht ohne Weiteres für Kontodaten, Verfügbarkeit oder HTML, das eine neue Veröffentlichung abbilden muss.
Ein vorrangiger Netzwerkabruf begünstigt aktuelle Antworten, kann Besucher bei einer unzuverlässigen Verbindung aber warten lassen. Legen Sie Abbruch, Ersatzantwort und Fehlerbehandlung ausdrücklich fest. Eine gespeicherte Antwort mit gleichzeitiger Aktualisierung im Hintergrund ermöglicht schnelle Wiederverwendung, kann dem aktuellen Besucher jedoch ältere Inhalte zeigen. Außerdem entsteht dabei Netzwerkarbeit, obwohl eine gespeicherte Antwort vorhanden ist.
Das sind Produktentscheidungen. Eine offline verfügbare Hilfeseite kann nützlich sein; eine veraltete Zahlungsbestätigung kann täuschen. Wenden Sie keine universelle Strategie an, nur weil sämtliche Anfragen durch denselben Handler laufen.
Den ersten Besuch berücksichtigen
Registrierung, Installation, Aktivierung und Kontrolle sind unterschiedliche Zustände. Ein neu registrierter Worker kontrolliert normalerweise nicht das ursprüngliche Dokument, das ihn registriert hat. Spätere Besuche können profitieren, sobald er bereit ist. Neue Besucher bleiben zunächst auf den normalen Ladepfad angewiesen.
Umfangreiches Vorabfüllen des Caches kann mit Ressourcen konkurrieren, die die aktuelle Seite benötigt. Speichern Sie nur, was eine bewusst geplante Nutzung unterstützt. Verbessern Sie Serverantwort, Ressourcenerkennung und Rendering unabhängig davon. Die Anleitung zur Serverantwortzeit bleibt relevant, auch wenn ein bereits gecachter Besuch schnell wirkt.
Mit einem bewusst begrenzten Beispiel beginnen
Der folgende beispielhafte Worker speichert eine ausdrücklich festgelegte Auswahl öffentlicher Dateien vorab. Passende Anfragen beantwortet er nach Möglichkeit aus diesem Cache. Legen Sie ihn in einer Workerdatei ab, registrieren Sie diese separat in einem sicheren Kontext und ersetzen Sie die Pfade durch reale Dateien. Die Antworten müssen öffentlich und unabhängig vom Anmeldestatus sein.
const CACHE = "editorialAssetsRelease";
const ASSETS = [
"/assets/site.abc123.css",
"/assets/brand.def456.svg"
];
self.addEventListener("install", event => {
event.waitUntil(
caches.open(CACHE).then(cache => cache.addAll(ASSETS))
);
});
self.addEventListener("fetch", event => {
const request = event.request;
const url = new URL(request.url);
if (request.method !== "GET" ||
url.origin !== self.location.origin ||
!ASSETS.includes(url.pathname + url.search)) return;
event.respondWith((async () => {
let cached;
try {
const cache = await caches.open(CACHE);
cached = await cache.match(request);
} catch {}
return cached || fetch(request);
})());
});Ändern Sie bei einer Veröffentlichung den Cachenamen zusammen mit den URLs, die den Inhaltsfingerabdruck tragen. Scheitert ein erforderlicher Vorababruf, kann die Installation scheitern. Das Beispiel enthält keine HTML Ersatzseite, keinen während der Nutzung wachsenden Cache und keine automatische Übernahme nach einem Update. Damit bleibt sein Umfang nachvollziehbar. Die tatsächliche Integration benötigt weiterhin Registrierung, Updateverwaltung und das geregelte Entfernen anwendungseigener Caches.
Updates mit offenen Tabs vereinbaren
Ein neu installierter Worker kann warten, während der aktive Worker bestehende Clients versorgt. Das hilft, eine alte Seite nicht mit inkompatiblen neuen Ressourcen zu vermischen. skipWaiting() und clients.claim() verändern Lebenszyklus und Kontrolle. Sie sind keine allgemeinen Geschwindigkeitsoptimierungen.
Entscheiden Sie, ob Sie ein Update anbieten, eine normale Neuladung abwarten oder kompatible Versionen parallel unterstützen. Halten Sie frühere Dateien mit Inhaltsfingerabdruck verfügbar, solange bestehende Seiten sie noch anfordern können. Löschen Sie nur Caches Ihrer Anwendung und berücksichtigen Sie aktive Clients bei der Aufbewahrung. Die Dokumentation zum Service Worker Lebenszyklus hilft bei der Planung dieses Übergangs.
Private Inhalte schützen und fehlenden Speicher einplanen
Nehmen Sie Authentifizierung, Kontoseiten und sensible API Antworten vom Caching aus, sofern kein gesondert geprüfter Entwurf etwas anderes verlangt. Eine explizite Liste erlaubter URLs lässt sich leichter überprüfen als das Speichern jeder erfolgreichen Anfrage. Weder ein Cookie noch ein Antwortheader macht einen pauschalen Cache Storage Handler automatisch sicher.
Speichert die Anwendung bewusst benutzerspezifische Inhalte, müssen Abmeldung, Kontowechsel und Löschung gemeinsam geplant werden. Rechnen Sie außerdem damit, dass der Browser gespeicherte Ressourcen entfernt. Der Offlinebetrieb muss erklären, was weiterhin nutzbar ist und was eine Verbindung benötigt. Fehlende Daten dürfen nicht als erfolgreich abgeschlossene Aktion erscheinen.
Zustände testen statt nur einen warmen Cache
Vergleichen Sie einen frischen Besuch, einen kontrollierten Besuch mit gefülltem Speicher, einen Offlinebesuch und ein Update mit weiterhin geöffnetem altem Tab. Prüfen Sie Geltungsbereich und Controller des Workers, die tatsächlichen Cache Storage Einträge sowie die Herkunft der Antworten. Das Abschalten des HTTP Caches in den Entwicklerwerkzeugen beweist nicht, dass Cache Storage umgangen wurde.
Untersuchen Sie langsames Verhalten mit einer Aufzeichnung und überprüfen Sie Auswirkungen auf Besucher mit Felddaten. Für eine gute Bewertung gelten LCP bis einschließlich 2.5 s, INP bis einschließlich 200 ms und CLS bis einschließlich 0.1. Bewertet wird das 75. Perzentil, getrennt nach Mobilgeräten und Desktop. Ein schneller wiederholter lokaler Besuch belegt nicht, dass die Verteilung im Feld diese Grenzen einhält.
Behalten Sie den Worker, wenn sein Nutzen nachvollziehbar ist. Korrekte Inhalte, vorhersehbare Updates und verlässliche Wiederherstellung gehören zur Performancearbeit. Die Erklärung zu Feld und Labordaten hilft, die Beobachtungen richtig einzuordnen.
