Los desarrolladores que usan service workers y la API de Cache Storage deben estar atentos a dos cambios pequeños que se lanzarán en Chrome 71. Ambos cambios permiten que la implementación de Chrome esté más alineada con las especificaciones y otros navegadores.
No se permite importScripts() asíncrono
importScripts()
le indica a la secuencia de comandos principal del trabajador de servicio que detenga su ejecución actual, descargue código adicional de una URL determinada y la ejecute hasta completarla en el alcance global actual. Una vez que se hace esto, la secuencia de comandos principal del trabajador de servicio reanuda la ejecución. importScripts()
resulta útil cuando quieres dividir la secuencia de comandos principal del trabajador de servicio en partes más pequeñas por motivos organizativos o incorporar código de terceros para agregar funcionalidad a tu trabajador de servicio.
Los navegadores intentan mitigar los posibles problemas de rendimiento de "descargar y ejecutar código síncrono" almacenando automáticamente en caché todo lo que se extrae a través de importScripts()
, lo que significa que, después de la descarga inicial, hay muy poca sobrecarga en la ejecución del código importado.
Sin embargo, para que eso funcione, el navegador debe saber que no habrá ningún código "sorpresa" importado al service worker después de la instalación inicial.
Según la especificación del servicio trabajador, llamar a importScripts()
solo debería funcionar durante la ejecución síncrona de la secuencia de comandos del servicio trabajador de nivel superior o, si es necesario, de forma asíncrona dentro del controlador install
.
Antes de Chrome 71, funcionaba llamar a importScripts()
de forma asíncrona fuera del controlador install
. A partir de Chrome 71, esas llamadas arrojan una excepción de tiempo de ejecución (a menos que la misma URL se haya importado anteriormente en un controlador install
), lo que coincide con el comportamiento en otros navegadores.
En lugar de un código como este:
// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
importScripts('my-fetch-logic.js');
event.respondWith(self.customFetchLogic(event));
});
El código de tu trabajador de servicio debería verse de la siguiente manera:
// Move the importScripts() to the top-level scope.
// (Alternatively, import the same URL in the install handler.)
importScripts('my-fetch-logic.js');
self.addEventListener('fetch', event => {
event.respondWith(self.customFetchLogic(event));
});
Se dará de baja la función cache.addAll() para las URLs repetidas
Si usas la API de Cache Storage junto con un trabajador de servicio, hay otro pequeño cambio en Chrome 71 para alinearse con la especificación relevante. Cuando la misma URL se pasa varias veces a una sola llamada a cache.addAll()
, la especificación indica que la promesa que muestra la llamada debe rechazarse.
Antes de Chrome 71, no se detectaba y se ignoraban las URLs duplicadas.
Este registro es un preludio de Chrome 72, en el que, en lugar de solo una advertencia registrada, las URLs duplicadas provocarán que cache.addAll()
las rechace. Si llamas a cache.addAll()
como parte de una cadena de promesas que se pasa a InstallEvent.waitUntil()
, como es práctica habitual, ese rechazo podría hacer que no se instale tu service worker.
A continuación, te mostramos cómo podrías tener problemas:
const urlsToCache = [
'/index.html',
'/main.css',
'/app.js',
'/index.html', // Oops! This is listed twice and should be removed.
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open('my-cache').then(cache => cache.addAll(urlsToCache))
);
});
Esta restricción solo se aplica a las URLs reales que se pasan a cache.addAll()
, y el almacenamiento en caché de lo que termina siendo dos respuestas equivalentes que tienen URLs diferentes, como '/'
y '/index.html'
, no activará un rechazo.
Prueba ampliamente tu implementación de servicio en primer plano
En este momento, los service workers están ampliamente implementados en todos los navegadores “siempre verdes” principales. Si pruebas tu app web progresiva con frecuencia en varios navegadores o si tienes una cantidad significativa de usuarios que no usan Chrome, es probable que ya hayas detectado la incoherencia y actualizado tu código. Sin embargo, en caso de que no hayas notado este comportamiento en otros navegadores, queríamos informarte sobre el cambio antes de cambiar el comportamiento de Chrome.