Introducción a la compresión de datos en la web

Accept-Encoding

Cuando el cliente solicita un recurso web al servidor, puede indicarle qué formatos de compresión desea utilizar. Esto lo hace a través de la cabecera Accept-Encoding (RFC 7231, sección 5.3.4), indicando los algoritmos de compresión que acepta. Ejemplo:

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate

En este caso el cliente indica al servidor que acepta los métodos de compresión gzip y deflate. El orden es importante ya que indica la preferencia del cliente (gzip sería la primera opción a utilizar y deflate la segunda).

Para controlar la preferencia también puede utilizarse el modificador ;q=, indicando un valor cualitativo (q-value). Esto expresa la prioridad en unidades "weight" que van desde 0 hasta 1. Ejemplo:

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: deflate;q=0.8, gzip;q=1.0

En este caso, a pesar de que gzip se encuentra segundo en la lista, sería el primero en cuanto a prioridad.

Content-Encoding

Tras la petición, llega la respuesta. En este caso el servidor es quién decide el método de compresión a utilizar. Realmente, el servidor puede hacer lo que le plazca, pero lo normal sería respetar los deseos del cliente y utilizar el algorimo de compresión con mayor prioridad especificado por el cliente. En el ejemplo anterior sería gzip. Si gzip no estuviera disponible se utilizaría deflate, y así sucesivamente. Si ninguno estuviera disponible, el servidor no debería comprimir el contenido.

Aparte de comprimir el cuerpo de la respuesta, el servidor añade la cabecera Content-Encoding (RFC 7231, sección 3.1.2.2) en la que especifica el algoritmo de compresión que finalmente se ha utilizado. Ejemplo:

HTTP/1.1 200 OK
Content-Length: 309
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

deflate

El caso de deflate es curioso a la vez que confuso. Está definido como:

Vamos por partes para intentar entenderlo mejor.

Resulta que según el RFC 2616, deflate equivale al formato zlib, comprimiendo el cuerpo utilizando el algortimo deflate (es decir, ningún otro algoritmo puede ser utilizado).

¿Confuso verdad? Resulta que deflate es tanto un formato como un algoritmo utilizado dentro de ese formato.

Esto llevó a la confusión también a los ingenieros de Microsoft que implementaron el formato, por lo que durante años los navegadores no sabían si deflate se refería al formato o al algoritmo de compresión, por lo que funcionaban por descarte: si no era uno, era otro.

Esta ambigüedad a la hora de definir el formato zlib/deflate provocó que el formato gzip se extendiera rápidamente y se acabase convirtiendo en el rey de la compresión web.

Para entenderlo mejor, veamos la implementación en Node.js de la librería zlib.

Resulta que tenemos estos dos métodos:

• zlib.Deflate: Compress data using deflate.
• zlib.DeflateRaw: Compress data using deflate, and do not append a zlib header.

Ya lo habrás adivinado, pero el método zlib.Deflate se refiere al formato deflate (incluyendo la cabecera y la suma de verificación), mientras que el método zlib.DeflateRaw se refiere al algoritmo de compresión en sí, sin ninguna cabecera ni envoltorio de ningún tipo.

zlib.deflateSync('foo')

<Buffer 78 9c 4b cb cf 07 00 02 82 01 45>

zlib.deflateRawSync('foo')

<Buffer 4b cb cf 07 00>

gzip

Basado en el algoritmo deflate, gzip es un formato abierto que comprime el mensaje utilizando el algoritmo LZ77 y añade, al igual que el formato zlib, una cabecera y una suma de verificación, aunque ésta en formato CRC-32.

La cabecera del formato gzip contiene más bytes de los que contiene el formato zlib (en total 12 bytes más). Además, la suma de verificación utilizando CRC-32 es más lenta de generar que mediante Adler-32, pero estas desventajas apenas son perceptibles con la potencia de los dispositivos de hoy en día. Ésto, sumado a que evitaremos la confusión del formato/algoritmo deflate, ha convertido a gzip en la opción ideal para adoptar cuando hablamos de compresión web.

Brotli

Brotli es un formato de compresión creado por Google en 2015 para comprimir fuentes para la web en formato WOFF, pero rápidamente encontró su sitio en el campo de la compresión web por sus ventajas. Utiliza un algoritmo de compresión propio, basado en LZ77.

Su compatibilidad en navegadores es actualmente del 62%, más que suficiente teniendo en cuenta que si Brotli no estuviera disponible se utilizaría el siguiente de la lista.

En las cabeceras HTTP Accept-Encoding y Concent-Encoding debe especificarse con el valor br.

En cuanto a las ventajas frente a gzip, promete en torno a un 20% extra de compresión siendo prácticamente igual de rápido en compresión/descompresión.

* (asterisco)

Cuando se utiliza el valor * se está indicando al servidor que se acepta compresión de datos pero no se especifica ninguna preferencia en cuanto al formato.

Éste es el valor por defecto cuando omitimos la cabecera Accept-Encoding.

identity

La función de identity es la de indicar de manera explícita al servidor que no se desea ninguna compresión.

compress

Este formato basado en el algoritmo LZW cayó en desuso debido a problemas de patentes y apenas quedan navegadores que lo soporten.

Zstandard

Facebook posee un proyecto open source llamado Zstandard (zstd), que promete mejores resultados que Brotli, tanto en compresión como en velocidad. Desgraciadamente, por el momento no cuenta con soporte en ningún navegador así que el uso de este formato no es realmente válido en compresión web. Aún así, se merece una mención.