Wer eine Website zum zweiten Mal besucht, sollte sie schneller sehen als beim ersten Mal. In der Praxis ist das oft nicht so: Der Browser fragt bei jedem Aufruf erneut beim Server nach, durchläuft DNS-Auflösung, Verbindungsaufbau und Serverantwort und wartet, bis die kritischen Dateien über das Netz eintreffen. Ein Service Worker ändert diese Reihenfolge grundlegend. Er ist ein kleines Skript, das der Browser zwischen die Seite und das Netzwerk schiebt und das kritische Dateien lokal vorhält. Beim nächsten Besuch beantwortet er Anfragen aus diesem Cache, oft ohne einen einzigen Server-Roundtrip. Die Technik ist erwachsen geworden: Die Service-Worker-Nutzung ist von 1,7 Prozent (Web Almanac 2025) im Jahr 2022 auf 19,2 Prozent (Web Almanac 2025) gestiegen, also rund um das Zehnfache. Dieser Beitrag erklärt, wie Precaching funktioniert, welche Caching-Strategien es gibt, wo die Grenzen liegen und für welche Projekte sich der Aufwand lohnt. Wer die vier Ladephasen einer Seite noch nicht sauber getrennt hat, findet die Grundlagen in unserer Analyse der LCP-Subparts; dieser Beitrag setzt beim wiederkehrenden Besuch an.
Das Wichtigste in Kürze
- Ein Service Worker sitzt als programmierbare Schicht zwischen Seite und Netzwerk und kann Anfragen aus einem lokalen Cache beantworten, statt sie an den Server weiterzureichen.
- Precaching legt die kritischen Dateien bereits bei der Installation ab, sodass wiederkehrende Besuche fast ohne Server-Roundtrip auskommen.
- Die Wahl der Caching-Strategie entscheidet, ob Nutzer stets die schnellste oder stets die frischeste Antwort erhalten – beides zugleich gibt es nicht.
- Ein Service Worker ersetzt keine schnelle Serverantwort und keinen sauberen Ladepfad; er wirkt zusätzlich, vor allem ab dem zweiten Besuch.
- Der größte Hebel liegt bei Projekten mit hoher Wiederkehrerquote und wackeligen Verbindungen; für reine Einmalbesuche ist der Nutzen gering.
Was ein Service Worker ist und wo er sitzt
Ein Service Worker ist ein JavaScript-Skript, das der Browser unabhängig von der eigentlichen Seite ausführt. Anders als gewöhnliches Seitenskript läuft er in einem eigenen Kontext, hat keinen direkten Zugriff auf das sichtbare Dokument und bleibt aktiv, auch wenn kein Tab der Seite geöffnet ist. Seine zentrale Fähigkeit ist das Abfangen von Netzwerkanfragen: Jede Anfrage, die die Seite stellt – für ein Bild, eine Schrift, eine API-Antwort – läuft durch den Service Worker, der entscheiden darf, ob er sie aus dem Cache beantwortet, ans Netz weiterreicht oder beides kombiniert.
Damit sitzt der Service Worker an einer mächtigen Stelle: als programmierbarer Vermittler zwischen Browser und Netzwerk. Diese Position ist der Grund, warum er nur über HTTPS funktioniert – eine Schicht, die jede Anfrage lesen und umleiten kann, wäre über eine unverschlüsselte Verbindung ein Sicherheitsrisiko. Sie erklärt auch, warum die Technik reifer und verbreiteter geworden ist: Inzwischen registrieren 19,2 Prozent (Web Almanac 2025) der untersuchten Seiten einen Service Worker, während mindestens ein Merkmal einer Progressive Web App auf 24,5 Prozent (Web Almanac 2025) der Seiten vorkommt. Wie schnell die eigentliche Serverantwort ausfällt, bleibt dennoch wichtig und ist Thema unserer Server-Optimierung.
Der Lebenszyklus in drei Schritten
Precaching: kritische Dateien bei der Installation ablegen
Precaching ist der Kern des Geschwindigkeitsgewinns. Bei der Installation des Service Workers wird eine feste Liste kritischer Dateien – das Grundgerüst der Seite, das zentrale Stylesheet, das wichtigste Skript, ein Logo, eine Schrift – einmal heruntergeladen und im sogenannten Cache Storage abgelegt. Diese Dateien liegen danach lokal im Browser. Beim nächsten Besuch muss der Browser sie nicht erneut über das Netz anfordern, sondern erhält sie direkt aus dem lokalen Speicher: in Millisekunden statt in einem vollen Roundtrip über DNS, Verbindungsaufbau und Serverantwort.
Der Unterschied zum gewöhnlichen HTTP-Cache des Browsers ist die Kontrolle. Der HTTP-Cache folgt den Vorgaben des Servers und kann jederzeit verdrängt werden; der Service-Worker-Cache wird vom Entwickler explizit befüllt und bleibt bestehen, bis das Skript ihn aktiv ersetzt. Das macht Precaching planbar: Man weiß genau, welche Dateien nach der Installation verfügbar sind. Gleichzeitig verlangt es Disziplin, denn eine veraltete Datei im Precache bleibt so lange erhalten, bis eine neue Version des Service Workers sie ersetzt. Wie sich das mit klassischem Server-Caching verzahnt, behandelt unser Überblick zu Caching-Strategien.
Bei der Installation füllen
Die App-Hülle – Grundgerüst, kritisches CSS, zentrales Skript – wird einmal heruntergeladen und dauerhaft abgelegt. Der erste Besuch zahlt diesen Preis, jeder weitere profitiert davon.
Aus dem Cache antworten
Kommt eine Anfrage für eine vorgehaltene Datei, liefert der Service Worker sie direkt aus dem Cache Storage – ohne Netzwerk, ohne Serverdenkzeit, in wenigen Millisekunden.
Kontrolliert erneuern
Ändert sich eine Datei, aktualisiert eine neue Version des Service Workers das Precache. So bleibt der Bestand aktuell, ohne dass Nutzer veraltete Inhalte zu sehen bekommen.
Erstbesuch gegen Wiederkehr: wo die Zeit gespart wird
Der entscheidende Punkt ist, dass ein Service Worker den ersten Besuch kaum beschleunigt. Beim allerersten Aufruf existiert noch kein Cache; der Browser muss das Skript herunterladen, installieren und das Precache befüllen – das kostet sogar minimal zusätzliche Zeit. Der Gewinn entsteht ab dem zweiten Besuch. Dann liegen die kritischen Dateien bereits lokal, und die Seite baut sich auf, ohne dass ein einziger Roundtrip über das Netz nötig ist. Genau dieser Unterschied macht die Technik für Angebote mit hoher Wiederkehrerquote interessant.
| Aspekt | Erstbesuch | Wiederkehr mit Service Worker |
|---|---|---|
| Herkunft der Dateien | Server über das Netz | lokaler Cache im Browser |
| Netzwerkschritte | DNS, TCP, TLS, Serverantwort | meist keine |
| Verhalten bei schlechtem Netz | wartet oder bricht ab | liefert die App-Hülle sofort |
| Serverlast | voller Seitenaufruf | entlastet, nur Datenabgleich |
Der Effekt wirkt zusätzlich zu allen serverseitigen Maßnahmen, nicht an ihrer Stelle. Eine unnötige Weiterleitung etwa kostet auch beim wiederkehrenden Besuch einen Roundtrip, wenn sie nicht sauber aufgelöst ist – deshalb bleibt das Vermeiden von Weiterleitungsketten auch mit Service Worker sinnvoll. Erst das Zusammenspiel aus schnellem Server, kurzem Ladepfad und lokalem Cache ergibt den durchgängig schnellen Eindruck, den Nutzer ab dem zweiten Besuch erwarten.
Caching-Strategien: welche Antwort woher kommt
Ein Service Worker beantwortet nicht jede Anfrage gleich. Für jeden Dateityp lässt sich festlegen, ob zuerst der Cache oder zuerst das Netz gefragt wird. Diese Entscheidung ist der eigentliche Hebel, denn sie steuert den Kompromiss zwischen Tempo und Aktualität. Vier Grundmuster haben sich etabliert; welches passt, hängt davon ab, wie oft sich der jeweilige Inhalt ändert und wie schlimm eine leicht veraltete Antwort wäre.
| Strategie | Woher kommt die Antwort | Geeignet für | Kompromiss |
|---|---|---|---|
| Cache First | zuerst Cache, sonst Netz | statische Dateien, App-Hülle | frisch erst nach einem Update |
| Network First | zuerst Netz, sonst Cache | häufig wechselnde Inhalte | langsam bei schlechtem Netz |
| Stale While Revalidate | sofort Cache, Update im Hintergrund | Inhalte mit etwas Toleranz | erste Antwort evtl. leicht veraltet |
| Network Only | stets das Netz | Zahlungen, personalisierte Daten | kein Offline-Nutzen |
Veraltete Antworten vermeiden
Was ein Service Worker nicht leistet
So wirksam Precaching ist, es löst nicht jedes Performance-Problem. Ein Service Worker macht eine langsame Serverantwort nicht schneller, solange der Inhalt nicht aus dem Cache kommt – der Weg zum Server bleibt derselbe. Er repariert auch keinen überladenen Ladepfad: Wenn die Seite beim ersten Besuch zu viel JavaScript ausführt oder das größte Bild zu spät entdeckt, bleibt dieser erste Eindruck langsam – ein Fall für die Frontend-Optimierung, nicht für den Cache. Und er hilft dort wenig, wo Menschen eine Seite nur ein einziges Mal aufrufen, etwa auf reinen Kampagnen-Landingpages ohne Wiederkehr. Der Service Worker ist ein Beschleuniger für den zweiten und jeden weiteren Besuch, kein Ersatz für solide Core Web Vitals beim ersten.
Der Kern in einem Satz
Vom Cache zur installierbaren Progressive Web App
Ein Service Worker allein macht eine Seite schnell im Wiederkehrfall; zusammen mit einem Web-App-Manifest wird sie zur Progressive Web App. Das Manifest ist eine kleine Beschreibungsdatei mit Name, Symbolen, Startadresse und Farben. Erfüllt eine Seite die technischen Voraussetzungen – unter anderem ein Service Worker und ein gültiges Manifest – bieten Browser an, sie wie eine App zum Startbildschirm hinzuzufügen. Sie startet dann im eigenen Fenster, ohne Adressleiste, und fühlt sich näher an einer nativen App an.
Das Potenzial ist groß, aber wenig ausgeschöpft. Zwar nutzen 24,5 Prozent (Web Almanac 2025) der Seiten mindestens ein PWA-Merkmal, doch vollständige Progressive Web Apps mit Service Worker und Manifest kommen nur auf 3,5 Prozent (Web Almanac 2025) der mobilen Seiten. Für viele Angebote mit treuer Nutzerschaft bleibt hier ein spürbarer Vorteil liegen. Ob sich der Schritt lohnt, gehört in eine ehrliche Bestandsaufnahme – unsere Leistungen rund um Progressive Web App Performance setzen genau dort an.
Der größte Fehler ist, einen Service Worker als Turbo für den ersten Besuch zu verkaufen. Sein Wert liegt im zweiten, dritten, zehnten Aufruf – bei Nutzern, die wiederkommen. Wer keine Wiederkehr hat, gewinnt hier wenig; wer viel Wiederkehr hat, gewinnt spürbar.
Wann sich der Aufwand lohnt
Ein Service Worker ist zusätzlicher Code, der gepflegt und getestet werden will. Diese Investition rechnet sich nicht überall gleich. Entscheidend ist die Frage, wie oft dieselben Menschen dieselbe Seite aufrufen und unter welchen Bedingungen sie das tun. Je höher die Wiederkehrerquote und je wackeliger die Verbindungen, desto größer der Gewinn.
- Nutzer kehren regelmäßig zurück, etwa in Shops, Portalen oder Web-Anwendungen mit Anmeldung
- Ein spürbarer Teil des Verkehrs kommt über mobile oder instabile Verbindungen
- Die Seite hat eine klar abgrenzbare App-Hülle, die sich selten ändert
- Es gibt Inhalte, die auch offline oder bei kurzem Verbindungsabbruch nutzbar bleiben sollten
- Das Team kann den Service Worker versionieren und Änderungen kontrolliert ausrollen
Erst messen, dann bauen
Für Angebote mit hoher Wiederkehr ist ein gut gebauter Service Worker eine der wirksamsten Maßnahmen für das gefühlte Tempo, weil er genau die Wartezeit entfernt, die Nutzer am stärksten wahrnehmen: das erneute Laden bekannter Inhalte. Wie ein solches Setup für Ihr Projekt aussehen kann und welche typischen Szenarien wir dabei begleiten, zeigen unsere Referenzen; den passenden Rahmen dazu finden Sie in unseren Preisen.
Verwandte Artikel
Style-Recalculation: wenn CSS erst im Browser bremst
Warum Stilberechnung zur Laufzeit Zeit kostet, wie Selector Stats und Long Animation Frames den Anteil sichtbar machen und welche Eingriffe den Umfang senken.
Checkout-Tempo: die letzten Sekunden vor der Bestellung
Der Checkout lässt sich nicht wegcachen: Warum die fünf Schritte vor der Bestellung eigene Tempo-Budgets brauchen und wo im Shop Sie messen sollten.
Zielgerät statt Testgerät: Tempo auf schwacher Hardware
Warum das Entwicklergerät die falsche Messlatte ist, welches Referenzgerät das 75. Perzentil trifft und wie daraus ein belastbares Performance-Budget wird.