Prueba de origen de la API de enrutamiento estático de Service Worker

Brendan Kenny
Brendan Kenny

Los Service Workers son una herramienta potente para permitir que los sitios web funcionen sin conexión y creen reglas de almacenamiento en caché especializadas. Un controlador fetch de service worker ve cada solicitud de una página que controla y puede decidir si quiere entregarle una respuesta desde la caché del service worker o incluso reescribir la URL para recuperar una respuesta completamente diferente, por ejemplo, según las preferencias locales del usuario.

Sin embargo, puede haber un costo de rendimiento para los service workers cuando se carga una página por primera vez en un tiempo y el service worker de control no se está ejecutando. Dado que todas las recuperaciones deben realizarse a través del service worker, el navegador debe esperar a que se inicie y ejecute para saber qué contenido cargar. Este costo de inicio puede ser pequeño, pero significativo, para los desarrolladores que usan trabajadores del servicio para mejorar el rendimiento a través de estrategias de almacenamiento en caché.

La carga previa de navegación es un enfoque para resolver el problema, ya que permite que se realicen solicitudes de navegación a través de la red en paralelo con el inicio del servicio de trabajo, pero se limita a las solicitudes de navegación iniciales y aún incluye el servicio de trabajo en la ruta crítica. Desde que se lanzó la carga previa de navegación, se realizaron varios esfuerzos para desarrollar una solución más general al espacio del problema, incluidas formas de evitar que algunas solicitudes no se bloqueen en el inicio del trabajador del servicio.

La API de enrutamiento estático de Service Worker

A partir de Chrome 116, la API experimental de enrutamiento estático de Service Worker está disponible para probar el primer paso de esa solución. Cuando se instala un service worker, puede usar la API de enrutamiento estático de Service Worker para indicar de forma declarativa cómo se deben recuperar ciertas rutas de recursos.

En la versión inicial de la API, se pueden declarar las rutas para que siempre se entreguen desde la red, no desde el service worker. Cuando se carga una URL controlada más adelante, el navegador puede comenzar a recuperar recursos de esas rutas de acceso antes de que se haya terminado de iniciar el service worker. Esto quita el trabajador de servicio de las rutas que sabes que no lo necesitan.

Para usar la API, el trabajador de servicio llama a event.registerRouter en el evento install con un conjunto de reglas:

self.addEventListener('install', event => {
  if (event.registerRouter) {
    // Go straight to the network and bypass invoking "fetch" handlers for all
    // same-origin URLs that start with '/form/'.
    event.registerRouter([{
      condition: {
        urlPattern: {pathname: '/form/*'},
      },
      source: 'network',
    }]);
  }
});

Por lo general, cada regla tiene dos propiedades:

  • condition: Especifica cuándo se aplica la regla con la API de URL Pattern para hacer coincidir las rutas de acceso de los recursos. La propiedad puede tomar una instancia de URLPattern o el objeto simple equivalente que es compatible con pasarse al constructor URLPattern (por ejemplo, new URLPattern({pathname: '*.jpg'}) o solo {pathname: '*.jpg'}).

    La flexibilidad de los patrones de URL significa que la regla puede coincidir con algo tan simple como cualquier recurso de una ruta, hasta condiciones muy específicas y detalladas. Por lo general, los patrones deberían ser familiares para los usuarios de bibliotecas de enrutamiento populares.

  • source: Especifica cómo se cargarán los recursos que coincidan con condition. Actualmente, solo se admite el valor 'network' (se omite el trabajador de servicio para cargar el recurso directamente a través de la red), pero el plan es expandir esto a otros valores en el futuro.

Casos de uso

Como se explicó, la versión inicial de la API es, en esencia, una salida de emergencia del control del trabajador de servicio para algunas rutas. El uso de esta función dependerá de cómo uses el trabajador de servicio y de cómo los usuarios naveguen por tu sitio.

Un ejemplo podría ser si tu sitio usa una estrategia de prioridad en la caché (recurre a la red), pero hay contenido que se visita tan poco que no tiene mucho valor que llegue a la caché (como el contenido archivado o los feeds RSS). La restricción de estas rutas para que se recuperen de la red solo se puede configurar en el trabajador de servicio, pero este aún debe iniciarse y ejecutarse para decidir cómo controlar esas solicitudes.

En cambio, la API de enrutamiento estático pasa por alto el servicio trabajador por completo con algunas líneas declarativas:

self.addEventListener('install', event => {
  if (event.registerRouter) {
    event.registerRouter([{
      condition: {
        urlPattern: {pathname: '/feeds/*.xml'},
      },
      source: 'network',
    }, {
      condition: {
        urlPattern: {pathname: '/archives/*'},
      },
      source: 'network',
    }]);
  }
});

A medida que evoluciona la API de enrutamiento estático de Service Worker, el plan es que esta configuración sea más flexible y admita más situaciones, como competir de forma declarativa por una recuperación de red y el inicio de un trabajador de servicio. Consulta la exploración del explicador de especificaciones de una posible "forma final" de la API para obtener más detalles.

Prueba la API de enrutamiento estático de Service Worker

La API de enrutamiento estático de Service Worker está disponible en Chrome a partir de la versión 116 con una prueba de origen, que permite a los desarrolladores probar la API en su sitio con usuarios reales para medir el efecto. Consulta "Comienza a usar las pruebas de origen" para obtener información general sobre las pruebas de origen.

Para las pruebas locales, la API de enrutamiento estático de Service Worker se puede habilitar con una marca en chrome://flags/#service-worker-static-router o ejecutando Chrome desde el comando como con --enable-features=ServiceWorkerStaticRouter.

Comentarios y direcciones futuras

La API de enrutamiento estático de Service Worker se está desarrollando de forma activa y aún está en desarrollo. Si crees que podría ser útil para ti, pruébala a través de la prueba de origen y envía comentarios sobre la API, la implementación y la funcionalidad disponible.