¿Qué son la compresión Gzip y Brotli?

Gzip y Brotli son algoritmos de compresión que tu servidor web utiliza para reducir el tamaño de los archivos antes de enviarlos al navegador del visitante. La idea es sencilla: los archivos basados en texto, como HTML, CSS y JavaScript, contienen muchos patrones repetitivos, y los algoritmos de compresión son muy buenos encontrando y eliminando esa redundancia. Un archivo HTML de 100 KB puede comprimirse hasta 15-20 KB. El navegador lo descomprime al instante y el visitante no nota nada salvo una carga más rápida.

Si alguna vez has comprimido una carpeta en tu ordenador, ya entiendes el concepto básico. La compresión web funciona igual, solo que de forma automática y transparente. El servidor comprime la respuesta, el navegador la descomprime y ni el desarrollador ni el visitante necesitan hacer nada especial (suponiendo que el servidor esté configurado correctamente).

Cómo funciona la compresión web a nivel de protocolo

Cada vez que un navegador envía una petición HTTP, incluye una cabecera Accept-Encoding que indica al servidor qué algoritmos de compresión soporta:

Accept-Encoding: gzip, deflate, br

Esta cabecera dice que el navegador puede manejar Gzip, Deflate y Brotli (abreviado como br). El servidor elige el mejor algoritmo que soporta, comprime el cuerpo de la respuesta y añade una cabecera Content-Encoding para indicar al navegador qué algoritmo se utilizó:

Content-Encoding: gzip

o:

Content-Encoding: br

El navegador lee esta cabecera, aplica el algoritmo de descompresión correspondiente y renderiza el contenido. Si el servidor no admite compresión (o no está configurada), envía la respuesta sin comprimir y no hay cabecera Content-Encoding presente.

Esta negociación ocurre en cada petición. El servidor puede elegir métodos de compresión distintos para distintos tipos de archivo, o incluso servir contenido sin comprimir para los archivos que no se benefician de la compresión.

Gzip: el estándar consolidado

Gzip ha sido el caballo de batalla de la compresión web desde finales de los 90. Se basa en el algoritmo DEFLATE (una combinación de LZ77 y codificación Huffman) y está soportado, literalmente, por todos los navegadores y servidores web en uso hoy. Cuando se habla de "activar la compresión" en un servidor web, normalmente se refieren a Gzip.

Gzip funciona con niveles de compresión configurables, normalmente del 1 (más rápido, menos compresión) al 9 (más lento, mejor compresión). La mayoría de servidores web utilizan por defecto el nivel 6, que ofrece un buen equilibrio entre ratio de compresión y uso de CPU. En el nivel 6, Gzip suele lograr un 70-85 % de compresión en archivos de texto. Es decir, un archivo CSS de 100 KB pasa a unos 15-30 KB.

Las principales ventajas de Gzip son su universalidad (funciona en todas partes), su velocidad en niveles de compresión moderados y las décadas de optimización que han pulido sus implementaciones. La principal desventaja es que no comprime tan bien como Brotli, sobre todo en archivos pequeños.

Brotli: la alternativa moderna

Brotli fue desarrollado por Google y publicado como RFC 7932 en 2016. Se diseñó específicamente para contenido web y consigue ratios de compresión un 15-25 % mejores que Gzip en activos web típicos. Brotli lo logra utilizando un algoritmo de compresión más sofisticado e incluyendo un diccionario integrado de cadenas comunes en el contenido web (etiquetas HTML, propiedades CSS, palabras clave de JavaScript, etc.).

Brotli también utiliza niveles de compresión configurables, del 0 al 11. A niveles de calidad comparables, Brotli produce una salida más pequeña que Gzip, pero en los niveles más altos (10-11) es significativamente más lento al comprimir. Esto hace que la compresión Brotli en niveles altos sea ideal para activos estáticos que se pueden precomprimir una vez y servir muchas veces, pero menos adecuada para contenido dinámico que debe comprimirse en cada petición.

Una limitación importante: Brotli solo funciona sobre HTTPS. Los navegadores no aceptan respuestas comprimidas con Brotli en conexiones HTTP planas. Como la mayoría de sitios WordPress deberían estar en HTTPS de todos modos (y HTTP/2 lo requiere), rara vez es un problema práctico.

Gzip vs. Brotli: comparación práctica

Así se comparan ambos algoritmos en los aspectos relevantes para los propietarios de sitios WordPress:

• Ratio de compresión: Brotli suele producir archivos un 15-25 % más pequeños que Gzip a niveles de compresión comparables. En un sitio WordPress que carga 500 KB de activos comprimibles, esa diferencia se traduce en unos 15-30 KB menos transferidos por carga.
• Velocidad de compresión: Gzip en nivel 6 es más rápido que Brotli en una calidad equivalente. Para contenido dinámico (páginas HTML generadas por PHP), Gzip suele ser la opción más práctica porque la compresión ocurre en cada petición. Brotli en niveles 1-4 es comparable en velocidad a Gzip y aun así comprime algo mejor.
• Velocidad de descompresión: Brotli descomprime ligeramente más rápido que Gzip, lo que significa que el navegador puede procesar el contenido un poco antes. La diferencia es pequeña pero consistente.
• Compatibilidad de navegadores: todos los navegadores modernos soportan Gzip y Brotli. Internet Explorer (ya descontinuado) no soportaba Brotli, pero Edge, Chrome, Firefox y Safari sí. La compatibilidad global con Brotli supera el 96 %.
• Soporte en servidores: Apache soporta Brotli mediante mod_brotli (disponible desde Apache 2.4.26). Nginx lo soporta mediante el módulo ngx_brotli (un módulo de terceros que hay que compilar por separado). LiteSpeed tiene soporte Brotli integrado. La mayoría de los proveedores de hosting gestionado y CDNs admiten ambos.
• Requisito de HTTPS: Brotli requiere HTTPS. Gzip funciona tanto sobre HTTP como sobre HTTPS.

En la práctica, muchos servidores se configuran para preferir Brotli cuando el navegador lo soporta y volver a Gzip en caso contrario. Así obtienes la mejor compresión para los navegadores modernos manteniendo la compatibilidad con clientes más antiguos.

Cómo activar la compresión en Apache

En Apache, activas la compresión Gzip mediante mod_deflate (un nombre confuso, pero usa Gzip y no Deflate puro). Añade lo siguiente a tu archivo .htaccess:

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

Para Brotli en Apache, necesitas mod_brotli:

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

Cómo activar la compresión en Nginx

En Nginx, Gzip está integrado y solo hay que activarlo en la configuración:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Para Brotli en Nginx, tras instalar el módulo ngx_brotli:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Plugins de caché de WordPress y compresión

Si no tienes acceso a la configuración de tu servidor (algo común en hosting compartido), varios plugins de caché de WordPress pueden gestionar la compresión por ti:

• WP Rocket: activa la compresión Gzip automáticamente añadiendo reglas a tu archivo .htaccess. También crea archivos HTML de caché estáticos precomprimidos.
• W3 Total Cache: ofrece la compresión Gzip como opción configurable en sus ajustes de caché del navegador. También puede servir archivos precomprimidos.
• LiteSpeed Cache: si tu hosting usa servidor LiteSpeed, este plugin activa automáticamente la compresión Gzip y Brotli.
• WP Super Cache: incluye una opción de compresión Gzip que comprime las páginas en caché.
• Autoptimize: aunque es principalmente un plugin de optimización de CSS/JS, también puede servir versiones comprimidas de los archivos que genera.

Ten en cuenta que si tu servidor ya gestiona la compresión a nivel de servidor, activarla otra vez mediante un plugin es innecesario y a veces puede provocar conflictos (doble compresión, que los navegadores no pueden descomprimir).

Qué tipos de archivo se benefician más de la compresión

La compresión funciona mejor en contenido basado en texto y repetitivo. Aquí tienes un desglose por tipo de archivo:

• HTML: comprime extremadamente bien (reducción del 70-90 %). Las páginas HTML generadas por WordPress están llenas de estructuras de etiquetas, nombres de clase y espacios en blanco repetitivos.
• CSS: comprime muy bien (reducción del 80-90 %). Las hojas de estilo contienen muchos nombres de propiedades y selectores repetidos.
• JavaScript: comprime muy bien (reducción del 70-85 %). Los archivos JS tienen palabras clave, nombres de funciones y patrones estructurales repetidos.
• SVG: comprime extremadamente bien (reducción del 80-95 %). Los SVGs son XML y muy repetitivos.
• JSON: comprime muy bien (reducción del 75-90 %). Las respuestas de API y los datos de configuración se benefician mucho.
• XML y feeds RSS: comprimen muy bien debido a su estructura de etiquetas repetitiva.
• Fuentes web (WOFF/WOFF2): las fuentes WOFF2 ya incluyen internamente compresión Brotli, por lo que la compresión adicional en el servidor aporta un beneficio mínimo. Las fuentes WOFF incluyen una compresión más ligera y pueden beneficiarse algo de Gzip.

Qué NO se debe comprimir

No todos los tipos de archivo se benefician de la compresión, y algunos deberían excluirse activamente:

• Imágenes JPEG, PNG, WebP, AVIF: estos formatos ya están comprimidos. Pasarlos por Gzip o Brotli desperdicia tiempo de CPU e incluso puede aumentar ligeramente el tamaño del archivo.
• Archivos de vídeo (MP4, WebM): ya están comprimidos con códecs muy eficientes. La compresión en el servidor añade sobrecarga sin ningún beneficio.
• Archivos de audio (MP3, AAC, OGG): igual que el vídeo, ya están comprimidos.
• ZIP, GZIP y otros archivos comprimidos: ya están comprimidos por definición.
• Archivos PDF: la mayoría de los PDF utilizan compresión interna. La compresión adicional aporta un ahorro insignificante.

Comprimir archivos ya comprimidos desperdicia CPU del servidor en cada petición y puede incluso producir una salida ligeramente mayor. La mayoría de configuraciones de servidor web y plugins de caché de WordPress limitan correctamente la compresión a tipos MIME basados en texto, pero conviene verificar tu configuración para asegurarte de que los archivos binarios queden excluidos.

Qué comprueba InspectWP

InspectWP examina la cabecera de respuesta Content-Encoding que devuelve tu sitio WordPress para determinar si la compresión está activa. Concretamente busca gzip, br (Brotli) o deflate en el valor de la cabecera. Si no se detecta compresión, el informe lo marca como un problema de rendimiento y recomienda activar la compresión Gzip o Brotli. El método de compresión detectado se muestra en la sección de rendimiento del informe, dándote una visión clara de si tu servidor está correctamente configurado para reducir los tamaños de transferencia.