Cómo los trabajadores web y los service worker pueden mejorar el rendimiento de tu sitio y cuándo usar un trabajador web en lugar de un service worker
Esta descripción general explica cómo los trabajadores web y los service worker pueden mejorar el rendimiento de tu sitio web, y cuándo usar un trabajador web en lugar de un service worker. Consulta el resto de esta serie para conocer los patrones específicos de comunicación entre ventanas y service workers.
Cómo los trabajadores pueden mejorar tu sitio web
El navegador utiliza un solo subproceso (el subproceso principal) para ejecutar todo el código JavaScript en una página web y para realizar tareas como renderizar la página y realizar la recolección de elementos no utilizados. Ejecutar un código JavaScript excesivo puede bloquear el subproceso principal, lo que retrasa el navegador para realizar esas tareas y genera una mala experiencia del usuario.
En el desarrollo de aplicaciones para iOS/Android, un patrón común que garantiza que el subproceso principal de la app permanezca libre para responder a 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 genera una falla de 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 varios subprocesos 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 trabajadores 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 independiente, sin memoria compartida.
En esta publicación, obtendrás información sobre dos tipos diferentes de trabajadores (trabajadores web y service worker), sus similitudes y diferencias, y los patrones más comunes para usarlos en sitios web de producción.
Trabajadores web y service worker
Similitudes
Los trabajadores web y los trabajadores de servicio son dos tipos de trabajadores disponibles para los sitios web. Tienen algunas características en común:
- Ambos se ejecutan en un subproceso secundario, lo que permite que se ejecute el código JavaScript 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 cosas que se pueden delegar a un trabajador web pueden hacerse en un service worker y viceversa, pero hay diferencias importantes entre ellos:
- A diferencia de los trabajadores web, los service worker te permiten interceptar solicitudes de red (mediante el evento
fetch) y escuchar los eventos de la API de Push en segundo plano (mediante el eventopush). - Una página puede generar varios trabajadores web, pero uno solo controla todas las pestañas activas del 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 su ciclo de vida es independiente de ella. Por ese motivo, si cierras la pestaña en la que se está ejecutando un trabajador web, esta se cerrará, mientras que un service worker puede seguir ejecutándose en segundo plano, incluso si el sitio no tiene ninguna pestaña activa abierta.
Casos de uso
Las diferencias entre ambos tipos de trabajadores sugieren en qué situaciones se recomienda usar uno o el otro:
Los casos de uso de los trabajadores web suelen estar relacionados con la transferencia del trabajo (como los cálculos pesados) a un subproceso secundario para evitar el bloqueo de la IU.
- Ejemplo: El equipo que compiló el videojuego PROXX quería dejar el subproceso principal con la mayor libertad posible para ocuparse de las entradas y las animaciones del usuario. Para lograrlo, usó trabajadores web a fin de ejecutar la lógica del juego y el mantenimiento del estado en un subproceso separado.
Por lo general, las tareas de service workers están más relacionadas con actuar como proxy de red, controlar tareas en segundo plano y tareas como el almacenamiento en caché y el uso sin conexión.
Ejemplo: En una AWP de podcast, es posible que quieras permitir que los usuarios descarguen episodios completos para escucharlos sin conexión. Se puede usar un service worker y, en particular, la API de recuperación en segundo plano. De esa manera, si el usuario cierra la pestaña mientras se descarga el episodio, no es necesario interrumpir la tarea.
Herramientas y bibliotecas
La comunicación entre ventanas y trabajadores se puede implementar mediante diferentes APIs de nivel inferior. Por suerte, hay bibliotecas que abstraen este proceso y se ocupan de los casos de uso más comunes. En esta sección, abordaremos dos de ellas que se encargan de la ventana a los trabajadores web y los service worker, respectivamente: Comlink y Workbox.
Vincular
Comlink es una biblioteca RPC pequeña (1.6k) que se ocupa de muchos detalles subyacentes cuando se compilan sitios web que usan Web Workers. Se ha usado en sitios web como PROXX y Squoosh. Aquí encontrarás un resumen de sus motivaciones y muestras de código.
Workbox
Workbox es una biblioteca popular para compilar sitios web que usan service workers. Empaqueta un conjunto de prácticas recomendadas sobre cuestiones como el almacenamiento en caché, el uso sin conexión, la sincronización en segundo plano, etc. El módulo workbox-window proporciona una manera 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 ventanas y service worker:
- Guía de almacenamiento en caché imperativo: Llamar a un service worker desde la página a los recursos en caché por adelantado (p.ej., en situaciones de carga previa).
- Transmitir actualizaciones: Llamar a la página desde el service worker para informar sobre actualizaciones importantes (p.ej., hay una nueva versión del sitio web disponible).
- Comunicación bidireccional: Delegar una tarea a un service worker (p.ej., una descarga pesada) y mantener a la página informada sobre el progreso.
Para conocer los patrones de comunicación de ventana y trabajador web, consulta Usa trabajadores web para ejecutar JavaScript desde el subproceso principal del navegador.