Se usó la API de Cloud Translation para traducir esta página.

Trabajadores de servicio más recientes, de forma predeterminada

Jeff Posnick

Resumen

A partir de Chrome 68, las solicitudes HTTP que buscan actualizaciones de la secuencia de comandos del service worker no pueden proporcionar más tiempo la caché HTTP de forma predeterminada. Esto soluciona un problema común de los desarrolladores: en la que configurar un encabezado Cache-Control involuntario en la secuencia de comandos del service worker a las actualizaciones retrasadas.

Si ya inhabilitaste el almacenamiento en caché HTTP para la secuencia de comandos /service-worker.js al publicarla con Cache-Control: max-age=0, no deberías ver ningún cambio debido al nuevo comportamiento el comportamiento de los usuarios.

Además, a partir de Chrome 78, la comparación byte por byte que se aplican a las secuencias de comandos cargadas en un service worker importScripts() Todo cambio que se realice en una secuencia de comandos importada activará el flujo de actualización de service worker del mismo modo que lo haría un cambio en el service worker de nivel superior.

Información general

Cada vez que navegues a una nueva página que esté dentro del permiso de un service worker, llama explícitamente a registration.update() desde JavaScript, o cuando un service worker se "activa" a través de un evento push o sync, el navegador solicitará, al mismo tiempo, el recurso JavaScript que se pasó originalmente al navigator.serviceWorker.register() para buscar actualizaciones de la secuencia de comandos del service worker.

A los efectos de este artículo, supongamos que su URL es /service-worker.js y que contiene una única llamada a importScripts(), que carga código adicional que se ejecuta dentro del service worker:

// Inside our /service-worker.js file:
importScripts('path/to/import.js');

// Other top-level code goes here.

¿Cuáles son los cambios?

Antes de Chrome 68, la solicitud de actualización de /service-worker.js se hacía a través de la caché HTTP. (como la mayoría de las recuperaciones). Esto significaba que, si la secuencia de comandos se enviaba originalmente con Cache-Control: max-age=600, las actualizaciones de los próximos 600 segundos (10 minutos) no iban a la red, por lo que el Es posible que el usuario no reciba la versión más actualizada del service worker. Sin embargo, si max-age era superior a 86,400 (24 horas), se tratará como si fuera 86,400 para evitar que los usuarios queden atascados. con una versión particular para siempre.

A partir de 68, se ignorará la caché HTTP al solicitar actualizaciones al service worker secuencia de comandos, por lo que las aplicaciones web existentes pueden experimentar un aumento en la frecuencia de las solicitudes de sus de la secuencia de comandos del service worker. Las solicitudes de importScripts se seguirán enviando a través de la caché HTTP. Pero este es solo la predeterminada; hay una nueva opción de registro disponible, updateViaCache, que permite controlar este comportamiento.

updateViaCache

Los desarrolladores ahora pueden pasar una opción nueva cuando llaman a navigator.serviceWorker.register(): el parámetro updateViaCache. Toma uno de tres valores: 'imports', 'all' o 'none'.

Los valores determinan si la caché HTTP estándar del navegador y cómo hacerlo entra en juego cuando se realiza la solicitud HTTP para buscar recursos actualizados del service worker.

Cuando se establece en 'imports', no se consultará la caché HTTP al buscar actualizaciones en la Secuencia de comandos /service-worker.js, pero se consultará cuando se recuperen las secuencias de comandos importadas (path/to/import.js, en nuestro ejemplo). Este es el valor predeterminado, y coincide con el comportamiento que comienza en Chrome 68.
Cuando se establece en 'all', se consultará la caché HTTP al realizar solicitudes para el secuencia de comandos /service-worker.js de nivel superior, así como cualquier secuencia de comandos importada dentro del servicio trabajadora, como path/to/import.js. Esta opción corresponde al comportamiento anterior en Chrome, anteriores a Chrome 68.
Cuando se establece en 'none', no se consultará la caché HTTP al realizar solicitudes para el /service-worker.js de nivel superior o para cualquier secuencia de comandos importada, como la secuencia path/to/import.js

Por ejemplo, el siguiente código registrará un service worker y garantizará que la caché HTTP nunca se consultó cuando se buscan actualizaciones de la secuencia de comandos de /service-worker.js o Secuencias de comandos a las que se hace referencia mediante importScripts() dentro de /service-worker.js:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js', {
    updateViaCache: 'none',
    // Optionally, set 'scope' here, if needed.
  });
}

Busca actualizaciones de las secuencias de comandos importadas

Antes de Chrome 78, cualquier secuencia de comandos del service worker se cargaba mediante importScripts() se recuperaría una sola vez (comprobando primero en la caché HTTP o mediante según la configuración de updateViaCache). Luego de esa inicial recuperarse, se almacenará de forma interna en el navegador y nunca se volverá a recuperar.

La única manera de hacer que un service worker ya instalado incorpore los cambios en una secuencia de comandos importada era cambiar la URL de la secuencia de comandos, por lo general, agregando semver value (p.ej., importScripts('https://example.com/v1.1.0/index.js')) o incluyendo un hash de el contenido (p.ej., importScripts('https://example.com/index.abcd1234.js')). R un efecto secundario de cambiar la URL importada es que el service worker de nivel superior de tu secuencia de comandos cambia, lo que, a su vez, activa flujo de actualización de service worker.

A partir de Chrome 78, cada vez que se realiza una verificación de actualización de un service worker, se realizarán verificaciones al mismo tiempo para determinar si o no el contenido de ninguna secuencia de comandos importada haya cambiado. Según el Se usaron Cache-Control encabezados. Es posible que estas comprobaciones de secuencias de comandos importadas completen estas verificaciones de la secuencia de comandos importada la caché HTTP si updateViaCache está configurado como 'all' o 'imports' (que es el valor predeterminado) o que las comprobaciones vayan directamente en la red si updateViaCache se establece en 'none'.

Si una verificación de actualización de una secuencia de comandos importada genera una diferencia byte por byte en comparación con lo que antes almacenó el service worker, activar todo el flujo de actualización del service worker, incluso si el servicio trabajador a la vez sigue siendo el mismo.

El comportamiento de Chrome 78 coincide con lo que Firefox implemented hace varios años, en Firefox 56. Safari ya implementa este comportamiento como en la nube.

¿Qué deben hacer los desarrolladores?

Si inhabilitaste el almacenamiento en caché HTTP para tu secuencia de comandos /service-worker.js de forma eficaz al entregarla con Cache-Control: max-age=0 (o un valor similar), no deberías ver ningún cambio debido a el nuevo comportamiento predeterminado.

Si entregas tu secuencia de comandos de /service-worker.js con el almacenamiento en caché HTTP habilitado, ya sea de forma intencional o porque es solo el predeterminado de tu entorno de hosting Es posible que empieces a ver un aumento de solicitudes HTTP adicionales para /service-worker.js realizadas contra estas son solicitudes que solían satisfacer la caché HTTP. Si deseas Sigue permitiendo que el valor del encabezado Cache-Control influya en la actualidad de tu /service-worker.js, deberás comenzar a configurar updateViaCache: 'all' de forma explícita cuando para registrar tu service worker.

Dado que puede haber una gran cantidad de usuarios en versiones anteriores del navegador, sigue siendo una buena idea continúa estableciendo el encabezado HTTP Cache-Control: max-age=0 en las secuencias de comandos del service worker, aunque es posible que los navegadores más nuevos los ignoren.

Los desarrolladores pueden aprovechar esta oportunidad para decidir si desean habilitar de forma explícita sus productos importados secuencias de comandos del almacenamiento en caché HTTP ahora y agregan updateViaCache: 'none' a su service worker el registro si corresponde.

Entrega secuencias de comandos importadas

A partir de Chrome 78, es posible que los desarrolladores vean más solicitudes HTTP entrantes para recursos cargados a través de importScripts(), ya que ahora se verificarán actualizaciones.

Si quieres evitar este tráfico HTTP adicional, configura Cache-Control cuando se publiquen secuencias de comandos que incluyan semver o hashes en sus URLs y se basan en el comportamiento predeterminado de updateViaCache de 'imports'.

De manera alternativa, si deseas que se revisen tus secuencias de comandos importadas para comprobar la frecuencia actualizaciones y, luego, asegúrate de publicarlas con Cache-Control: max-age=0 o que uses updateViaCache: 'none'.

Lecturas adicionales

"El ciclo de vida del service worker" y “Prácticas recomendadas de almacenamiento en caché y problemas de la edad máxima", ambas por Jake Archibald, se recomiendan para todos los desarrolladores que implementan cualquier cosa en la Web.