Clonado estructurado: el peaje de cada entrada y cada salida

IndexedDB no guarda tus objetos. Guarda una imagen serializada de tu grafo de objetos y te entrega una reconstrucción nueva cada vez que lees. Entre tu variable y el disco vive un algoritmo del estándar HTML —el clonado estructurado— que recorre el grafo nodo a nodo, detecta ciclos, rechaza lo que no sabe representar y produce una copia profunda. Ese recorrido, y no la escritura en el disco, es lo que suele dominar el perfil en cuanto los objetos dejan de ser diminutos.

Qué ocurre al cruzar la frontera

La especificación HTML define dos operaciones abstractas complementarias: StructuredSerialize, que convierte un valor de JavaScript en una representación intermedia independiente del realm, y StructuredDeserialize, que reconstruye un valor nuevo a partir de ella. IndexedDB invoca la primera —en su variante ForStorage, algo más estricta— sobre cada valor que pasas a put o add, y la segunda sobre cada valor que sale de un get, un getAll o un cursor.

Tres consecuencias caen de ahí y conviene tenerlas explícitas. La primera: el algoritmo es síncrono y se ejecuta en el hilo que hizo la llamada, aunque la API sea asíncrona; lo asíncrono es la entrada y salida, no el recorrido. La segunda: es una copia profunda, de modo que el objeto que lees nunca es idéntico al que escribiste, ni siquiera si la escritura acaba de ocurrir. La tercera: el algoritmo mantiene un mapa de memoria de los objetos ya visitados para preservar la identidad compartida y tolerar ciclos, lo que significa que cada nodo del grafo paga una consulta y una inserción en una tabla hash.

flowchart LR
A[objeto en tu hilo] --> B[StructuredSerializeForStorage]
B --> C[representacion intermedia]
C --> D[motor de almacenamiento]
D --> E[disco]
E --> F[bytes recuperados]
F --> G[StructuredDeserialize]
G --> H[objeto NUEVO distinto del original]

Que la lectura devuelva un objeto nuevo no es un detalle académico: invalida cualquier estrategia de caché basada en identidad referencial, obliga a revalidar invariantes y explica por qué mutar lo que acabas de leer no cambia nada en la base.

Conviene además distinguir dos algoritmos que la API mezcla sin avisar. Los valores pasan por el clonado estructurado en su variante para almacenamiento, algo más restrictiva que la general —no admite objetos que solo tienen sentido dentro de un realm vivo, ni memoria compartida—. Las claves, en cambio, no se clonan: pasan por una conversión mucho más estrecha que solo acepta números finitos, cadenas, fechas, ArrayBuffer y sus vistas, y arrays de esos mismos tipos. Nada más. Un undefined, un null, un booleano o un objeto plano como clave lanzan DataError, y una ruta de clave que apunte a un campo ausente simplemente no produce entrada de índice.

store.put({ id: 1, activo: true });                  // ok: la clave es 1
store.put({ id: null });                             // DataError: null no es clave
store.put({ id: [2026, "abril"] });                  // ok: array de clave valida
store.put({ id: { compuesta: true } });              // DataError: objeto no es clave

El catálogo: qué sobrevive y qué no

class Nota {
  #secreto = 42;
  constructor(t) { this.texto = t; this.creada = new Date(); }
  get resumen() { return this.texto.slice(0, 20); }
  render() { return `<p>${this.texto}</p>`; }
}

const copia = structuredClone(new Nota("hola"));
copia instanceof Nota;      // false: el prototipo se perdio
copia.creada instanceof Date; // true: Date si esta en el catalogo
copia.resumen;              // "hola": el getter se evaluo y quedo como valor
copia.render;               // undefined: el metodo vivia en el prototipo

El coste escala con los nodos, no con los bytes

Aquí está el modelo mental que hay que interiorizar. El clonado estructurado es un recorrido en profundidad del grafo. Su coste es aproximadamente lineal en el número de nodos visitados, no en la cantidad de memoria que ocupan. Por cada nodo hay que decidir su tipo, consultar el mapa de memoria para saber si ya se visitó, insertarlo, iterar sus claves propias enumerables y recursar. Ese trabajo por nodo es pequeño pero constante, y se multiplica por la cardinalidad del grafo.

De ahí sale una asimetría poco intuitiva: un registro con un ArrayBuffer de cinco megabytes se serializa casi instantáneamente, mientras que un registro de cincuenta kilobytes formado por veinte mil objetos minúsculos —una lista de operaciones, un árbol sintáctico, un documento con anotaciones por carácter— puede costar órdenes de magnitud más. La factura no la emite el disco: la emite el recorrido.

Esa asimetría es especialmente cruel en local-first, porque las estructuras que este tipo de aplicaciones acumulan son exactamente las peores para el algoritmo: historiales de operaciones, árboles de documento con un nodo por fragmento de texto, mapas de metadatos por identificador de réplica. Son grafos con altísima cardinalidad y poquísimo contenido por nodo, es decir, la peor relación posible entre trabajo de recorrido y bytes útiles. Un CRDT maduro guarda su estado en representaciones compactas y binarias precisamente por esta razón, aunque su modelo lógico sea un grafo.

// Aisla el peaje del resto del sistema: sin transacciones, sin disco, sin IPC.
function medirClonado(valor, repeticiones = 20) {
  structuredClone(valor);              // calienta el JIT
  const t0 = performance.now();
  for (let i = 0; i < repeticiones; i++) structuredClone(valor);
  return (performance.now() - t0) / repeticiones;
}

// Compara dos representaciones del MISMO contenido.
const grafo = { ops: Array.from({ length: 20000 }, (_, i) => ({ i, t: "ins", c: "x" })) };
const bytes = new TextEncoder().encode(JSON.stringify(grafo)).buffer;

medirClonado(grafo); // recorre 20001 nodos y sus propiedades
medirClonado(bytes); // recorre 1 nodo opaco

Del diagnóstico al diseño

Antes de rediseñar nada conviene tener una cifra de referencia: cuántos nodos tiene de verdad tu registro típico. Casi nadie lo sabe, y casi siempre la respuesta es un orden de magnitud mayor de lo que se estimaba, porque el anidamiento se acumula por capas —un envoltorio aquí, unos metadatos allá— sin que ninguna sea culpable por sí sola.

function contarNodos(v, vistos = new Set()) {
  if (v === null || typeof v !== "object" || vistos.has(v)) return 0;
  vistos.add(v);
  let n = 1;
  for (const k of Object.keys(v)) n += contarNodos(v[k], vistos);
  return n;
}

La consecuencia práctica es que la forma del registro es una decisión de rendimiento, no de estilo. Aplanar un grafo profundo en unos pocos objetos con campos escalares reduce la cardinalidad y por tanto el peaje. Sustituir la parte que nunca se consulta por un ArrayBuffer codificado con tu propio formato —o con un códec binario compacto— convierte miles de nodos en uno solo, a cambio de perder la capacidad de indexar por dentro. Y mantener fuera del registro los campos que solo existen para la vista evita pagar por lo que se recalcula igual al leer.

// Antes: un grafo entero por registro, indexable pero caro de cruzar.
await store.put({ id, titulo, autor, bloques: [ /* miles de nodos */ ] });

// Despues: escalares para indexar arriba, carga util opaca abajo.
await store.put({ id, titulo, autorId: autor.id, cuerpo: codificar(bloques) });

Existe un escalón intermedio entre el grafo y el buffer binario que casi nadie considera: guardar el cuerpo como una cadena de texto ya serializada. Una cadena es un solo nodo para el clonado, igual que un buffer, y no exige elegir códec ni escribir decodificador; a cambio, pagas una conversión a texto al escribir y un análisis sintáctico al leer. Si eso sale a cuenta o no depende del motor y de la forma del dato, y es exactamente el tipo de decisión que hay que resolver midiendo las tres variantes sobre tus registros reales en lugar de razonándola.

Hay un matiz que se pasa por alto y que puede invertir el resultado: el clonado no solo cuesta tiempo, también cuesta memoria transitoria. Durante la serialización coexisten el grafo original y su representación intermedia; durante la deserialización coexisten los bytes y el grafo reconstruido. Con registros grandes eso significa un pico de asignación que el recolector tendrá que limpiar después, y ese trabajo aparece más tarde, desplazado, en un punto del perfil donde ya no lo relacionas con la escritura que lo causó. Los picos de memoria por lectura masiva y las pausas de recolección poco después son el mismo fenómeno visto dos veces.