Compresión sin pérdida: definición, algoritmos y web

¿Qué es la compresión sin pérdida?

La compresión sin pérdida (lossless) reduce el tamaño de un archivo sin descartar información: al descomprimir se recuperan exactamente los bytes originales. Funciona codificando de forma más compacta los patrones repetidos, así que el texto, el código, el JSON y el HTML se reducen mucho, mientras que los datos ya comprimidos apenas cambian.

La alternativa es la compresión con pérdida, que elimina de forma permanente detalles que el ojo o el oído difícilmente echan de menos (JPEG, MP3, la mayoría del vídeo). Usa la compresión sin pérdida siempre que cada bit importe: código fuente, ejecutables, bases de datos, archivos comprimidos y el HTML, CSS, JavaScript y JSON que sirve tu servidor.

Cómo funciona la compresión sin pérdida

Los algoritmos sin pérdida detectan la redundancia y la eliminan. Dos técnicas hacen la mayor parte del trabajo:

• Codificación por diccionario (familia LZ77): sustituye una cadena repetida por una referencia corta a una copia anterior. gzip, Zstandard y LZ4 se basan en ella.
• Codificación entrópica (Huffman, codificación aritmética): asigna códigos más cortos a los símbolos frecuentes que a los raros. La mayoría de los compresores la usan como paso final.

Brotli combina estas ideas con modelado de contexto y un diccionario integrado. Según MDN, el texto puede tener hasta un 60 % de redundancia, por eso se comprime tan bien.

Algoritmos sin pérdida habituales

Sin pérdida frente a con pérdida

La compresión sin pérdida devuelve el original exacto. La compresión con pérdida devuelve una aproximación y suele lograr tamaños menores. Algunos formatos, como WebP, admiten ambos modos.

Compresión sin pérdida en la web

La compresión HTTP es sin pérdida. El navegador indica en Accept-Encoding lo que admite, el servidor elige una opción, comprime el cuerpo y lo etiqueta en Content-Encoding. La cabecera Vary: Accept-Encoding permite que las cachés y las CDN guarden cada variante por separado.

GET / HTTP/1.1
Accept-Encoding: br, gzip

HTTP/1.1 200 OK
Content-Encoding: br
Vary: Accept-Encoding
Content-Type: text/html

Las codificaciones que encontrarás en la práctica (consulta la guía de compresión de MDN):

Sirve Brotli donde el cliente lo admita y recurre a gzip si no. MDN indica que la compresión puede reducir algunos documentos hasta un 70 %, lo que acorta el tiempo de transferencia y puede mejorar métricas de carga como el LCP (consulta Core Web Vitals). Para configurarlo en el servidor, lee cómo activar gzip en NGINX.

Qué compresor usar

• HTML, CSS, JavaScript y JSON por HTTP: Brotli, con gzip como alternativa. Los archivos estáticos se comprimen una vez en la compilación con un nivel alto. Las respuestas dinámicas necesitan un nivel más bajo y rápido para que el tiempo de CPU no añada latencia.
• Flujos en tiempo real y datos en memoria: LZ4 o Snappy, que cambian relación de compresión por velocidad.
• Archivos a largo plazo: xz o Zstandard con nivel alto, donde la relación importa más que la velocidad.
• Logs y muchos payloads parecidos: Zstandard, opcionalmente con un diccionario compartido.

Errores comunes

• Comprimir archivos ya comprimidos. JPEG, MP4, ZIP y formatos similares no se reducen, y el paso extra gasta CPU y puede aumentar el tamaño.
• Comprimir imágenes con un algoritmo de texto. Sirve las imágenes en un formato de imagen. Consulta tamaño de imagen.
• Olvidar Vary: Accept-Encoding. Sin ella, una caché puede entregar una respuesta comprimida a un cliente que no puede leerla.
• Usar el nivel máximo en cada petición. Los últimos puntos porcentuales de tamaño cuestan mucha CPU. Resérvalo para archivos que comprimes una sola vez.
• Dar por hecho que la compresión está activa. Un ajuste del proxy, la CDN o el origen puede desactivarla sin ningún error visible. Revisa las cabeceras de la respuesta.

Comprobar la compresión con LoadFocus

Un servidor mal configurado puede servir JSON sin comprimir durante meses sin que nadie lo note. La monitorización de API de LoadFocus puede comprobar las cabeceras de la respuesta además del código de estado, el cuerpo y el tiempo de respuesta, de modo que una comprobación falle si falta Content-Encoding, y desglosa el tiempo de respuesta en espera, DNS, conexión TCP, primer byte (TTFB) y descarga. Las comprobaciones gratuitas se ejecutan cada 5 minutos. Una prueba de carga desde 25 regiones informa de percentiles de tiempo de respuesta, latencia y rendimiento bajo carga, y muestra si el coste de CPU de la compresión te perjudica en las horas punta.

Preguntas frecuentes: compresión sin pérdida

¿Cuál es el mejor compresor sin pérdida?

Depende de lo que sacrifiques. xz logra una relación alta pero es lento, Zstandard equilibra velocidad y relación, LZ4 es el más rápido y gzip es el más compatible. Para respuestas web, Brotli con gzip como alternativa.

¿Por qué mi archivo no se reduce?

Probablemente ya no le queda redundancia. JPEG, MP4, los datos cifrados y los archivos ya comprimidos son casi aleatorios para un compresor.

¿Debo comprimir JSON?

Sí. JSON repite mucho los nombres de las claves, así que suele comprimirse bien. Activa gzip o Brotli en las respuestas de tu API y compruébalo en las cabeceras.

¿PNG es sin pérdida?

Sí. PNG y GIF son sin pérdida, JPEG es con pérdida y WebP puede ser ambos. Usa PNG para capturas y logotipos, y JPEG o WebP para fotos.

¿Brotli es mejor que gzip?

Para texto por HTTP, normalmente sí: su README lo describe como similar a deflate en velocidad pero más denso. La compatibilidad es amplia, así que sirve Brotli y deja gzip como alternativa.

¿Debo comprimir antes de cifrar?

Si cifras archivos tú mismo, sí, porque la salida cifrada parece aleatoria y no se comprime. La compresión HTTP se aplica a la respuesta antes de que TLS la cifre.