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, comopath/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 secuenciapath/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.