Mit einem Service Worker können Sie auf Navigationsanfragen reagieren, ohne auf das Netzwerk zu warten.
Navigationsanfragen sind Anfragen für HTML-Dokumente, die von Ihrem Browser gesendet werden, wenn Sie eine neue URL in die Navigationsleiste eingeben oder einem Link auf einer Seite folgen, der zu einer neuen URL führt. Hier haben Service Worker den größten Einfluss auf die Leistung: Wenn Sie einen Service Worker verwenden, um auf Navigationsanfragen zu reagieren, ohne auf das Netzwerk zu warten, können Sie dafür sorgen, dass Navigationen zuverlässig schnell und auch dann leistungsfähig sind, wenn das Netzwerk nicht verfügbar ist. Dies ist der größte Leistungsvorteil eines Service Workers im Vergleich zu dem, was mit HTTP-Caching möglich ist.
Wie im Leitfaden Über das Netzwerk geladene Ressourcen ermitteln beschrieben, ist eine Navigationsanfrage die erste von potenziell vielen Anfragen, die im Abfolgeplan des Netzwerktraffics gestellt werden. Der HTML-Code, den Sie über eine Navigationsanfrage laden, löst den Fluss aller anderen Anfragen für untergeordnete Ressourcen wie Bilder, Scripts und Stile aus.
Im fetch
-Ereignis-Handler eines Service Workers können Sie anhand der request.mode
-Property der FetchEvent
feststellen, ob es sich bei einer Anfrage um eine Navigation handelt. Wenn der Wert 'navigate'
ist, handelt es sich um eine Navigationsanfrage.
Verwenden Sie in der Regel keine langlebigen Cache-Control headers
, um die HTML-Antwort für eine Navigationsanfrage im Cache zu speichern. Sie sollten normalerweise über das Netzwerk mit Cache-Control: no-cache
erfüllt werden, damit die HTML-Datei und die nachfolgenden Netzwerkanfragen (relativ) aktuell sind. Wenn jedes Mal, wenn der Nutzer eine neue Seite aufruft, das Netzwerk kontaktiert werden muss, kann die Navigation möglicherweise langsam sein. In jedem Fall ist die Verbindung nicht zuverlässig schnell.
Verschiedene Ansätze für Architekturen
Es kann schwierig sein, herauszufinden, wie Sie auf Navigationsanfragen reagieren und dabei das Netzwerk vermeiden. Der richtige Ansatz hängt stark von der Architektur Ihrer Website und der Anzahl der eindeutigen URLs ab, zu denen Nutzer gelangen können.
Es gibt keinen universellen Ansatz, aber die folgenden allgemeinen Richtlinien sollten Ihnen helfen zu entscheiden, welcher Ansatz am besten geeignet ist.
Kleine statische Websites
Wenn Ihre Webanwendung aus einer relativ kleinen Anzahl (z. B. ein paar Dutzend) eindeutiger URLs besteht und jede dieser URLs einer anderen statischen HTML-Datei entspricht, können Sie alle diese HTML-Dateien einfach im Cache speichern und auf Navigationsanfragen mit der entsprechenden im Cache gespeicherten HTML-Datei antworten.
Mit dem Vorab-Caching können Sie den HTML-Code bereits vorab im Cache speichern, sobald der Service Worker installiert ist. Aktualisieren Sie den im Cache gespeicherten HTML-Code jedes Mal, wenn Sie Ihre Website neu erstellen und Ihren Service Worker neu bereitstellen.
Wenn Sie das gesamte HTML nicht im Voraus zwischenspeichern möchten, weil Nutzer beispielsweise nur eine Teilmenge der URLs auf Ihrer Website aufrufen, können Sie die Laufzeit-Caching-Strategie Stale-While-Revalidate verwenden. Bei diesem Ansatz ist jedoch Vorsicht geboten, da jedes einzelne HTML-Dokument im Cache gespeichert und separat aktualisiert wird. Das Laufzeit-Caching für HTML eignet sich am besten, wenn Sie nur eine kleine Anzahl von URLs haben, die häufig von denselben Nutzern besucht werden, und wenn Sie damit einverstanden sind, dass diese URLs unabhängig voneinander neu validiert werden.
Einseitige Apps
Eine Single-Page-Architektur wird häufig von modernen Webanwendungen verwendet. Dabei wird der HTML-Code durch clientseitiges JavaScript als Reaktion auf Nutzeraktionen geändert. Bei diesem Modell wird die aktuelle URL über die History API geändert, während der Nutzer mit der Webanwendung interagiert. Dies führt zu einer „simulierten“ Navigation. Auch wenn nachfolgende Navigationen „gefälscht“ sein können, ist die erste Navigation echt und es ist wichtig, darauf zu achten, dass sie nicht im Netzwerk blockiert wird.
Wenn Sie die Single-Page-Architektur verwenden, gibt es glücklicherweise ein einfaches Muster, das Sie beim Bereitstellen der ersten Navigation aus dem Cache befolgen können: die Anwendungs-Shell. Bei diesem Modell antwortet Ihr Service Worker auf Navigationsanfragen, indem er dieselbe einzelne HTML-Datei zurückgibt, die bereits vorab im Cache gespeichert wurde – unabhängig von der angeforderten URL. Dieser HTML-Code sollte einfach sein und beispielsweise aus einem generischen Ladeindikator oder Skelettinhalt bestehen. Sobald der Browser dieses HTML aus dem Cache geladen hat, übernimmt das vorhandene clientseitige JavaScript und rendert die korrekten HTML-Inhalte für die URL aus der ursprünglichen Navigationsanfrage.
Workbox bietet die Tools, die Sie für die Implementierung dieses Ansatzes benötigen. Mit der navigateFallback
option
können Sie angeben, welches HTML-Dokument als App-Shell verwendet werden soll, sowie eine optionale Zulassungs- und Sperrliste, um dieses Verhalten auf einen Teil Ihrer URLs zu beschränken.
Mehrseitige Apps
Wenn Ihr Webserver das HTML Ihrer Website dynamisch generiert oder Sie mehr als ein paar Dutzend eindeutige Seiten haben, ist es viel schwieriger, das Netzwerk bei der Verarbeitung von Navigationsanfragen zu umgehen. Die Tipps unter Sonstiges gelten wahrscheinlich auch für Sie.
Bei bestimmten mehrseitigen Apps können Sie jedoch einen Service Worker implementieren, der die Logik, die auf Ihrem Webserver zum Generieren von HTML verwendet wird, vollständig repliziert. Das funktioniert am besten, wenn Sie Routing- und Vorlageninformationen zwischen der Server- und der Service Worker-Umgebung teilen können, und insbesondere, wenn Ihr Webserver JavaScript verwendet (ohne sich auf Node.js-spezifische Funktionen wie den Dateisystemzugriff zu verlassen).
Wenn Ihr Webserver in diese Kategorie fällt und Sie einen Ansatz zur Verlagerung der HTML-Generierung aus dem Netzwerk in Ihren Service Worker ausprobieren möchten, können Sie mit der Anleitung unter Beyond SPAs: alternative architectures for your PWA (Über SPAs hinaus: alternative Architekturen für Ihre PWA) beginnen.
Alle anderen
Wenn Sie auf Navigationsanfragen nicht mit im Cache gespeichertem HTML antworten können, müssen Sie dafür sorgen, dass das Hinzufügen eines Service Workers zu Ihrer Website (zum Verarbeiten anderer, nicht HTML-Anfragen) die Navigation nicht verlangsamt. Wenn Sie den Service Worker starten, ohne ihn für die Beantwortung einer Navigationsanfrage zu verwenden, führt dies zu einer kleinen Verzögerung (wie im Artikel Schnellere, resilientere Apps mit Service Workern erstellen erläutert). Sie können diesen Overhead verringern, indem Sie die Funktion Navigationsvorab-Laden aktivieren und dann die Netzwerkantwort verwenden, die in Ihrem fetch
-Ereignishandler vorab geladen wurde.
Workbox bietet eine Hilfsbibliothek, die anhand von Funktionen erkennt, ob die Navigationsvorab-Ladefunktion unterstützt wird. Falls ja, wird die Anweisung an Ihren Service Worker, die Netzwerkantwort zu verwenden, vereinfacht.
Foto von Aaron Burden auf Unsplash