Een netwerktime-out forceren

Er zijn momenten waarop u een netwerkverbinding heeft, maar die verbinding is te traag of uw verbinding liegt tegen u dat u online bent . In dergelijke situaties waarin een servicemedewerker in de mix zit, kan het te lang duren voordat een netwerk-eerste caching-strategie een reactie van het netwerk krijgt, anders blijft het verzoek hangen (en blijven de laadspinners eindeloos draaien) totdat je een foutpagina krijgt.

Hoe de situatie ook is, er zijn gevallen waarin het na een bepaalde tijdsperiode de voorkeur verdient om terug te gaan naar het laatste in de cache opgeslagen antwoord voor een item of pagina – nog een probleem waarmee Workbox kan helpen.

networkTimeoutSeconds gebruiken

Het forceren van een time-out voor netwerkaanvragen kan worden gedaan bij gebruik van de NetworkFirst of NetworkOnly -strategieën. Deze strategieën bieden een optie networkTimeoutSeconds , die het aantal seconden specificeert dat de servicemedewerker moet wachten tot het netwerkantwoord arriveert voordat het wordt uitgeschakeld en de laatst in de cache opgeslagen versie ervan retourneert:

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

De bovenstaande code instrueert uw servicemedewerker om elk netwerk-eerste navigatieverzoek uit te schakelen en na drie seconden de laatst in de cache opgeslagen versie te gebruiken. Bij gebruik met navigatieverzoeken garandeert dit toegang tot het laatste in de cache opgeslagen antwoord van een eerder bezochte pagina.

Maar wat moet ik doen als de pagina die u bezoekt geen ouder antwoord in de cache heeft? In dergelijke gevallen kunt u een terugvalreactie instellen op een generieke offline HTML-pagina:

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

Dit werkt omdat wanneer u networkTimeoutSeconds gebruikt in een NetworkFirst -strategie, uw handler een foutreactie retourneert als de time-out optreedt en er geen cacheovereenkomst is voor de URL. Als dat gebeurt, kan de handlerDidError Workbox-plug-in een generiek antwoord bieden als terugval.

Hoe lang is te lang wachten?

Wanneer u een time-out voor verzoeken forceert, vooral bij navigatieverzoeken, wilt u de juiste balans vinden tussen het niet te lang laten wachten van de gebruiker en het niet te snel time-outen. Als u te lang wacht, loopt u het risico dat gebruikers met langzame verbindingen stuiteren voordat de time-out optreedt. Als de time-out te snel is, kan het zijn dat u onnodig verouderde inhoud uit de cache aanbiedt.

Het juiste antwoord is "het hangt ervan af". Als u een site zoals een blog beheert en de inhoud niet te vaak bijwerkt, is het juiste antwoord waarschijnlijk om niet te lang te wachten, aangezien alles wat zich in de cache bevindt waarschijnlijk "vers" genoeg is. Voor meer interactieve websites en web-apps kan het echter het beste zijn om wat langer te wachten en te voorkomen dat verouderde gegevens uit de cache van de servicemedewerkers te gretig worden aangeboden.

Als u statistieken in het veld registreert, kijk dan naar het 75e percentiel van de Time to First Byte (TTFB) en First Contentful Paint (FCP) -scores om een ​​idee te krijgen van waar langere wachttijden voor navigatieverzoeken zich in uw gebruikersbestand kunnen bevinden. Dat kan u inzicht geven in waar u de grens moet trekken.