El clonado estructurado: qué cruza y qué se queda

Entre tu postMessage y el manejador del otro lado se interpone un algoritmo del estándar HTML con nombre poco glamuroso y consecuencias enormes: la serialización estructurada. No es un formato de intercambio como JSON ni una copia superficial como el operador de propagación: es un recorrido completo del grafo de objetos que sale de tu valor, con un mapa de nodos ya visitados para no caer en ciclos, un catálogo cerrado de tipos que sabe reconstruir y un rechazo tajante de todo lo que no encaje. Entenderlo con precisión resuelve de golpe las dos preguntas que más tiempo hacen perder en la frontera entre hilos: por qué mi objeto llegó sin métodos, y por qué enviar un mensaje tarda más que calcular la respuesta.

Un copiador de grafos, no un serializador

La comparación con JSON.stringify aclara la naturaleza del algoritmo por contraste. JSON produce texto, se atraganta con un ciclo, no distingue una fecha de una cadena y convierte dos referencias al mismo objeto en dos objetos distintos. El clonado estructurado no produce texto en ningún momento —la representación intermedia es interna al motor y jamás la ves—, atraviesa ciclos sin inmutarse y, lo que más se subestima, preserva la identidad compartida: si tu mensaje contiene dos referencias al mismo objeto, al otro lado siguen siendo un único objeto con dos referencias.

const usuario = { nombre: 'Ada' };
const equipo = { lider: usuario, miembros: [usuario] };
equipo.miembros.push(equipo);            // ciclo deliberado

const copia = structuredClone(equipo);

copia.lider === copia.miembros[0];       // true: la identidad se conserva
copia.miembros[1] === copia;             // true: el ciclo tambien
copia.lider === usuario;                 // false: es otro objeto, claro

Que esas dos propiedades se conserven no es un detalle de lujo: es lo que permite enviar estructuras de datos reales —listas con nodos compartidos, índices que apuntan a los mismos registros, árboles con referencias al padre— sin aplanarlas primero. Y explica por qué el algoritmo tiene que llevar un mapa de nodos visitados, con el coste que eso implica.

flowchart LR
A[Valor en el hilo emisor] --> B[Recorrido nodo a nodo]
B --> C[Mapa de nodos ya vistos]
C --> D[Representacion interna del motor]
D --> E[Cola de mensajes del destino]
E --> F[Reconstruccion nodo a nodo]
F --> G[Grafo nuevo en el hilo receptor]
style D fill:#cba6f7,color:#11111b
style G fill:#a6e3a1,color:#11111b

El catálogo: pasa, muere o se degrada

El catálogo tiene tres cajones y el peligroso es el tercero, porque no avisa. En el primero está lo que atraviesa la frontera intacto: primitivas incluido BigInt y undefined, Date, RegExp, Map, Set, ArrayBuffer y todas las vistas tipadas, DataView, Blob, File, ImageData, ImageBitmap, los errores estándar del lenguaje y, por supuesto, arrays y objetos planos.

En el segundo está lo que lanza un DataCloneError en el acto, es decir, lo que falla ruidosamente y por tanto no da problemas: funciones, símbolos, nodos del DOM, WeakMap y WeakSet. Que fallen es una buena noticia; te enteras en la primera ejecución.

structuredClone(() => 1);          // DataCloneError: las funciones no cruzan
structuredClone(Symbol('x'));      // DataCloneError
structuredClone(new WeakMap());    // DataCloneError
structuredClone(document.body);    // DataCloneError

El tercer cajón es el traicionero: lo que cruza pero llega distinto de como salió. Aquí no hay excepción, no hay aviso y el fallo aparece más tarde, en una línea que parecía inocente.

class Documento {
  #interno = 'privado';
  constructor(id) { this.id = id; }
  get titulo() { return 'Doc ' + this.id; }
  renombrar(t) { /* ... */ }
}

const d = new Documento(7);
Object.defineProperty(d, 'oculto', { value: 1, enumerable: false });

const c = structuredClone(d);

c instanceof Documento;                      // false: el prototipo se pierde
typeof c.renombrar;                          // 'undefined'
c.titulo;                                    // undefined: el getter vivia en el prototipo
c.oculto;                                    // undefined: lo no enumerable se descarta
Object.isFrozen(structuredClone(Object.freeze({})));  // false: se pierde el congelado

El precio se cobra dos veces

Aquí está la parte que casi nunca aparece en los tutoriales y que decide el rendimiento de una arquitectura con Workers. postMessage no es asíncrono para quien lo llama. La serialización ocurre de forma síncrona, en el hilo emisor, antes de que la función retorne. Después el mensaje viaja, y la reconstrucción ocurre también de forma síncrona, en el hilo receptor, antes de que se ejecute tu manejador. Un mensaje caro bloquea los dos hilos, uno detrás de otro, y ninguno de esos dos bloqueos aparece atribuido a tu código en un perfil ingenuo.

// aisla el coste real del recorrido, sin worker de por medio
const grafo = Array.from({ length: 100_000 }, (_, i) => ({
  id: i,
  nombre: 'registro ' + i,
  etiquetas: ['alfa', 'beta'],
  meta: { visto: false, version: 1 },
}));

let t = performance.now();
structuredClone(grafo);
console.log('grafo de objetos', (performance.now() - t).toFixed(1), 'ms');

// mismo volumen de bytes, un solo nodo
const plano = new Float64Array(600_000);
t = performance.now();
structuredClone(plano);
console.log('array tipado', (performance.now() - t).toFixed(1), 'ms');

La diferencia entre esas dos mediciones suele ser de dos órdenes de magnitud, y explica la regla operativa de toda la lección: el coste escala con el número de nodos del grafo, no con los bytes. Cien mil objetos pequeños son cien mil asignaciones, cien mil consultas al mapa de visitados y cien mil reconstrucciones al otro lado; un array tipado de varios megabytes es un nodo y una copia de bloque que el procesador hace a velocidad de memoria. Por eso una lista de registros pesa mucho más de lo que su tamaño en disco sugiere, y por eso reorganizar los mismos datos en columnas —un array tipado por campo en lugar de un objeto por fila— puede cambiar el coste de un mensaje de decenas de milisegundos a fracciones de uno.

Diseñar mensajes que no duelan

La conclusión no es evitar los Workers ni renunciar al clonado, sino tratar la forma del mensaje como una decisión de diseño con impacto medible, igual que tratas el esquema de una tabla. Cuatro criterios cubren casi todos los casos reales.

El primero es enviar datos, nunca objetos de dominio. Como los prototipos no cruzan, cualquier intento de mandar entidades ricas termina en objetos mutilados y en rehidrataciones frágiles. Define estructuras planas y explícitas para el canal, con un campo de tipo, y reconstruye lo que necesites en el destino. Es la misma disciplina que separa un DTO de una entidad, y aquí no es una preferencia estética: la impone el algoritmo.

El segundo es reducir el número de nodos. Mil registros con seis campos son siete mil nodos; los mismos datos en seis arrays paralelos son seis nodos más las primitivas. Si además esos arrays son tipados, entras en el terreno de la lección siguiente y el coste se desploma a cero transfiriendo en lugar de copiando.

El tercero es no mandar lo que no se va a leer. Es tentador enviar el registro completo porque ya lo tienes, pero cada campo ignorado se recorre, se copia y se reconstruye igual. Proyectar antes de enviar es la optimización más barata que existe en esta frontera.

El cuarto es medir antes de rediseñar. structuredClone está disponible como función global precisamente para que puedas aislar el coste del recorrido sin montar un Worker. Si el clonado de tu mensaje típico es de microsegundos, no reorganices nada; si es de decenas de milisegundos, ya sabes dónde está tu problema y no era el disco ni la red.