service-worker - with - service worker implementation

Frecuencia de actualización de JavaScript del trabajador de servicio(¿cada 24 horas?) (1)

Después de eso, se descarga cada 24 horas más o menos. Puede descargarse con más frecuencia, pero debe descargarse cada 24 h para evitar que los scripts incorrectos sean molestos durante demasiado tiempo.

¿Es lo mismo cierto para Firefox y Chrome? ¿O la actualización a JavaScript del trabajador de servicio solo ocurre cuando el usuario navega al sitio?

Nota: a partir de Firefox 57 y Chrome 68 , así como las versiones de Safari y Edge que admiten los trabajadores de servicios, el comportamiento predeterminado ha cambiado para tener en cuenta la especificación actualizada de los trabajadores de servicios . En esos navegadores, las directivas de caché HTTP, de forma predeterminada, se ignorarán cuando se verifiquen las actualizaciones del script del trabajador del servicio. La descripción a continuación todavía se aplica a versiones anteriores de Chrome y Firefox.

Cada vez que navega a una nueva página que está bajo el alcance de un trabajador de servicio, Chrome realizará una solicitud HTTP estándar para el recurso de JavaScript que se pasó a la llamada navigator.serviceWorker.register() . Supongamos que se llama service-worker.js . Esta solicitud solo se realiza junto con una navegación o cuando un trabajador de servicio se despierta mediante, por ejemplo, un evento push . No hay un proceso en segundo plano que vuelva a buscar cada script de trabajador de servicio cada 24 horas, ni nada automatizado como ese.

Esta solicitud HTTP obedecerá las directivas estándar de caché HTTP , con una excepción (que se trata en el siguiente párrafo). Por ejemplo, si su servidor establece los encabezados de respuesta HTTP apropiados que indican que la respuesta en caché se debe usar durante 1 hora, entonces, dentro de la siguiente hora, la solicitud del navegador para service-worker.js será atendida por la memoria caché del navegador. Tenga en cuenta que no estamos hablando de la API de almacenamiento en caché , que no es relevante en esta situación, sino del almacenamiento en caché HTTP estándar del navegador .

La única excepción a las reglas estándar de almacenamiento en caché de HTTP, y aquí es donde entran las 24 horas, es que los navegadores siempre irán a la red si la antigüedad de la entrada de service-worker.js en el caché HTTP es superior a 24 horas. Entonces, funcionalmente, no hay diferencia en el uso de una max-age de 1 día o 1 semana o 1 año: todos serán tratados como si la max-age fuera 1 día.

Los proveedores de navegadores quieren asegurarse de que los desarrolladores no desplieguen accidentalmente un service-worker.js "roto" o con errores que se service-worker.js con una max-age de 1 año, dejando a los usuarios lo que podría ser una experiencia web persistente y rota para un largo periodo de tiempo. (No puede confiar en que sus usuarios sepan borrar los datos de su sitio o volver a cargar el sitio).

Algunos desarrolladores prefieren servir explícitamente a su service-worker.js con encabezados de respuesta que hacen que se deshabilite todo el almacenamiento en caché de HTTP, lo que significa que se realiza una solicitud de red para service-worker.js para cada navegación. Otro enfoque podría ser utilizar una max-age muy, muy corta max-age digamos un minuto, para proporcionar cierto grado de limitación en caso de que haya un gran número de navegaciones rápidas de un solo usuario. Si realmente desea minimizar las solicitudes y está seguro de que no actualizará su service-worker.js corto plazo, puede establecer una max-age de 24 horas, pero le recomiendo que elija algo más breve fuera de la posibilidad de que inesperadamente necesite volver a implementar.