Las claves verificadas
- Un Web Worker ejecuta JavaScript en un contexto separado del hilo principal y no manipula directamente el DOM de la página. Ver evidencia
- La comunicación entre la página y el worker usa mensajes, eventos y postMessage para enviar resultados o errores. Ver evidencia
- Mover una tarea sólo conviene si el costo de crear el contexto y transferir datos compensa el bloqueo que se evita. Ver evidencia
- Los datos grandes pueden clonarse o transferirse, y esa elección cambia el costo de comunicación entre contextos. Ver evidencia
Qué es un Web Worker
Un Web Worker permite ejecutar un archivo de JavaScript en un contexto separado del hilo principal de una página. El hilo principal puede seguir atendiendo eventos y renderizando la interfaz mientras el worker procesa una tarea que no necesita tocar el DOM directamente.
También puede servirte: Web Components: qué son y cuándo convienen
La separación no crea memoria compartida por defecto. La página y el worker intercambian mensajes con postMessage y reciben respuestas mediante eventos. El navegador puede clonar los datos enviados o transferir ciertos objetos, por lo que el diseño del mensaje forma parte del costo real de la solución.
Qué tareas conviene mover fuera de la interfaz
Un worker encaja cuando una operación usa bastante CPU y puede recibir una entrada acotada: parsear un archivo grande, procesar datos, calcular una imagen o ejecutar una transformación repetible. La pantalla sigue siendo responsabilidad del documento y el worker devuelve resultados, progreso o errores.
No conviene mover cualquier función por reflejo. Crear el contexto, serializar mensajes y coordinar la respuesta también cuesta. Si una operación es breve o depende de leer y modificar el DOM, mantenerla en el hilo principal puede ser más simple y evitar una comunicación innecesaria.
Cómo se comunican la página y el worker
La página crea un Worker con la URL de un script y puede enviarle una orden con postMessage. El worker escucha el evento message, procesa la entrada y responde por el mismo canal. Para cerrar la tarea, cualquiera de los extremos puede terminar el contexto cuando ya no lo necesita.
El canal no debe tratarse como una llamada local instantánea. Definí un identificador de tarea, un formato de resultado y un mensaje de error. Para volúmenes grandes, evaluá objetos transferibles y evitá copiar estructuras que la interfaz no necesita conservar.
Guía para decidir si usar un Web Worker
Primero medí qué tarea bloquea la interacción y si puede aislarse del DOM. Si el trabajo es pesado, repetible y sus entradas caben en mensajes claros, un worker puede liberar el hilo principal. Si necesita acceso continuo a elementos de la página o dura muy poco, una función normal suele tener menos piezas.
Después definí el contrato: entrada, progreso, resultado, cancelación y error. Probá el caso de datos grandes, una desconexión o una tarea cancelada y compará el tiempo de interacción con y sin worker. La decisión no se basa sólo en tener dos hilos: depende de que el costo de comunicación sea menor que el bloqueo que se quiere evitar.
Qué aporta VisteEsto: Nuestro trabajo en esta nota
VisteEsto convierte la documentación de Workers en una guía de decisión: tipo de tarea, acceso al DOM, costo de mensajes, cancelación y pruebas de interacción antes de mover código.
Fuentes, actualizaciones y metodología 3 fuentes
Fuentes consultadas
- Fuente primariaWHATWG HTML Standard: Workers
- Fuente secundariaMDN: Using web workers
- Fuente secundariaweb.dev: Off the main thread
Historial de actualización
- Publicación inicial basada en el estándar HTML de WHATWG, la guía de Web Workers de MDN y la explicación de web.dev sobre trabajo fuera del hilo principal.
Cómo elaboramos esta nota
Definimos la consulta principal “qué son los Web Workers en JavaScript y cuándo convienen”, contrastamos los datos con 3 fuentes —1 primaria— y revisamos contexto, imágenes y posibles vacíos antes de publicar. Conocé nuestra política editorial y de verificación.
