Forcer un délai avant expiration du réseau

Il peut arriver que votre connexion réseau soit trop lente, ou qu'elle vous prétend que vous êtes connecté. Dans les situations où un service worker fait partie de l'ensemble, 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 fige (et les icônes de chargement tournent indéfiniment) jusqu'à ce qu'une page d'erreur s'affiche.

Quelle que soit la situation, il est préférable, dans certains cas, de revenir à la dernière réponse mise en cache pour un élément ou une page après un certain temps. Mais Workbox peut vous aider à résoudre un autre problème.

Utiliser networkTimeoutSeconds

Vous pouvez forcer le délai avant expiration des requêtes réseau lorsque vous utilisez 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 l'arrivée de la réponse du réseau avant d'abandonner et de renvoyer 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 indique à votre service worker d'abandonner toute requête de navigation réseau et d'utiliser la dernière version mise en cache au bout de trois secondes. Lorsqu'elle est utilisée avec des requêtes de navigation, elle garantit l'accès à la dernière réponse mise en cache de toute page précédemment consultée.

Cependant, que se passe-t-il si la page à laquelle vous accédez ne possède pas d'ancienne réponse dans le cache ? Dans de tels cas, vous pouvez établir une réponse de remplacement pour 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));

Cela fonctionne, car lorsque vous utilisez networkTimeoutSeconds dans une stratégie NetworkFirst, votre gestionnaire renvoie une réponse d'erreur si le délai a expiré et qu'il n'existe aucune 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 avant expiration 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 vous attendez trop longtemps, vous risquez de provoquer un rebond des utilisateurs dont la connexion est lente avant l'expiration du délai. Délai d'inactivité trop élevé : vous risquez de diffuser inutilement du contenu obsolète depuis le cache.

La bonne réponse est "cela dépend". Si vous gérez un site tel qu'un blog et que vous ne mettez pas à jour trop souvent son contenu, la bonne réponse est sans doute de ne pas attendre trop, car le contenu du cache est probablement assez "nouveau". Toutefois, pour les sites Web et les applications 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 à partir du 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 de l'endroit où les temps d'attente pour les requêtes de navigation peuvent se situer parmi votre base d'utilisateurs. Cela peut vous donner une idée de la ligne à franchir.