Qué trabajo se puede mover a un worker y qué no

Un trabajador web es un hilo real con su propio bucle de eventos, su propio montículo y su propio intérprete. Lo que ejecuta dentro no toca el hilo principal en absoluto, lo cual lo convierte en la única forma de eliminar trabajo del hilo en lugar de repartirlo. La restricción que lo define es que no tiene DOM, y de esa restricción sale todo el criterio de qué se puede mover y qué no.

El criterio de tres preguntas

¿Necesita el DOM? Si la respuesta es sí, no se puede mover. Dentro de un trabajador no existen document, window, localStorage ni ninguna API que dependa del documento. Y no hay forma de rodearlo: la restricción es de diseño, porque el DOM no es seguro para acceso concurrente y hacerlo seguro habría exigido bloqueos por todas partes.

¿Los datos de entrada y salida se pueden copiar o transferir barato? El coste de mover los datos puede superar al del cálculo. Un array de números de un megabyte se transfiere en microsegundos; un árbol de objetos anidados con cien mil nodos puede costar más en serializar que en procesar. Es el tema de el coste de postMessage.

¿El trabajo dura lo suficiente para amortizar el viaje? Cada ida y vuelta cuesta entre 0,5 y 3 milisegundos solo en el mecanismo de mensajes. Una operación de 2 milisegundos no gana nada; una de 200, sí.

Si las tres respuestas son favorables, el trabajador es la solución correcta y además la mejor: no reparte el bloqueo como el troceado, lo elimina.

Qué hay dentro de un trabajador

Lo que sí está disponible, y es más de lo que la gente cree:

• fetch y toda la API de red, incluida la de flujos.
• IndexedDB, Cache Storage, Crypto, TextEncoder y TextDecoder.
• WebAssembly, con todo lo que eso implica.
• OffscreenCanvas y su contexto 2D y WebGL, lo que permite dibujar fuera del hilo principal.
• WebSocket, BroadcastChannel, MessageChannel.
• performance, setTimeout, structuredClone, URL, Blob, FileReader.
• importScripts en trabajadores clásicos, e import estático y dinámico en trabajadores de módulo.

Lo que no está:

• document, window, parent, y todo el DOM.
• localStorage y sessionStorage. El almacenamiento síncrono no está disponible por diseño; la alternativa es IndexedDB.
• alert, confirm, prompt.
• Las APIs que exigen contexto de documento, como las de historial o las de permisos con interfaz.

La lista de disponibles explica los tres casos de uso que mejor funcionan.

Los tres tipos de trabajo con mejor retorno

Uno: transformación de datos grandes. Parsear, filtrar, ordenar, agregar. Una tabla de cincuenta mil filas que hay que ordenar por tres criterios, un CSV de diez megas que hay que convertir, un conjunto de datos que hay que agrupar. La entrada y la salida suelen ser arrays de tipos primitivos o de objetos planos, y la ganancia es directa.

Dos: cálculo intensivo. Compresión, cifrado, procesamiento de imagen, análisis de audio, cálculo geoespacial, simulación. Es donde WebAssembly brilla, y el trabajador es su hogar natural.

Tres: la red y su procesamiento. Descargar, parsear y normalizar una respuesta grande sin tocar el hilo principal. El fetch en sí no bloquea, pero el await respuesta.json() de un documento de cinco megas sí, y ese trabajo se mueve entero.

Este tercer caso es el más infravalorado y el más fácil de aplicar:

// datos.worker.js
self.addEventListener('message', async (e) => {
  const { id, url } = e.data;
  try {
    const r = await fetch(url);
    if (!r.ok) throw new Error(`HTTP ${r.status}`);
    const bruto = await r.json();               // parseo fuera del hilo principal
    const normalizado = normalizar(bruto);      // transformacion tambien
    self.postMessage({ id, ok: true, datos: normalizado });
  } catch (err) {
    self.postMessage({ id, ok: false, error: String(err) });
  }
});

function normalizar(filas) {
  return filas.map((f) => ({
    id: f.identificador,
    nombre: f.nombre_completo.trim(),
    total: Number(f.importe_total),
    fecha: Date.parse(f.fecha_iso),
  }));
}

// hilo principal
const trabajador = new Worker(new URL('./datos.worker.js', import.meta.url), { type: 'module' });
const pendientes = new Map();
let siguienteId = 0;

trabajador.addEventListener('message', (e) => {
  const { id, ok, datos, error } = e.data;
  const p = pendientes.get(id);
  if (!p) return;
  pendientes.delete(id);
  ok ? p.resolver(datos) : p.rechazar(new Error(error));
});

export function pedirDatos(url) {
  const id = siguienteId++;
  return new Promise((resolver, rechazar) => {
    pendientes.set(id, { resolver, rechazar });
    trabajador.postMessage({ id, url });
  });
}

Dos detalles del código que importan.

new URL('./datos.worker.js', import.meta.url) es la forma correcta de referenciar el fichero del trabajador: los empaquetadores modernos la reconocen y generan el fichero como un artefacto propio con su hash. Una cadena literal no se resuelve bien y rompe en producción.

El identificador de correlación es imprescindible en cuanto hay más de una petición en vuelo. Sin él, no sabes qué respuesta corresponde a qué pregunta. Esta plomería es exactamente lo que resuelve Comlink.

El coste de arrancar

Crear un trabajador no es gratis. El navegador tiene que crear un contexto de ejecución nuevo, con su propio montículo y su propio intérprete, y después descargar, parsear, compilar y ejecutar su código.

Las cifras de referencia: entre 10 y 40 milisegundos para el arranque del contexto en un dispositivo de gama media, más el coste del código del trabajador, que se paga igual que el del hilo principal —descarga, parseo, compilación, ejecución— aunque en un hilo aparte.

De ahí tres consecuencias prácticas.

No crees un trabajador por operación. Créalo una vez y reutilízalo. Un trabajador vivo consume memoria y poco más.

Créalo antes de necesitarlo, no en el momento de la interacción. Arrancarlo dentro de un manejador de clic añade sus 30 milisegundos al procesamiento. Lo correcto es crearlo en tiempo ocioso tras la carga.

let trabajadorPromesa = null;

export function obtenerTrabajador() {
  return (trabajadorPromesa ??= new Promise((resolver) => {
    const crear = () => resolver(new Worker(new URL('./datos.worker.js', import.meta.url), { type: 'module' }));
    if ('requestIdleCallback' in globalThis) requestIdleCallback(crear, { timeout: 2000 });
    else setTimeout(crear, 500);
  }));
}

Mantén el código del trabajador pequeño. Todo lo que importe se descarga y se compila. Un trabajador que arrastra media aplicación tarda tanto en estar listo como el hilo principal.

// hilo principal: transferir el control del canvas
const lienzo = document.querySelector('#grafico');
const desplazado = lienzo.transferControlToOffscreen();
const trabajador = new Worker(new URL('./dibujo.worker.js', import.meta.url), { type: 'module' });
trabajador.postMessage({ tipo: 'init', lienzo: desplazado }, [desplazado]);

// dibujo.worker.js
let ctx = null;

self.addEventListener('message', (e) => {
  if (e.data.tipo === 'init') {
    ctx = e.data.lienzo.getContext('2d');
    requestAnimationFrame(pintar);            // rAF existe dentro del worker
  }
  if (e.data.tipo === 'datos') datos = e.data.valores;
});

let datos = [];
function pintar() {
  const { width: w, height: h } = ctx.canvas;
  ctx.clearRect(0, 0, w, h);
  ctx.beginPath();
  for (let i = 0; i < datos.length; i++) {
    const x = (i / (datos.length - 1)) * w;
    const y = h - datos[i] * h;
    i ? ctx.lineTo(x, y) : ctx.moveTo(x, y);
  }
  ctx.strokeStyle = '#89b4fa';
  ctx.lineWidth = 2;
  ctx.stroke();
  requestAnimationFrame(pintar);
}