Mit einem Service Worker auf Navigationsanfragen antworten, ohne auf das Netzwerk zu warten.
Navigationsanfragen sind Anfragen für HTML-Dokumente, die von Ihrem Browser 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 die Navigation zuverlässig schnell ist und auch dann funktioniert, wenn das Netzwerk nicht verfügbar ist. Das ist der größte Leistungsvorteil, den ein Service Worker im Vergleich zum HTTP-Caching bietet.
Wie im Leitfaden Über das Netzwerk geladene Ressourcen identifizieren beschrieben, ist eine Navigationsanfrage die erste von potenziell vielen Anfragen im „Wasserfall“ des Netzwerkverkehrs. Der HTML-Code, den Sie über eine Navigationsanfrage laden, löst den Fluss aller anderen Anfragen für Unterressourcen wie Bilder, Skripts und Stile aus.
Im fetch-Event-Handler eines Service Workers können Sie anhand der request.mode-Property des FetchEvent feststellen, ob es sich bei einer Anfrage um eine Navigation handelt. Wenn der Wert auf 'navigate' festgelegt 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, um sicherzustellen, dass der HTML-Code zusammen mit der Kette nachfolgender Netzwerkanfragen (einigermaßen) aktuell ist. Wenn bei jedem Aufruf einer neuen Seite durch den Nutzer eine Anfrage an das Netzwerk gesendet wird, kann die Navigation langsam sein. Zumindest bedeutet es, dass sie nicht zuverlässig schnell ist.
Verschiedene Ansätze für Architekturen
Es kann schwierig sein, herauszufinden, wie auf Navigationsanfragen reagiert werden soll, ohne das Netzwerk zu verwenden. 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 keine allgemeingültige Lösung, 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 im Cache speichern und auf Navigationsanfragen mit der entsprechenden im Cache gespeicherten HTML-Datei antworten.
Mit Precaching kannst du den HTML-Code im Voraus im Cache speichern, sobald der Service Worker installiert ist. Außerdem kannst du den im Cache gespeicherten HTML-Code jedes Mal aktualisieren, wenn du deine Website neu erstellst und den Service Worker neu bereitstellst.
Wenn du nicht alle HTML-Inhalte im Voraus im Cache speichern möchtest, weil Nutzer beispielsweise nur einen Teil der URLs auf deiner Website aufrufen, kannst du eine Stale-While-Revalidate-Laufzeit-Caching-Strategie verwenden. Seien Sie jedoch vorsichtig, da jedes einzelne HTML-Dokument separat im Cache gespeichert und aktualisiert wird. Die Verwendung von Laufzeit-Caching für HTML ist am besten geeignet, wenn Sie eine kleine Anzahl von URLs haben, die von denselben Nutzern häufig besucht werden, und wenn Sie damit einverstanden sind, dass diese URLs unabhängig voneinander neu validiert werden.
Einseitige Apps
Moderne Webanwendungen verwenden häufig eine Single-Page-Architektur. Dabei wird der HTML-Code durch clientseitiges JavaScript als Reaktion auf Nutzeraktionen geändert. Bei diesem Modell wird die History API verwendet, um die aktuelle URL zu ändern, wenn der Nutzer mit der Web-App interagiert. Dadurch wird eine Navigation „simuliert“. Auch wenn nachfolgende Navigationsaktionen „falsch“ sein können, ist die erste Navigationsaktion echt und es ist wichtig, dass sie nicht im Netzwerk blockiert wird.
Wenn Sie die Single-Page-Architektur verwenden, gibt es glücklicherweise ein einfaches Muster, um die erste Navigation aus dem Cache bereitzustellen: die Anwendungsshell. In diesem Modell antwortet Ihr Service Worker auf Navigationsanfragen, indem er dieselbe einzelne HTML-Datei zurückgibt, die bereits im Pre-Cache gespeichert wurde – unabhängig von der angeforderten URL. Dieses HTML sollte auf das Wesentliche reduziert sein und beispielsweise aus einer allgemeinen Ladeanzeige oder Skelettinhalten bestehen. Sobald der Browser dieses HTML aus dem Cache geladen hat, übernimmt das vorhandene clientseitige JavaScript und rendert den korrekten HTML-Inhalt für die URL aus der ursprünglichen Navigationsanfrage.
Workbox bietet die Tools, die Sie für die Implementierung dieses Ansatzes benötigen. Mit dem navigateFallback
option können Sie angeben, welches HTML-Dokument als Anwendungsshell verwendet werden soll. Außerdem können Sie eine optionale Zulassungs- und Ablehnungsliste angeben, um dieses Verhalten auf eine Teilmenge Ihrer URLs zu beschränken.
Mehrseitige Apps
Wenn dein Webserver den HTML-Code deiner Website dynamisch generiert oder du mehr als ein paar Dutzend eindeutige Seiten hast, ist es viel schwieriger, das Netzwerk bei der Verarbeitung von Navigationsanfragen zu vermeiden. Die Hinweise unter Alles andere gelten wahrscheinlich für Sie.
Für eine bestimmte Teilmenge von mehrseitigen Apps können Sie jedoch möglicherweise einen Service Worker implementieren, der die Logik Ihres Webservers zur Generierung von HTML vollständig repliziert. Das funktioniert am besten, wenn Sie Routing- und Vorlageninformationen zwischen dem Server und den Service Worker-Umgebungen teilen können und insbesondere, wenn Ihr Webserver JavaScript verwendet (ohne auf Node.js-spezifische Funktionen wie den Zugriff auf das Dateisystem angewiesen zu sein).
Wenn Ihr Webserver in diese Kategorie fällt und Sie einen Ansatz zur Verlagerung der HTML-Generierung vom Netzwerk in Ihren Service Worker ausprobieren möchten, finden Sie im Leitfaden Beyond SPAs: alternative architectures for your PWA (Mehr als SPAs: alternative Architekturen für Ihre PWA) entsprechende Informationen.
Alle anderen
Wenn Sie Navigationsanfragen nicht mit im Cache gespeichertem HTML beantworten können, müssen Sie dafür sorgen, dass das Hinzufügen eines Service Workers zu Ihrer Website (zur Verarbeitung anderer, nicht HTML-Anfragen) die Navigation nicht verlangsamt. Wenn Sie den Service Worker starten, ohne ihn zum Beantworten einer Navigationsanfrage zu verwenden, führt dies zu einer geringen Latenz (wie in Schnellere, stabilere Apps mit Service Worker erstellen erläutert). Sie können diesen Mehraufwand 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, wird der Prozess vereinfacht, mit dem Sie Ihren Service Worker anweisen, die Netzwerkantwort zu verwenden.