Forcer un délai avant expiration du réseau

Il peut arriver que vous disposiez d'une connexion réseau, mais qu'elle soit trop lente ou que votre connexion ne vous indique pas que vous êtes en ligne. Dans les situations où un service worker fait partie de la combinaison, une stratégie de mise en cache axée sur le réseau peut mettre trop de temps à obtenir une réponse du réseau, ou la requête se bloque (et les icônes de chargement tournent à l'infini) jusqu'à ce qu'une page d'erreur s'affiche.

Quelle que soit la situation, il peut parfois s'avérer préférable de revenir à la dernière réponse mise en cache pour un élément ou une page après une certaine période. Autre problème que Workbox peut résoudre.

networkTimeoutSeconds utilisé(s)

Vous pouvez forcer un délai avant expiration pour les requêtes réseau en utilisant les stratégies NetworkFirst ou NetworkOnly. Ces stratégies proposent une option networkTimeoutSeconds, qui spécifie le nombre de secondes pendant lesquelles le service worker doit attendre la réponse du réseau avant de disparaître et renvoie la dernière version mise en cache:

// 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);

Le code ci-dessus demande au service worker d'annuler toute requête de navigation réseau et d'utiliser la dernière version mise en cache au bout de trois secondes. Utilisé avec des requêtes de navigation, il garantit l'accès à la dernière réponse mise en cache de toute page précédemment consultée.

Que se passe-t-il si la page à laquelle vous accédez ne dispose pas d'une ancienne réponse dans le cache ? Dans ce cas, vous pouvez établir une réponse de remplacement à une page HTML hors connexion générique:

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));

En effet, lorsque vous utilisez networkTimeoutSeconds dans une stratégie NetworkFirst, votre gestionnaire renvoie une réponse d'erreur si le délai avant expiration se produit et qu'il n'y a pas de correspondance de cache pour l'URL. Dans ce cas, le plug-in Workbox handlerDidError peut fournir une réponse générique en remplacement.

Combien de temps faut-il attendre ?

Lorsque vous forcez un délai d'inactivité pour des requêtes (en particulier pour les requêtes de navigation), vous devez trouver le bon équilibre entre ne pas laisser l'utilisateur attendre trop longtemps et ne pas expirer trop rapidement. Si le délai d'attente est trop long, vous risquez de faire rebondir l'accès des utilisateurs dont la connexion est lente avant l'expiration du délai. Délai avant expiration trop rapide : vous risquez de diffuser inutilement du contenu non actualisé à partir du cache.

La bonne réponse est "Cela dépend". Si vous gérez un site tel qu'un blog et que vous n'actualisez pas le contenu trop souvent, la bonne solution est sans doute de ne pas attendre trop, car tout ce qui se trouve dans le cache est probablement "fraîcheur". cela suffit. Toutefois, pour les sites et les applications Web plus interactifs, il peut être préférable d'attendre un peu plus longtemps et d'éviter de diffuser trop hâtivement des données obsolètes depuis le cache du service worker.

Si vous enregistrez des métriques sur le terrain, examinez le 75e centile des scores Time to First Byte (TTFB) et First Contentful Paint (FCP) pour vous faire une idée des temps d'attente plus longs pour les requêtes de navigation dans votre base d'utilisateurs. Cela peut vous donner un aperçu de la ligne à suivre.