Forzare un timeout di rete

A volte hai una connessione di rete che è troppo lenta o la connessione ti dice che sei online. In situazioni di questo tipo, quando si trova un service worker, una strategia di memorizzazione nella cache basata sulla rete potrebbe impiegare troppo tempo per ottenere una risposta dalla rete o la richiesta si blocca e le rotelline di caricamento ruotano all'infinito fino a quando non viene visualizzata una pagina di errore.

Qualunque sia la situazione, ci sono casi in cui sarebbe preferibile tornare all'ultima risposta memorizzata nella cache per una risorsa o una pagina dopo un certo periodo di tempo, un altro problema per cui Workbox può essere d'aiuto.

In uso: networkTimeoutSeconds

Puoi forzare il timeout per le richieste di rete quando utilizzi le strategie NetworkFirst o NetworkOnly. Queste strategie offrono un'opzione networkTimeoutSeconds, che specifica per quanti secondi il service worker deve attendere l'arrivo della risposta di rete prima che venga salvata e restituisce l'ultima versione memorizzata nella 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);

Il codice riportato sopra indica al service worker di abbandonare qualsiasi richiesta di navigazione network-first e di utilizzare l'ultima versione memorizzata nella cache dopo tre secondi. Se utilizzato con le richieste di navigazione, garantisce l'accesso all'ultima risposta memorizzata nella cache di qualsiasi pagina visitata in precedenza.

Tuttavia, cosa succede se la pagina a cui stai accedendo non contiene una risposta meno recente nella cache? In questi casi, puoi stabilire una risposta di riserva a una pagina HTML offline generica:

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

Questo funziona perché quando utilizzi networkTimeoutSeconds in una strategia NetworkFirst, il gestore restituisce una risposta di errore se si verifica il timeout e non esiste una corrispondenza della cache per l'URL. In questo caso, il plug-in handlerDidError Workbox può fornire una risposta generica come alternativa.

Quanto tempo è necessario attendere?

Quando forzi un timeout per le richieste, in particolare per le richieste di navigazione, vuoi trovare il giusto equilibrio tra non lasciare che l'utente attenda troppo a lungo e non scadere troppo rapidamente. Attendi troppo a lungo e potresti rischiare che gli utenti con connessioni lente rimbalzano prima del timeout. Timeout troppo veloce e potresti finire per pubblicare inutilmente contenuti obsoleti dalla cache.

La risposta giusta è "Dipende". Se gestisci un sito come un blog e non aggiorni i contenuti troppo spesso, la risposta giusta probabilmente è quella di non aspettare troppo perché tutto ciò che si trova nella cache è probabilmente "nuovo" abbastanza. Tuttavia, per i siti web e le app web più interattivi, potrebbe essere meglio attendere un po' più a lungo ed evitare di inviare dati inattivi dalla cache del service worker.

Se stai registrando metriche sul campo, osserva il 75° percentile dei punteggi TTFB (Time to First Byte) e First Contentful Paint (FCP) per avere un'idea di quali potrebbero essere i tempi di attesa più lunghi per le richieste di navigazione nella tua base utenti. Ciò potrebbe darti informazioni su dove tracciare la linea.