Netzwerkzeitüberschreitung erzwingen

Es kann vorkommen, dass Sie zwar eine Netzwerkverbindung haben, diese aber entweder zu langsam ist oder Sie haben angegeben, dass Sie online sind. In solchen Fällen, in denen sich ein Service Worker befindet, kann es bei einer netzwerkorientierten Caching-Strategie zu lange dauern, bis eine Antwort vom Netzwerk empfangen wird. Andernfalls bleibt die Anfrage hängen und die Ladekreise laufen endlos, bis Sie eine Fehlerseite erhalten.

In jeder Situation gibt es Fälle, in denen für ein Asset oder eine Seite nach einem bestimmten Zeitraum ein Fallback auf die letzte im Cache gespeicherte Antwort für ein Asset oder eine Seite sinnvoll wäre – ein weiteres Problem, bei dem Workbox Ihnen helfen kann.

networkTimeoutSeconds verwenden

Mit der Strategie NetworkFirst und NetworkOnly kann ein Zeitlimit für Netzwerkanfragen erzwungen werden. Diese Strategien bieten eine networkTimeoutSeconds-Option, die die Anzahl der Sekunden angibt, die der Service Worker auf das Eintreffen der Netzwerkantwort warten soll, bevor er die letzte im Cache gespeicherte Version der Netzwerkantwort zurückgibt:

// sw.js
import { NetworkFirst } from 'workbox-strategies';
import { registerRoute, NavigationRoute } from 'workbox-routing';

// Only wait for three seconds before returning the last
// cached version of the requested page.
const navigationRoute = new NavigationRoute(new NetworkFirst({
  networkTimeoutSeconds: 3,
  cacheName: 'navigations'
}));

registerRoute(navigationRoute);

Der obige Code weist Ihren Service Worker an, alle netzwerkorientierten Navigationsanfragen zu verwerfen und die letzte im Cache gespeicherte Version nach drei Sekunden zu verwenden. Bei Verwendung mit Navigationsanfragen wird der Zugriff auf die letzte im Cache gespeicherte Antwort einer zuvor besuchten Seite garantiert.

Was passiert jedoch, wenn die Seite, auf die Sie zugreifen, keine ältere Antwort im Cache enthält? In solchen Fällen können Sie eine Fallback-Antwort auf eine allgemeine Offline-HTML-Seite erstellen:

import {registerRoute, NavigationRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

// Hardcode the fallback cache name and the offline
// HTML fallback's URL for failed responses
const FALLBACK_CACHE_NAME = 'offline-fallback';
const FALLBACK_HTML = '/offline.html';

// Cache the fallback HTML during installation.
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(FALLBACK_CACHE_NAME).then((cache) => cache.add(FALLBACK_HTML)),
  );
});

// Apply a network-only strategy to navigation requests.
// If offline, or if more than five seconds pass before there's a
// network response, fall back to the cached offline HTML.
const networkWithFallbackStrategy = new NetworkOnly({
  networkTimeoutSeconds: 5,
  plugins: [
    {
      handlerDidError: async () => {
        return await caches.match(FALLBACK_HTML, {
          cacheName: FALLBACK_CACHE_NAME,
        });
      },
    },
  ],
});

// Register the route to handle all navigations.
registerRoute(new NavigationRoute(networkWithFallbackStrategy));

Das funktioniert, weil der Handler bei Verwendung von networkTimeoutSeconds in einer NetworkFirst-Strategie eine Fehlerantwort zurückgibt, wenn das Zeitlimit überschritten wird und es keine Cache-Übereinstimmung für die URL gibt. In diesem Fall kann das Workbox-Plug-in handlerDidError eine allgemeine Antwort als Fallback liefern.

Wie lange muss ich warten?

Wenn Sie eine Zeitüberschreitung für Anfragen – insbesondere Navigationsanfragen – erzwingen, ist es wichtig, das richtige Gleichgewicht zu finden: den Nutzer nicht zu lange warten zu lassen und nicht zu schnell eine Zeitüberschreitung zu vermeiden. Wenn Sie zu lange warten, besteht die Gefahr, dass Nutzer bei langsamen Verbindungen abspringen, bevor die Zeitüberschreitung auftritt. Das Zeitlimit wird zu schnell festgelegt, sodass möglicherweise veraltete Inhalte aus dem Cache bereitgestellt werden.

Die richtige Antwort lautet: „Das kommt darauf an.“ Wenn Sie eine Website, z. B. einen Blog, betreiben und Inhalte nicht zu oft aktualisieren, ist die richtige Antwort wahrscheinlich, nicht zu viel zu warten, da alles, was sich im Cache befindet, wahrscheinlich "neu" ist. ausreichend. Bei interaktiven Websites und Web-Apps empfiehlt es sich jedoch, etwas länger zu warten und veraltete Daten nicht zu stark aus dem Service Worker-Cache bereitzustellen.

Wenn Sie Messwerte im Feld erfassen, sehen Sie sich das 75. Perzentil der Werte für Time to First Byte (TTFB) und First Contentful Paint (FCP) an, um eine Vorstellung davon zu bekommen, wo bei Ihren Nutzern möglicherweise längere Wartezeiten für Navigationsanfragen liegen. Dies könnte Ihnen Aufschluss darüber geben, wo Sie die Grenze ziehen sollten.