Cómo los web workers y los service workers pueden mejorar el rendimiento de tu sitio, y cuándo usar un web worker en lugar de un service worker
En esta descripción general, se explica cómo los Web Workers y los Service Workers pueden mejorar el rendimiento de tu sitio web, y cuándo usar un Web Worker en lugar de un Service Worker. Consulta el resto de esta serie para conocer patrones específicos de comunicación entre ventanas y service workers.
Cómo los trabajadores pueden mejorar tu sitio web
El navegador usa un solo subproceso (el subproceso principal) para ejecutar todo el código JavaScript de una página web, así como para realizar tareas como renderizar la página y realizar la recolección de elementos no utilizados. Ejecutar un exceso de código JavaScript puede bloquear el subproceso principal, lo que retrasa la realización de estas tareas por parte del navegador y genera una mala experiencia del usuario.
En el desarrollo de aplicaciones para iOS y Android, un patrón común para garantizar que el subproceso principal de la app permanezca libre para responder a los eventos del usuario es descargar operaciones en subprocesos adicionales. De hecho, en las versiones más recientes de Android, bloquear el subproceso principal durante demasiado tiempo provoca una falla en la app.
En la Web, JavaScript se diseñó en torno al concepto de un solo subproceso y carece de las capacidades necesarias para implementar un modelo de subprocesos múltiples como el que tienen las apps, como la memoria compartida.
A pesar de estas limitaciones, se puede lograr un patrón similar en la Web usando workers para ejecutar secuencias de comandos en subprocesos en segundo plano, lo que les permite realizar tareas sin interferir en el subproceso principal. Los trabajadores son un alcance de JavaScript completo que se ejecuta en un subproceso separado, sin memoria compartida.
En esta publicación, aprenderás sobre dos tipos diferentes de trabajadores (trabajadores web y trabajadores de servicio), sus similitudes y diferencias, y los patrones más comunes para usarlos en sitios web de producción.
Web workers y service workers
Similitudes
Los Web Workers y los Service Workers son dos tipos de trabajadores disponibles para los sitios web. Tienen algunas cosas en común:
- Ambos se ejecutan en un subproceso secundario, lo que permite que el código JavaScript se ejecute sin bloquear el subproceso principal ni la interfaz de usuario.
- No tienen acceso a los objetos
WindowyDocument, por lo que no pueden interactuar con el DOM directamente y tienen acceso limitado a las APIs del navegador.
Diferencias
Se podría pensar que la mayoría de las tareas que se pueden delegar a un trabajador web se pueden realizar en un trabajador de servicio y viceversa, pero existen diferencias importantes entre ellos:
- A diferencia de los trabajadores web, los trabajadores de servicio te permiten interceptar solicitudes de red (a través del evento
fetch) y detectar eventos de la API de Push en segundo plano (a través del eventopush). - Una página puede generar varios trabajadores web, pero un solo service worker controla todas las pestañas activas en el alcance con el que se registró.
- La vida útil del trabajador web está estrechamente vinculada a la pestaña a la que pertenece, mientras que el ciclo de vida del trabajador de servicio es independiente de ella. Por ese motivo, cerrar la pestaña en la que se ejecuta un Web Worker lo finalizará, mientras que un Service Worker puede seguir ejecutándose en segundo plano, incluso cuando el sitio no tenga ninguna pestaña activa abierta.
Casos de uso
Las diferencias entre ambos tipos de trabajadores sugieren en qué situaciones se podría querer usar uno u otro:
Los casos de uso de los trabajadores web se relacionan más comúnmente con la descarga de trabajo (como cálculos pesados) en un subproceso secundario para evitar el bloqueo de la IU.
- Ejemplo: El equipo que creó el videojuego PROXX quería dejar el subproceso principal lo más libre posible para encargarse de las animaciones y las entradas del usuario. Para lograrlo, usaron Web Workers para ejecutar la lógica del juego y el mantenimiento del estado en un subproceso independiente.
Las tareas de Service Workers suelen estar más relacionadas con actuar como proxy de red, controlar tareas en segundo plano y aspectos como el almacenamiento en caché y el modo sin conexión.
Ejemplo: En una PWA de podcasts, es posible que se quiera permitir que los usuarios descarguen episodios completos para escucharlos sin conexión. Un service worker y, en particular, la API de Background Fetch se pueden usar para ese fin. De esa manera, si el usuario cierra la pestaña mientras se descarga el episodio, no se interrumpirá la tarea.
Herramientas y bibliotecas
La comunicación entre ventanas y trabajadores se puede implementar con diferentes APIs de nivel inferior. Afortunadamente, existen bibliotecas que abstraen este proceso y se encargan de los casos de uso más comunes. En esta sección, abordaremos dos de ellos que se encargan de la ventana para los trabajadores web y los trabajadores de servicio, respectivamente: Comlink y Workbox.
Comlink
Comlink es una pequeña biblioteca de RPC (1.6 k) que se encarga de muchos detalles subyacentes cuando se compilan sitios web que usan Web Workers. Se usó en sitios web como PROXX y Squoosh. Puedes encontrar un resumen de sus motivaciones y muestras de código aquí.
Workbox
Workbox es una biblioteca popular para compilar sitios web que usan service workers. Empaqueta un conjunto de prácticas recomendadas en torno a aspectos como el almacenamiento en caché, la sincronización en segundo plano sin conexión, etcétera. El módulo workbox-window proporciona una forma conveniente de intercambiar mensajes entre el service worker y la página.
Próximos pasos
El resto de esta serie se centra en los patrones de comunicación entre la ventana y el service worker:
- Guía de almacenamiento en caché imperativo: Llama a un service worker desde la página para almacenar en caché los recursos con anticipación (p.ej., en situaciones de recuperación previa).
- Actualizaciones de transmisión: Se llama a la página desde el Service Worker para informar sobre actualizaciones importantes (p.ej., hay disponible una nueva versión del sitio web).
- Comunicación bidireccional: Delegar una tarea a un trabajador de servicio (p. ej., una descarga pesada) y mantener informada a la página sobre el progreso
Para conocer los patrones de comunicación de los subprocesos de trabajo y de ventana, consulta Usa subprocesos de trabajo para ejecutar JavaScript fuera del subproceso principal del navegador.