Los service workers son una herramienta potente que permite que los sitios web funcionen sin conexión y
creen reglas especializadas de almacenamiento en caché para ellos mismos. El controlador fetch del service worker ve todas las solicitudes de una página que controla y puede decidir si desea entregar una respuesta desde la caché del service worker o incluso reescribir la URL para obtener una respuesta completamente diferente; por ejemplo, según las preferencias del usuario
local.
Sin embargo, puede haber un costo de rendimiento para los service workers cuando una página se carga por primera vez en un tiempo y el service worker que la controla no se está ejecutando en ese momento. Dado que todas las recuperaciones deben realizarse a través del service worker, el navegador debe esperar a que este se inicie y ejecute para saber qué contenido cargar. Este costo de inicio puede ser pequeño, pero significativo, para los desarrolladores que usan service workers a fin de mejorar el rendimiento a través de estrategias de almacenamiento en caché.
La carga previa de Navigation es un enfoque para resolver el problema, que permite que las solicitudes de navegación se realicen por la red en paralelo con el inicio del service worker, pero se limita a las solicitudes de navegación iniciales y también incluye el service worker en la ruta crítica. Desde el lanzamiento de la precarga de navegación, se realizaron varios esfuerzos para desarrollar una solución más general al espacio del problema, incluidas formas en que algunas solicitudes no se bloqueen durante el inicio del service worker.
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 hacia 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 de acceso para que siempre se entreguen desde la red, no desde el service worker. Cuando luego se carga una URL controlada, el navegador puede comenzar a recuperar recursos de esas rutas antes de que el service worker haya terminado de iniciarse. De esta forma, se quita el service worker de las rutas que no lo necesitan.
Para usar la API, el service worker 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 mediante la API de URL Pattern para que coincidan las rutas de los recursos. La propiedad puede tomar una instancia deURLPatterno el objeto sin formato equivalente que es compatible con el paso al constructorURLPattern(por ejemplo,new URLPattern({pathname: '*.jpg'})o solo{pathname: '*.jpg'}).La flexibilidad de los patrones de URL significa que la regla puede hacer coincidir algo tan simple como cualquier recurso en una ruta de acceso, hasta condiciones muy específicas y detalladas. Por lo general, los usuarios de las bibliotecas de enrutamiento populares deberían resultar familiares.
source: Especifica cómo se cargarán los recursos que coincidan concondition. Actualmente, solo se admite el valor'network'(se omite el service worker para cargar el recurso a través de la red directamente), pero se planea expandirlo a otros valores en el futuro.
Casos de uso
Como se explicó anteriormente, la versión inicial de la API es, básicamente, una solución de emergencia del control de service worker para algunas rutas. El lugar en que tenga sentido utilizarlo dependerá de cómo utilices tu service worker y cómo los usuarios naveguen por tu sitio.
Un ejemplo podría ser si tu sitio usa una estrategia que prioriza la caché (recurrir a la red), pero hay contenido que se visita con tanta frecuencia que no tiene valor en la caché (como contenido archivado o feeds RSS). La restricción de estas rutas de acceso para que se recuperen desde la red solo se puede configurar en el service worker, pero este aún debe iniciarse y ejecutarse para decidir cómo controlar esas solicitudes.
Por el contrario, la API de enrutamiento estático omite el service worker 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, la idea es que esta configuración sea más flexible y admita más situaciones, como la carrera declarativa de una recuperación de la red y el inicio del service worker. Consulta la exploración en la explicación 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 detrás de una prueba de origen, que permite a los desarrolladores probar la API en su sitio con usuarios reales para medir el efecto. Consulta “Cómo comenzar 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 mediante la ejecución de 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 se está dando forma. Si te parece útil, pruébala durante la prueba de origen y envíanos comentarios sobre la API, la implementación y la funcionalidad disponible.