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 pequeños cambios que se lanzarán en Chrome 71. Ambos cambios permiten que la implementación de Chrome se alinee mejor con specification y otros navegadores.

Cómo inhabilitar importScripts() asíncronos

importScripts() le indica a la secuencia de comandos principal del service worker que pause la ejecución actual, descargue código adicional de una URL determinada y ejecutarla hasta el final en el alcance global actual. Una vez hecho esto, la secuencia de comandos principal del service worker reanuda la ejecución. importScripts() es útil cuando quieres dividir la secuencia de comandos principal del service worker en partes más pequeñas por razones organizativas. extraer código de terceros para agregar funcionalidad al service worker.

Los navegadores intentan mitigar los posibles problemas de rendimiento de "descargar y ejecutar aplicaciones código" ya que almacena en caché automáticamente todo lo que se extrae a través de importScripts(), lo que significa que después de la descarga inicial, hay muy poca sobrecarga involucrada en la ejecución del código importado.

Sin embargo, para que eso funcione, el navegador debe saber que no habrá ninguna "sorpresa" código importado al service worker después de la ejecución instalación. Según la especificación de service worker, Se supone que llamar a importScripts() solo funciona durante la ejecución síncrona del servicio de o, si es necesario, de forma asíncrona dentro del controlador install.

Antes de Chrome 71, llamar a importScripts() de forma asíncrona fuera del controlador install hacía el trabajo. A partir de Chrome 71, esas llamadas arroja una excepción de tiempo de ejecución (a menos que la misma URL se haya importado antes en un controlador install), 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 del service worker 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));
});

Da de baja las URLs repetidas que se pasan a cache.addAll()

Si usas la API de Cache Storage junto con un service worker, hay otro pequeño cambio Chrome 71 de manera que se alinee con la especificación relevante. Cuando la misma URL es varias veces a una sola llamada cache.addAll(), el especificación indica que se debe rechazar la promesa que devuelve la llamada.

Antes de Chrome 71, esta acción no se detectaba, y las URL duplicadas se ignoraban de forma efectiva.

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

Este registro es un paso previo a Chrome 72, donde, en lugar de solo una advertencia, las URLs duplicadas puede dar como resultado un rechazo de cache.addAll(). Si llamas a cache.addAll() como parte de una cadena de promesas, haz lo siguiente: pasado a InstallEvent.waitUntil(), Como es habitual, ese rechazo podría hacer que no se instale tu service worker.

A continuación, te mostramos cómo podría 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 a almacenar en caché lo que termina siendo dos respuestas equivalentes con URLs diferentes, como '/' y '/index.html', no desencadena un rechazo.

Prueba ampliamente la implementación del service worker

Los service workers se implementan ampliamente en todas las principales plataformas “permanentes” navegadores en este punto. Si pruebas tu app web progresiva con regularidad en varios navegadores o si Si tienes una cantidad significativa de usuarios que no usan Chrome, es probable que ya hayas detectado la incoherencia y actualizó el código. Pero si aún no te has dado cuenta en otros navegadores, queríamos destacar el cambio antes de cambiar el comportamiento de Chrome.