Los ejes que importan de verdad, y en qué orden

La tentación al elegir una librería CRDT es abrir tres benchmarks, mirar quién gana más columnas y firmar. El problema no está en los benchmarks, que suelen estar bien hechos, sino en que sus columnas no pesan lo mismo en tu decisión y el benchmark no puede decirte cuánto pesa cada una porque eso depende de algo que él no conoce: qué errores puedes corregir después con un parche y qué errores te obligan a migrar el formato de todos los documentos que tus usuarios ya tienen guardados. Un eje reversible y uno irreversible no son comparables aunque los dos se midan en megabytes. Esta lección ordena los seis ejes por irreversibilidad y no por la impresión que causa cada cifra, y ese orden es lo único de todo el nivel que conviene memorizar, porque las cifras concretas caducan con cada versión y el orden no.

El orden lo fija la irreversibilidad, no la importancia

Un criterio de ordenación aparentemente razonable sería colocar primero lo que el usuario nota antes. Llevaría a poner el tiempo de carga arriba y el tamaño en disco al final, y es exactamente el orden que produce las decisiones más caras de esta materia. El tiempo de carga es un eje reversible: si dentro de un año descubres que arrancar tarda demasiado, puedes cargar de forma perezosa, partir el documento, mover el trabajo a un worker o esperar a que la propia librería lo mejore. Ninguna de esas correcciones toca los bytes que ya están escritos en los dispositivos de tus usuarios.

El tamaño en disco no funciona así. No es una cifra de rendimiento sino una consecuencia del formato, y el formato es lo único de una librería CRDT que no puedes cambiar sin tocar cada documento existente. Además compone en cinco sitios a la vez que se olvidan al mirar un solo número: ocupa cuota en el navegador, que es finita y está sujeta a desalojo; multiplica el coste de cada copia de seguridad; determina cuántos bytes cruzan la red en cada sincronización de cada dispositivo; fija el tiempo de la primera carga en un dispositivo nuevo; y, si cifras extremo a extremo, decide cuánto material hay que descifrar antes de poder mostrar nada.

De ahí sale el principio de ordenación que sostiene todo el nivel: un eje pesa en proporción a lo que costaría equivocarse en él, no en proporción a lo llamativa que sea su cifra. Bajo ese criterio el orden es tamaño en disco, memoria en caliente, tiempo de carga, peso del módulo, madurez del ecosistema y forma de tus datos, y cada posición tiene una justificación que se puede reconstruir sin apelar a ninguna preferencia.

La prueba que separa un eje reversible de uno irreversible se puede formular en una sola pregunta y conviene hacérsela literalmente a cada uno de los seis: si dentro de dos años descubro que me equivoqué aquí, ¿la corrección la puedo desplegar yo solo, o necesita que miles de dispositivos que no controlo cooperen? Todo lo que se corrige con un despliegue es negociable. Todo lo que exige cooperación ajena es una decisión que se toma una vez, y esa distinción no aparece en ningún cuadro comparativo porque no es una propiedad de las librerías sino de tu relación con los datos que ya escribieron.

flowchart TB
M[ejes que un benchmark sabe medir] --> M1[tamano en disco]
M1 --> M2[memoria en caliente]
M2 --> M3[tiempo de carga]
M3 --> M4[peso del modulo]
J[ejes que exigen juicio propio] --> J1[madurez del ecosistema]
J1 --> J2[forma de tus datos]
M4 --> R[decision defendible]
J2 --> R
style M fill:#89b4fa,color:#11111b
style J fill:#cba6f7,color:#11111b
style R fill:#a6e3a1,color:#11111b

Los cuatro ejes que un benchmark sabe medir

El tamaño en disco va primero por lo ya dicho, y hay una distinción dentro de él que casi ningún cuadro comparativo hace explícita: no es lo mismo el tamaño del estado actual que el tamaño del estado más su historia. Loro y Automerge guardan el grafo completo del historial; Yjs no. Esa diferencia estructural no es un defecto de nadie, es una elección de producto con consecuencias opuestas: quien guarda el grafo puede responder preguntas sobre el pasado y paga por ellas todos los días; quien no lo guarda es más ligero y no puede responderlas. Comparar sus tamaños sin decir esto produce una tabla que engaña en las dos direcciones.

La memoria en caliente va segunda porque decide algo más binario que el rendimiento: decide si tu aplicación funciona en el dispositivo o lo mata. Un documento que ocupa poco en disco puede desplegarse en memoria a un múltiplo enorme de su tamaño, y ese múltiplo es propiedad de la representación interna, no del contenido. La versión 3.0 de Automerge, de julio de 2025, es la mejor ilustración disponible: bajó la memoria un orden de magnitud, de 700 MB a 1,3 MB en un documento del tamaño de Moby Dick. Un salto de esa escala no es una optimización, es la diferencia entre un caso de uso posible y uno imposible.

El tiempo de carga va tercero porque es el eje donde la promesa local-first se cumple o se rompe delante del usuario, y a la vez el más reversible de los cuatro. La misma versión 3.0 llevó la carga de ese documento de 17 horas a 9 segundos, y conviene detenerse en lo que significa un número como 17 horas: no es una aplicación lenta, es una aplicación que no existe. Cuando un eje se mueve en ese rango, deja de ser una métrica y pasa a ser una frontera de viabilidad.

El peso del módulo cierra el grupo medible y va cuarto por una razón concreta: es un coste fijo, se paga una vez, se cachea y no crece con tus datos. Es también el único eje donde Loro, que es el más rápido en los benchmarks, no gana: el tiempo de carga de su módulo WebAssembly es su punto débil. Que su única debilidad medida esté en el eje menos irreversible de los cuatro es exactamente el tipo de matiz que un ranking por número de columnas ganadas destruye.

Los cuatro se pueden medir sobre tu propio documento con muy poco código, y hacerlo cambia la conversación entera porque sustituye cifras ajenas por cifras tuyas. El esqueleto es siempre el mismo con las tres librerías, y lo único que hay que cuidar es anotar la versión junto a cada resultado.

// Los ejes medibles, sobre tu forma de dato y no sobre la de un articulo
async function medirEjes(construirDocumentoTipico) {
  const doc = construirDocumentoTipico();      // tu documento, no Moby Dick
  const bytes = serializar(doc);               // eje 1: tamano en disco

  const antes = performance.now();
  const cargado = deserializar(bytes);         // eje 3: hasta estado utilizable
  const carga = performance.now() - antes;

  return {
    disco: bytes.byteLength,
    carga,
    memoria: await medidaDeMemoria(cargado),   // eje 2: memoria en caliente
    modulo: TAMANO_DEL_MODULO,                 // eje 4: coste fijo, una sola vez
    version: VERSION_DE_LA_LIBRERIA,           // sin esto el numero no vale nada
  };
}

Anotar la versión no es burocracia. Una sola versión mayor de una de estas librerías ha movido dos de los cuatro ejes en un orden de magnitud, de modo que un resultado sin versión es un dato que no se puede interpretar ni reproducir seis meses después.

Los cuatro ejes medibles no son independientes entre sí, y saber cómo se acoplan evita medir de más. La memoria en caliente suele comportarse como un múltiplo del tamaño en disco, y ese múltiplo es una propiedad de la representación interna que se mantiene bastante estable entre documentos de la misma forma. El tiempo de carga, a su vez, tiende a seguir a la memoria más que al disco, porque lo caro no es leer los bytes sino construir las estructuras. Ese encadenamiento explica por qué una mejora de formato como el almacenamiento columnar de Automerge 3.0 movió los tres a la vez, y por qué medir uno solo da una impresión incompleta.

El peso del módulo es el único que queda fuera de ese encadenamiento, y esa independencia es justo lo que lo hace poco decisivo: no arrastra a nada ni es arrastrado por nada, y su efecto se agota en la primera visita de cada dispositivo.

Los dos ejes que ningún benchmark puede medir

La madurez del ecosistema es el quinto eje y el primero que exige juicio en lugar de medición. Su indicador más honesto no es una cifra de rendimiento sino de adopción: Yjs ronda las 920 mil descargas semanales y las 17 mil estrellas, y está detrás de Notion, Jupyter, Tiptap y BlockNote. Automerge se mueve en torno a las 85 mil descargas semanales y arrastra raíces académicas que se notan en la calidad de su documentación conceptual. Loro anda por las 12 mil y es el más joven en ecosistema. Lo que estas cifras miden no es calidad técnica —esa está en los cuatro ejes anteriores— sino cuánta gente resolvió antes que tú los problemas que vas a tener: los enlaces con editores, los proveedores de red, los adaptadores de persistencia, las respuestas a las preguntas que aún no sabes que vas a hacer.

Merece la pena nombrar el sesgo que este eje introduce, porque es real y va en las dos direcciones. Sobrevalorarlo lleva a elegir siempre lo más popular y a heredar decisiones de diseño que no encajan con tu problema. Infravalorarlo lleva a escribir tú mismo, en el peor momento posible, el adaptador que la opción popular ya tenía. La postura defendible es tratarlo como lo que es: no un eje de calidad, sino una estimación del volumen de código que no tendrás que escribir, con la incertidumbre que corresponde a toda estimación.

Hay además un componente de este eje que se confunde con la popularidad y no lo es: el riesgo de continuidad. Una librería con un ecosistema amplio tiene más gente con incentivos para mantenerla viva, más forks posibles y más probabilidad de que alguien arregle un fallo que a ti te bloquea. Una joven puede ser técnicamente superior y a la vez depender de muy pocas manos. Eso no la descarta —Loro gana los benchmarks por algo—, pero es una variable que hay que puntuar aparte del rendimiento y que se paga, si se paga, en el peor momento imaginable.

La forma de tus datos es el sexto eje y es distinto en naturaleza a los otros cinco. Los cinco anteriores puntúan opciones: le das a cada librería un número y las ordenas. Este no puntúa nada. Lo que hace es decidir qué comparación estás obligado a hacer, porque si editas texto largo de forma colaborativa, si manejas documentos estructurados con historia o si lo tuyo son registros de base de datos, las tres situaciones no ordenan igual los cinco ejes anteriores ni conceden el mismo valor a las mismas propiedades. Es el tema entero de la tercera lección de este nivel.

Aplicar el orden sin convertirlo en un ritual

El resumen operativo del orden cabe en una tabla que no contiene ni una sola cifra, y precisamente por eso no caduca: lo que ordena no es el rendimiento de nadie, sino lo que cuesta rectificar.

El orden no dice que un eje inferior nunca pueda desempatar a uno superior; dice que solo puede hacerlo cuando el superior no discrimina. Si dos candidatas quedan a diferencia despreciable en disco, el segundo eje decide y el primero calla. Si una de ellas ocupa varias veces más que la otra en un escenario que se parece al tuyo, ninguna ventaja en peso de módulo compensa eso, porque el módulo se paga una vez y el disco se paga en cada documento, cada dispositivo y cada sincronización durante toda la vida del producto.

Un patrón de decisión que funciona bien en la práctica es el descarte secuencial con umbral declarado. Consiste en fijar de antemano, para cada eje, qué diferencia consideras significativa —por ejemplo, un factor de dos en disco o de tres en memoria— y recorrer los ejes en orden eliminando candidatos solo cuando la diferencia supera el umbral. El valor del método no está en el resultado sino en que obliga a escribir los umbrales antes de ver los números, que es la única forma conocida de no ajustarlos a posteriori para justificar la opción que ya te gustaba.

Hay además un error de método que conviene desactivar de entrada: sumar los ejes en una puntuación única. Es tentador porque produce un ganador y evita la conversación difícil, y es incorrecto porque los ejes no son conmensurables. Un megabyte de disco y un megabyte de módulo no son la misma cantidad de nada. Una tabla comparativa sirve para eliminar candidatos por eje, empezando por el primero, no para calcular una nota media que oculta precisamente el juicio que la decisión requería.