Se realizaron ajustes en importScripts() y cache.addAll() disponibles en Chrome 71

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 se alinee mejor con las especificaciones y otros navegadores.

Cómo inhabilitar importScripts() asíncronos

importScripts() le indica a tu secuencia de comandos principal del service worker que pause la ejecución actual, descargue código adicional de una URL determinada y la ejecute hasta el final 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 se importará ningún código "sorpresa" 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 de 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.

Una captura de pantalla del mensaje de advertencia en la consola de Chrome
A partir de Chrome 71, verás un mensaje de advertencia registrado en la consola.

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 regularidad 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 el código. Sin embargo, si no notaste este comportamiento en otros navegadores, queremos destacar el cambio antes de cambiar el comportamiento de Chrome.