Los service workers ofrecen una utilidad increíble, pero puede ser difícil trabajar con ellos al principio. Workbox facilita el uso de los service workers. Sin embargo, debido a que los service workers resuelven problemas difíciles, cualquier abstracción de esa tecnología también será complicada si no la entiendes. Por lo tanto, estos primeros fragmentos de documentación cubrirán esa tecnología subyacente antes de entrar en los detalles específicos de Workbox.
Para ver una lista de los service workers en ejecución, ingresa chrome://serviceworker-internals/ en la barra de direcciones.
¿Qué proporcionan los service workers?
Los service workers son recursos especializados de JavaScript que actúan como proxies entre los navegadores y los servidores web. Su objetivo es mejorar la confiabilidad mediante el acceso sin conexión, así como aumentar el rendimiento de la página.
Un ciclo de vida similar a una aplicación, con mejora progresiva
Los service workers son una mejora para los sitios web existentes. Esto significa que, si los usuarios de navegadores que no son compatibles con service workers visitan sitios web que los usan, no se daña la funcionalidad del modelo de referencia. De eso se trata la Web.
Los service workers mejoran los sitios web de forma progresiva a través de un ciclo de vida similar al de las aplicaciones específicas de la plataforma. Piensa en lo que sucede cuando se instala una aplicación nativa desde una tienda de aplicaciones:
- Se realiza una solicitud para descargar la aplicación.
- La app se descarga y se instala.
- La app está lista para usarse y se puede iniciar.
- La app se actualiza cuando hay nuevos lanzamientos.
El ciclo de vida del service worker es similar, pero con un enfoque de mejora progresiva. En la primera visita a una página web que instala un nuevo service worker, la visita inicial a una página proporciona la funcionalidad de referencia mientras se descarga el service worker. Después de instalar y activar un service worker, controla la página para ofrecer mayor confiabilidad y velocidad.
Acceso a una API de almacenamiento en caché controlada por JavaScript
Un aspecto indispensable de la tecnología del service worker es la interfaz de Cache,
que es un mecanismo de almacenamiento en caché completamente independiente de la caché HTTP.
Se puede acceder a la interfaz Cache dentro del alcance del service worker y del subproceso principal.
Esto abre muchísimas posibilidades de interacciones controladas por el usuario con una instancia de Cache.
Mientras que la caché HTTP se ve influenciada por las directivas de almacenamiento en caché especificadas en los encabezados HTTP, la interfaz Cache se puede programar con JavaScript.
Esto significa que las respuestas de almacenamiento en caché para las solicitudes de red pueden basarse en la lógica que sea mejor para un sitio web determinado.
Por ejemplo:
- Almacenar recursos estáticos en la caché en la primera solicitud de ellos y entregarlos solo desde la caché en cada solicitud posterior.
- Lenguaje de marcado de la página de la tienda en la caché, pero solo publicar lenguaje de marcado de la caché en situaciones sin conexión
- Entregar respuestas inactivas para ciertos elementos desde la caché, pero actualizarlas desde la red en segundo plano
- Transmite contenido parcial desde la red y ensambla con un shell de app desde la caché para mejorar el rendimiento perceptual.
Cada una es un ejemplo de una estrategia de almacenamiento en caché. Las estrategias de almacenamiento en caché posibilitan las experiencias sin conexión y pueden ofrecer un mejor rendimiento mediante el paso de las comprobaciones de revalidación de alta latencia de HTTP que se inicia la caché HTTP. Antes de comenzar a usar Workbox, se analizarán algunas estrategias de almacenamiento en caché y el código que las hace funcionar.
Una API asíncrona y controlada por eventos
La transferencia de datos a través de la red es inherentemente asíncrona. Lleva tiempo solicitar un recurso, que un servidor responda a esa solicitud y que se descargue la respuesta. El tiempo involucrado es variado e indeterminado. Los service workers se adaptan a esta asincronía mediante una API controlada por eventos, con devoluciones de llamada para eventos como los siguientes:
- Cuando un service worker está instalando.
- Cuando un service worker se está activando.
- Cuando un service worker detecta una solicitud de red.
Los eventos se pueden registrar con una
API de addEventListener conocida.
Todos estos eventos pueden interactuar con la interfaz de Cache.
En particular, la capacidad de ejecutar devoluciones de llamada cuando se envían solicitudes de red es fundamental para proporcionar la confiabilidad y velocidad necesarias.
Hacer trabajo asíncrono en JavaScript implica el uso de promesas.
Debido a que las promesas también respaldan async y await, esas funciones de JavaScript también se pueden usar para simplificar el código del service worker (y de Workbox) para brindar una mejor experiencia del desarrollador.
Almacenamiento previo en caché y almacenamiento en caché del entorno de ejecución
La interacción entre un service worker y una instancia de Cache implica dos conceptos distintos de almacenamiento en caché: el almacenamiento previo en caché y el almacenamiento en caché en el entorno de ejecución.
Cada una de estas opciones es fundamental para los beneficios que puede proporcionar un service worker.
El almacenamiento previo en caché es el proceso de almacenar recursos en caché anticipadamente, por lo general, durante la instalación de un service worker.
Con el almacenamiento previo en caché, los elementos estáticos y los materiales clave necesarios para el acceso sin conexión se pueden descargar y almacenar en una instancia de Cache.
Este tipo de almacenamiento en caché también mejora la velocidad de la página a páginas siguientes que requieren los elementos previamente almacenados en caché.
El almacenamiento en caché en el entorno de ejecución es cuando se aplica una estrategia de almacenamiento en caché a los recursos a medida que se solicitan de la red durante el tiempo de ejecución. Este tipo de almacenamiento en caché es útil porque garantiza el acceso sin conexión a las páginas y los recursos que el usuario ya visitó.
Cuando se combinan, estos enfoques para usar la interfaz Cache en un service worker proporcionan un gran beneficio a la experiencia del usuario y proporcionan comportamientos similares a los de una app a páginas web que por otra parte serían normales.
Aislamiento del subproceso principal
El estado del rendimiento de JavaScript es un desafío en evolución para la Web y, desde la perspectiva del usuario, depende de las capacidades del dispositivo y del acceso a Internet de alta velocidad. Cuanto más se use JavaScript, más difícil será compilar sitios web rápidos que brinden experiencias del usuario agradables.
Los service workers son como los trabajadores web en el sentido de que todo el trabajo que realizan ocurre en sus propios subprocesos. Esto significa que las tareas de los service workers no competirán por la atención con otras tareas del subproceso principal. Por su diseño, los service workers priorizan al usuario.
La ruta por delante
Esta documentación es solo una descripción general. Hay algunos temas más para abordar sobre los service workers antes de abordar Workbox en sí, pero no te preocupes: con una comprensión sólida de los service workers, usar Workbox será una experiencia más fácil y productiva.