Service workers

Los usuarios esperan que las apps se inicien de manera confiable con conexiones de red lentas o inestables. incluso sin conexión. Esperan el contenido con el que interactuaron más recientemente. como itinerarios o pistas multimedia, para que estén disponibles y se puedan usar. Cuando no es posible realizar una solicitud, ellos esperan que la app se lo indique en lugar de falla o falla silenciosamente. Y quieren que todo esto suceda rápidamente. Como puedes ver en Los milisegundos valen millones, incluso una mejora de 0.1 segundos en los tiempos de carga puede mejorar la conversión en hasta un 10%. Los service workers son la herramienta que permite que tu app web progresiva (AWP) esté a la altura tus usuarios con sus expectativas.

Un service worker como proxy de middleware que se ejecuta en el dispositivo entre tu AWP y servidores, lo que incluye tus propios servidores y servidores multidominio.
Un service worker actúa como middleware AWP y los servidores con los que interactúa.

Cuando una app solicita un recurso cubierto por el alcance del service worker, el service worker intercepta la solicitud y actúa como un proxy de red, incluso si usuario está sin conexión. Luego, puede decidir si debe entregar el recurso desde la con la API de Cache Storage, entregarla desde la red como si no existiera un service worker activo o crearlo a partir de un algoritmo local. Esto te permite brindan una experiencia de alta calidad, como la de una app de plataforma, incluso cuando tus no tiene conexión.

Registra un service worker

Antes de que un service worker tome el control de tu página, debe estar registrada para tu AWP. Esto significa que, la primera vez que un usuario abre tu AWP, toda la red van directamente a tu servidor porque el service worker no tiene el control de sus páginas.

Después de comprobar si el navegador admite la API de Service Worker, tu AWP puede registrar un service worker. Cuando se carga, el service worker se configura entre tu AWP y la red, interceptar solicitudes y entregar respuestas correspondientes.

if ('serviceWorker' in navigator) {
   navigator.serviceWorker.register("/serviceworker.js");
}
Intenta registrar un service worker para ver qué se realiza en las herramientas para desarrolladores de tu navegador.

Verifica si se registró un service worker

Para verificar si un service worker está registrado, usa las herramientas para desarrolladores de tu navegador favorito.

En los navegadores basados en Chromium y Firefox (Microsoft Edge, Google Chrome o Samsung Internet):

  1. Abre las herramientas para desarrolladores y, luego, haz clic en la pestaña Aplicación.
  2. En el panel izquierdo, selecciona Service Workers.
  3. Comprueba que la URL de la secuencia de comandos del service worker aparezca con el estado "Activada". (para obtener más información, consulta Ciclo de vida). En Firefox, el estado puede ser "Running" o "Detenido".

En Safari:

  1. Haz clic en Develop > Service Workers:
  2. Busca en este menú una entrada con el origen actual. Hacer clic en esa entrada abre un inspector sobre el contexto del service worker.
Herramientas para desarrolladores de service workers en Chrome, Firefox y Safari.
Herramientas para desarrolladores de service workers en Chrome, Firefox y Safari.

Alcance

La carpeta en la que se encuentra tu service worker determina su alcance. Un service worker que se encuentra en example.com/my-pwa/sw.js puede controlar cualquier navegación en la ruta my-pwa, como example.com/my-pwa/demos/. Los service workers pueden solo controlan elementos (páginas, trabajadores, "clientes") en conjunto que estén dentro de su alcance. Este alcance se aplica a las pestañas del navegador y las ventanas de la AWP.

Solo se permite un service worker por permiso. Cuando un service worker está activo y en ejecución, por lo general, solo hay una instancia disponible, sin importar cuántos clientes (ventanas de AWP o pestañas del navegador) están en la memoria.

Safari tiene una administración de permisos más compleja, conocida como particiones, que afecta la forma funcionan con iframes multidominio. Para obtener más información sobre WebKit's consulta su entrada de blog.

Lifecycle

Los service workers tienen un ciclo de vida que determina cómo se instalan, por separado de la instalación de tu AWP.

El ciclo de vida del service worker comienza con el registro del service worker. El navegador intentará descargar y analizar el archivo del service worker. Si se está analizando tiene éxito, se activa el evento install del service worker. El evento install solo se activa una vez.

La instalación del service worker se realiza silenciosamente, sin requerir el permiso del usuario. incluso si el usuario no instala la AWP. La API de Service Worker está disponible incluso en plataformas que no admiten la instalación de AWP, como Safari y Firefox en dispositivos de escritorio

Luego de la instalación, el service worker debe activarse antes de controlar sus clientes, incluida tu AWP. Cuando el service worker está listo controlar sus clientes, se activa el evento activate. Sin embargo, de forma predeterminada, un service worker activado no puede administrar la página que lo registró hasta el próximo cuando navegues a esa página volviendo a cargar la página o volviendo a abrir la AWP.

Puedes escuchar eventos en el permiso global del service worker mediante self. objeto:

serviceworker.js

// This code executes in its own worker or thread
self.addEventListener("install", event => {
   console.log("Service worker installed");
});
self.addEventListener("activate", event => {
   console.log("Service worker activated");
});

Actualiza un service worker

Los service workers se actualizan cuando el navegador detecta que del cliente y la nueva versión del archivo del service worker desde la de cada servidor sean diferentes en bytes.

Luego de una instalación exitosa, el nuevo service worker espera para activarse el service worker antiguo ya no controla a ningún cliente. Este estado se denomina "esperando", y así el navegador garantiza que solo una versión de tu service worker se esté ejecutando a la vez.

Actualizar una página o volver a abrir la AWP no hará que el nuevo service worker tarde control. El usuario debe cerrar todas las pestañas y ventanas, o salir de ellas, mediante el service worker actual y, luego, vuelve para darle al nuevo service worker control. Para obtener más información, consulta El ciclo de vida de un service worker.

Vida útil de un service worker

Un service worker instalado y registrado puede administrar todas las solicitudes de red dentro de su alcance. Se ejecuta en su propio subproceso, con activación y finalización. controlado por el navegador, lo que le permite funcionar incluso antes de que se abra la AWP o tras el cierre. Los service workers se ejecutan en su propio subproceso, pero se encuentran en el estado de la memoria no persistan entre las ejecuciones de un service worker, así que asegúrate que quieres reutilizar en cada ejecución está disponible en IndexedDB o en alguna otra y el almacenamiento persistente.

Si aún no se está ejecutando, se inicia un service worker cada vez que se envía una solicitud de red se envía dentro de su alcance o cuando recibe un evento activador, como una una sincronización en segundo plano o un mensaje push.

Los service workers se finalizan si han estado inactivos durante algunos segundos o llevan demasiado tiempo ocupados. Los tiempos de este proceso varían según el navegador. Si un un service worker finaliza y ocurre un evento que lo inicia se reinicia.

Funciones

Un service worker registrado y activo usa un subproceso con una interfaz completamente diferente del ciclo de vida de ejecución desde el subproceso principal de la AWP. Sin embargo, de forma predeterminada, el archivo de service worker en sí no tiene comportamiento. No almacenará en caché ni entregará nada recursos; estas son las tareas que tu código debe hacer. Descubrirás cómo en la los siguientes capítulos.

Las funciones de los service workers no son solo para usar un proxy o entregar solicitudes HTTP. Hay otras funciones disponibles para otros fines, como el fondo la ejecución de código, las notificaciones push web y los pagos de procesos. Analizaremos estas adiciones en Funciones.

Recursos