Mit einem Service Worker auf Navigationsanfragen antworten, ohne im Netzwerk zu warten
Navigationsanfragen sind Anfragen für HTML-Dokumente, die von Ihrem Browser immer dann gestellt werden, wenn Sie eine neue URL in die Navigationsleiste eingeben oder einem Link auf einer Seite folgen, der Sie 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 antworten, ohne auf das Netzwerk zu warten, können Sie dafür sorgen, dass das Aufrufen zuverlässig schnell erfolgt und auch bei Nichtverfügbarkeit des Netzwerks stabil ist. Dies ist der größte Leistungsgewinn durch einen Service Worker im Vergleich zu dem, was mit HTTP-Caching möglich ist.
Wie im Leitfaden Aus dem Netzwerk geladene Ressourcen identifizieren beschrieben, ist eine Navigationsanfrage die erste von potenziell vielen Anfragen, die im Wasserfall des Netzwerktraffics gestellt werden. Mit dem HTML-Code, den Sie über eine Navigationsanfrage laden, werden alle anderen Anfragen für Unterressourcen wie Bilder, Skripts und Stile gestartet.
Im fetch-Event-Handler eines Service Workers können Sie anhand des Attributs request.mode für FetchEvent feststellen, ob eine Anfrage eine Navigation ist. Ist es auf 'navigate' gesetzt, handelt es sich um eine Navigationsanfrage.
Verwende im Allgemeinen keinen 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 bereitgestellt werden, um sicherzustellen, dass der HTML-Code zusammen mit der Kette nachfolgender Netzwerkanfragen (in angemessenem Maße) aktuell ist. Wird jedes Mal, wenn der Nutzer eine neue Seite aufruft, die Netzwerkverbindung aktiv, bedeutet dies leider, dass die Navigation möglicherweise langsam ist. Zumindest bedeutet dies, dass sie nicht zuverlässig schnell ist.
Verschiedene Ansätze für Architekturen
Es kann schwierig sein, herauszufinden, wie auf Navigationsanfragen reagiert und gleichzeitig das Netzwerk vermieden wird. Der richtige Ansatz hängt stark von der Architektur Ihrer Website und der Anzahl der eindeutigen URLs ab, die Nutzer aufrufen können.
Es gibt zwar keine Universallösung, aber die folgenden allgemeinen Richtlinien helfen Ihnen bei der Entscheidung, welcher Ansatz am besten geeignet ist.
Kleine statische Websites
Wenn Ihre Webanwendung aus einer relativ kleinen Anzahl eindeutiger URLs besteht und jede dieser URLs einer anderen statischen HTML-Datei entspricht, ist es sinnvoll, alle diese HTML-Dateien im Cache zu speichern und auf Navigationsanfragen mit dem entsprechenden zwischengespeicherten HTML-Code zu antworten.
Mithilfe der Precaching-Funktion können Sie den HTML-Code im Voraus speichern, sobald der Service Worker installiert wurde, und den im Cache gespeicherten HTML-Code jedes Mal aktualisieren, wenn Sie Ihre Website neu erstellen und den Service Worker neu bereitstellen.
Wenn Sie es lieber vermeiden möchten, Ihren gesamten HTML-Code vorab im Cache zu speichern – weil Nutzer beispielsweise dazu neigen, nur einen Teil der URLs auf Ihrer Website aufzurufen – können Sie eine veraltete Strategie für das Laufzeit-Caching verwenden. Gehen Sie bei diesem Ansatz jedoch vorsichtig vor, da jedes einzelne HTML-Dokument separat im Cache gespeichert und aktualisiert wird. Das Laufzeit-Caching für HTML ist am besten geeignet, wenn Sie eine geringe Anzahl von URLs haben, die häufig von derselben Gruppe von Nutzern noch einmal aufgerufen werden, und wenn Sie kein Problem damit haben, dass diese URLs unabhängig voneinander neu validiert werden.
Einseitige Apps
Eine Single-Page-Architektur wird häufig von modernen Webanwendungen verwendet. Darin ändert clientseitiges JavaScript den HTML-Code als Reaktion auf Nutzeraktionen. Dieses Modell verwendet die Verlaufs-API, um die aktuelle URL zu ändern, während der Nutzer mit der Web-App interagiert. Dies führt zu einer sogenannten "simulierten" Navigation. Auch wenn nachfolgende Navigationen „Fake“ sein können, ist die ursprüngliche Navigation echt. Es ist trotzdem wichtig, dass sie im Netzwerk nicht blockiert ist.
Wenn Sie die Single-Page-Architektur verwenden, gibt es für die anfängliche Navigation aus dem Cache ein einfaches Muster: die Anwendungsshell. In diesem Modell antwortet der 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 einem Basisinhalt bestehen. Sobald der Browser diesen HTML-Code aus dem Cache geladen hat, übernimmt Ihr vorhandenes clientseitiges JavaScript und rendert den richtigen HTML-Inhalt für die URL aus der ursprünglichen Navigationsanfrage.
Workbox bietet die Tools, die Sie zur Implementierung dieses Ansatzes benötigen. Mit navigateFallback
option können Sie angeben, welches HTML-Dokument als Anwendungs-Shell verwendet werden soll. Außerdem können Sie eine optionale Zulassungs- und Sperrliste angeben, um dieses Verhalten auf eine Teilmenge Ihrer URLs zu beschränken.
Mehrseitige Apps
Wenn Ihr Webserver den HTML-Code Ihrer Website dynamisch generiert oder Sie mehr als ein paar Dutzend Seiten haben, ist es viel schwieriger, das Netzwerk bei der Verarbeitung von Navigationsanfragen zu umgehen. Die Tipps unter Alles andere gelten wahrscheinlich auch für Sie.
Für einen Teil der mehrseitigen Anwendungen können Sie jedoch möglicherweise einen Service Worker implementieren, der die in Ihrem Webserver verwendete Logik vollständig repliziert, um HTML zu generieren. Das funktioniert am besten, wenn Sie Routing- und Vorlageninformationen zwischen der Server- und der Service Worker-Umgebung freigeben können und insbesondere wenn Ihr Webserver JavaScript verwendet (ohne auf Node.js-spezifische Funktionen wie den Dateisystemzugriff angewiesen zu sein).
Wenn Ihr Webserver in diese Kategorie fällt und Sie einen Ansatz untersuchen möchten, um die HTML-Generierung aus dem Netzwerk in Ihren Service Worker zu verschieben, finden Sie unter Über SPAs hinaus: alternative Architekturen für Ihre PWA Informationen zum Einstieg.
Alles andere
Wenn Sie auf Navigationsanfragen nicht mit im Cache gespeichertem HTML-Code antworten können, müssen Sie dafür sorgen, dass das Hinzufügen eines Service Workers zur Verarbeitung anderer Nicht-HTML-Anfragen Ihre Navigation nicht verlangsamt. Wenn Sie den Service Worker starten, ohne ihn zum Antworten auf eine Navigationsanfrage zu verwenden, kommt es zu einer geringen Latenz, wie unter Mit Service Worker schnellere, stabilere Anwendungen erstellen erläutert. Sie können diesen Aufwand reduzieren, indem Sie die Funktion Vorabladen der Navigation aktivieren und dann die Netzwerkantwort verwenden, die in Ihrem fetch-Event-Handler vorab geladen wurde.
Workbox bietet eine Hilfsbibliothek, die erkennt, ob das Vorabladen der Navigation unterstützt wird. Wenn ja, vereinfacht sie die Anweisung Ihres Service Workers, die Netzwerkantwort zu verwenden.
Foto von Aaron Burden bei Unsplash