Los usuarios esperan que las apps se inicien de forma confiable con conexiones de red lentas o débiles, o incluso sin conexión. Esperan que el contenido con el que interactuaron más recientemente, como itinerarios o pistas de contenido multimedia, entradas y entradas, esté disponible y se pueda usar. Cuando no es posible realizar una solicitud, esperan que la app se lo diga en lugar de fallar o fallar en silencio. Y quieren que todo esto suceda rápidamente. Como puedes ver en Los milisegundos valen millones, incluso una mejora de 0.1 segundo en los tiempos de carga puede aumentar la conversión hasta en un 10%. Los service workers son la herramienta que permite que tu app web progresiva (AWP) esté a la altura de las expectativas de los usuarios.
Cuando una app solicita un recurso cubierto por el alcance del service worker, este intercepta la solicitud y actúa como un proxy de red, incluso si el usuario no tiene conexión. Luego, puede decidir si debería entregar el recurso de la caché con la API de Cache Storage, entregarlo desde la red como si no hubiera un service worker activo o crearlo a partir de un algoritmo local. De esta manera, puedes proporcionar una experiencia de alta calidad como la de una app de plataforma, incluso cuando no tiene conexión.
Registra un service worker
Antes de que un service worker tome el control de tu página, debes registrarla para tu AWP. Esto significa que la primera vez que un usuario abre tu AWP, todas sus solicitudes de red irán directamente a tu servidor, ya que el service worker aún no tiene el control de tus páginas.
Después de verificar si el navegador es compatible con la API de Service Worker, tu AWP puede registrar un service worker. Después de que se carga, el service worker se configura entre la AWP y la red, intercepta solicitudes y entrega las respuestas correspondientes.
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register("/serviceworker.js");
}
Verifica si un service worker está registrado
Para verificar si un service worker está registrado, usa las herramientas para desarrolladores de tu navegador favorito.
En Firefox y navegadores basados en Chromium (Microsoft Edge, Google Chrome o Samsung Internet), haz lo siguiente:
- Abre las herramientas para desarrolladores y, luego, haz clic en la pestaña Aplicación.
- En el panel izquierdo, selecciona Service Workers.
- Verifica 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 "En ejecución" o "Detenido".
En Safari:
- Haz clic en Develop > Service Workers.
- Consulta este menú para buscar una entrada con el origen actual. Cuando haces clic en esa entrada, se abre un inspector en el contexto del service worker.
Alcance
La carpeta en la que se encuentra tu service worker determina su alcance. Un service worker que se encuentre en example.com/my-pwa/sw.js puede controlar cualquier navegación en la ruta de acceso my-pwa o en ella, como example.com/my-pwa/demos/. Los service worker solo pueden
controlar los elementos (páginas, trabajadores, colectivamente "clientes") en su alcance.
Este alcance se aplica a las pestañas del navegador y las ventanas de AWP.
Solo se permite un service worker por alcance. Cuando un service worker está activo y en ejecución, por lo general, solo una instancia está 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 alcance más compleja, conocida como particiones, que afecta el funcionamiento de los permisos con iframes multidominio. Para obtener más información sobre la implementación de WebKit, consulta su entrada de blog.
Ciclo de vida
Los service workers tienen un ciclo de vida que determina cómo se instalan, independientemente de la instalación de la AWP.
El ciclo de vida del service worker comienza con el registro del service worker. Luego, el navegador intenta descargar y analizar el archivo del service worker. Si el análisis se realiza correctamente, se activa el evento install del service worker. El evento install solo se activa una vez.
La instalación del service worker se realiza de forma silenciosa, sin requerir el permiso del usuario, incluso si este 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.
Después de la instalación, se debe activar el service worker para que pueda controlar sus clientes, incluida tu AWP. Cuando el service worker está listo para controlar a 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 la próxima vez que navegues a ella. Para ello, vuelve a cargarla o volver a abrir la AWP.
Puedes escuchar eventos en el alcance global del service worker con el objeto self:
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");
});
Actualizar un service worker
Los service workers se actualizan cuando el navegador detecta que el service worker que controla el cliente y la nueva versión del archivo del service worker del servidor tienen una diferencia de bytes.
Después de una instalación exitosa, el service worker nuevo espera para activarse hasta que el anterior ya no controle a ningún cliente. Este estado se denomina "espera" y es la forma en que el navegador garantiza que solo se ejecute una versión de tu service worker a la vez.
Actualizar una página o volver a abrir la AWP no hará que el nuevo service worker tome el control. El usuario debe cerrar o salir de todas las pestañas y ventanas con el service worker actual y, luego, volver para otorgarle el control al nuevo service worker. Para obtener más información, consulta El ciclo de vida del service worker.
Vida útil de 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, y el navegador controla la activación y finalización, lo que le permite funcionar incluso antes de que se abra la AWP o después de cerrarla. Los service workers se ejecutan en su propio subproceso, pero es posible que el estado en la memoria no persista entre las ejecuciones de un service worker, así que asegúrate de que todo lo que quieras reutilizar para cada ejecución esté disponible en IndexedDB o en algún otro almacenamiento persistente.
Si aún no se está ejecutando, un service worker se inicia cada vez que se envía una solicitud de red dentro de su alcance o cuando recibe un evento de activación, como una sincronización periódica en segundo plano o un mensaje push.
Los service workers se cierran si han estado inactivos durante algunos segundos o si han estado ocupados durante demasiado tiempo. Los tiempos varían según el navegador. Si se cerró un service worker y se produce un evento que podría iniciarlo, este se reiniciará.
Capacidades
Un service worker registrado y activo usa un subproceso con un ciclo de vida de ejecución completamente diferente al del subproceso principal de la AWP. Sin embargo, de forma predeterminada, el archivo del service worker no tiene comportamiento. No almacena en caché ni entrega ningún recurso; estas son las tareas que debe realizar tu código. Descubrirás cómo hacerlo en los siguientes capítulos.
Las funciones de service worker no son solo para proxy o entrega de solicitudes HTTP. Además, hay otras funciones disponibles para otros fines, como la ejecución de código en segundo plano, las notificaciones push web y el procesamiento de pagos. Analizaremos estas adiciones en Funciones.