Cómo forzar un tiempo de espera de la red

A veces, tienes una conexión de red, pero es demasiado lenta o la conexión te oculta de que estás en línea. En estas situaciones en las que un service worker se encuentra en la mezcla, una estrategia de almacenamiento en caché centrada en la red puede tardar demasiado en obtener una respuesta de la red, o la solicitud queda en espera (y los íconos giratorios de carga giran sin fin) hasta que recibas una página de error.

Cualquiera sea la situación, hay casos en los que sería preferible volver a la última respuesta almacenada en caché para un recurso o página después de un período determinado, otro problema con el que Workbox puede ayudar.

Usa networkTimeoutSeconds

Se puede forzar un tiempo de espera para las solicitudes de red cuando se usan las estrategias NetworkFirst o NetworkOnly. Estas estrategias ofrecen una opción networkTimeoutSeconds, que especifica la cantidad de segundos que el service worker debe esperar a que llegue la respuesta de red antes de recuperarse y mostrar la última versión almacenada en caché:

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

El código anterior indica a tu service worker que se resguarde de cualquier solicitud de navegación centrada en la red y use la última versión almacenada en caché después de tres segundos. Cuando se utiliza con solicitudes de navegación, esto garantiza el acceso a la última respuesta almacenada en caché de cualquier página visitada anteriormente.

Sin embargo, ¿qué sucede si la página a la que estás accediendo no tiene una respuesta más antigua en la memoria caché? En casos como ese, puedes establecer una respuesta de resguardo a una página HTML genérica sin conexión:

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

Esto funciona porque, cuando usas networkTimeoutSeconds en una estrategia NetworkFirst, el controlador mostrará una respuesta de error si se agota el tiempo de espera y no hay una coincidencia de caché para la URL. Si eso sucede, el complemento handlerDidError de Workbox puede proporcionar una respuesta genérica como resguardo.

¿Cuánto es demasiado tiempo para esperar?

Cuando fuerzas un tiempo de espera para las solicitudes (especialmente las solicitudes de navegación), lo mejor es encontrar el equilibrio adecuado entre no dejar que el usuario espere demasiado y no agotar el tiempo de espera demasiado rápido. Espera demasiado y podrías correr el riesgo de que los usuarios con conexiones lentas reboten antes de que se agote el tiempo de espera. Si el tiempo de espera es demasiado rápido, es posible que entregues contenido inactivo de la caché de manera innecesaria.

La respuesta correcta es "depende". Si tienes un sitio, como un blog, y no actualizas el contenido con demasiada frecuencia, la respuesta correcta probablemente sea errar de no esperar demasiado tiempo, ya que lo que haya en la caché probablemente sea “actualizado”. lo suficiente. Sin embargo, en el caso de apps y sitios web más interactivos, es mejor esperar un poco más y evitar entregar datos inactivos desde la caché del service worker con demasiada anticipación.

Si registras métricas en el campo, consulta las puntuaciones del percentil 75 de Tiempo hasta el primer byte (TTFB) y Primer procesamiento de imagen con contenido (FCP) para tener una idea de en qué parte de tu base de usuarios podrían encontrarse los tiempos de espera más largos para las solicitudes de navegación. Eso puede darte una idea de dónde trazar el límite.