Minificar JSON

La manera rápida de reducir JSON es quitar todos los espacios y saltos de línea. También es la equivocada, porque el espacio dentro de una cadena forma parte del dato: un `"Nombre y apellidos"` se convierte en `"Nombreyapellidos"`, y como el resultado sigue siendo JSON válido nadie lo nota hasta mucho después.

Aquí el documento se lee con el analizador incorporado y se vuelve a escribir. Lo que sale es por tanto la misma estructura de datos garantizada: no existe una entrada para la que la reducción cambie el contenido, porque en ningún momento se trata el texto como texto.

El ahorro que se muestra está en bytes UTF-8, que es la cifra que cuenta: una tilde ocupa dos bytes, un emoji cuatro, un carácter chino tres. Un documento con texto en castellano es en bytes bastante mayor de lo que sugiere su número de caracteres.

Quien mida el ahorro en caracteres obtiene casi la misma cifra con un payload de puro ASCII y una que se desvía un tercio con uno lleno de texto en escritura no latina. Como aquí siempre se trata de un canal o de un campo de almacenamiento, y ambos cuentan bytes, se calcula en bytes.

Casi cualquier API responde comprimida, y Gzip es extraordinariamente bueno contra el espacio repetido: cuatro espacios al principio de una línea, mil veces, no cuestan casi nada después de comprimir. El ahorro en el canal es por tanto mucho menor de lo que sugiere la cifra de aquí, a menudo un porcentaje de un solo dígito.

Donde sí compensa es allí donde no se comprime nada: en una variable de entorno, en un campo de base de datos con límite de longitud, en un registro, en un mensaje encolado con un tope de tamaño. Ahí el número de bytes en bruto es la frontera, y ahí la diferencia es real.

Los objetos JSON no tienen un orden definido, así que dos servicios pueden devolver los mismos datos en distinto orden. Una comparación de textos señala entonces una diferencia donde no la hay — el motivo habitual de que un test de contrato se ponga en rojo aunque ambas partes digan lo mismo.

Minificar los dos documentos con las claves ordenadas produce una forma en la que una comparación literal da la respuesta correcta. El mismo procedimiento está detrás de las claves de caché y de las firmas sobre JSON: lo que se hashea necesita una forma canónica, o el hash depende del humor del serializador.

Para firmas existe una especificación de verdad, el RFC 8785, y regula más que el orden: cómo se escriben los números, cómo se escapan los caracteres especiales y cómo se ordena — por unidades de código UTF-16 y no por lo que un idioma considere alfabético.

El orden de aquí es la variante práctica para comparaciones y diffs, no la normativa para firmas criptográficas. Para un diff basta de sobra; quien firme JSON debería leer la especificación, porque ahí la diferencia la marcan justo los detalles que en el día a día no le llaman la atención a nadie.

JSON escribe los números como texto y JavaScript los lee como coma flotante de doble precisión. Los enteros por encima de 9.007.199.254.740.991 pierden cifras: un identificador de 19 dígitos sale distinto, y como el resultado sigue pareciendo un número válido no lo nota nadie.

Afecta a cualquier procesamiento que pase por un analizador de JavaScript, este incluido. El disparador habitual son los identificadores tipo snowflake y algunas secuencias de base de datos. La solución está en quien los genera: esos valores deben viajar como cadena, y entonces atraviesan cualquier etapa sin cambiar.

JSON minificado dentro de un fichero versionado convierte cualquier cambio en una línea modificada. El diff pasa a ser todo o nada, la revisión se vuelve imposible y un conflicto de fusión afecta al documento entero en lugar de a los dos campos de los que iba.

El reparto que funciona: formateado en el repositorio, minificado al servir. La página de formatear hace el camino de vuelta, y entre las dos está exactamente el paso que un proceso de compilación debería dar solo.

La salida de aquí termina sin salto de línea, porque es una línea y no un archivo. Quien la escriba en un fichero debería añadir uno: POSIX define una línea de texto como algo que termina en un salto, y las herramientas, de `cat` a Git, se comportan de forma rara con los archivos que no lo tienen.

Se vuelve relevante al comparar sumas de verificación. El hash de un archivo con salto final difiere por completo del de uno sin él aunque ambos contengan el mismo JSON — una de las razones por las que dos valores que deberían coincidir no coinciden.

Un payload JSON contiene con frecuencia justo lo que no conviene mover: registros de clientes, datos de pedidos, un webhook con direcciones dentro. Como aquí se analiza y se escribe en la propia página, no hay comunicación a nosotros ni encargo de tratamiento sobre ese contenido.

Se demuestra en el panel de red: mientras la usas no sale ninguna petición que lleve tu documento. Es la razón por la que esta herramienta se puede usar donde una versión con servidor chocaría con una política interna, y comprobarlo cuesta un minuto.