Gzip y Brotli en Nginx son las dos tecnologías de compresión que todo administrador de servidores debería dominar si quiere acelerar sus sitios web. Comprimir las respuestas HTTP reduce el peso de HTML, CSS, JavaScript y JSON entre un 60 y un 80 por ciento. Eso se traduce en cargas más rápidas, mejor puntuación en Core Web Vitals y menos consumo de ancho de banda. En esta guía verás cómo comprobar si tu servidor ya comprime, cómo habilitar Gzip con una configuración sólida y cómo preparar el terreno para Brotli, con ejemplos listos para aplicar.
¿Qué son Gzip y Brotli y por qué comprimir tu web?
Gzip es el estándar histórico de compresión HTTP, soportado por todos los navegadores desde hace décadas y basado en el algoritmo DEFLATE. Brotli, desarrollado por Google, es su sucesor moderno: alcanza ratios de compresión entre un 15 y un 25 por ciento mejores que Gzip con el mismo nivel de CPU, sobre todo en textos grandes como HTML y JavaScript. El detalle es que Brotli solo funciona sobre HTTPS y su compresión máxima es más cara en CPU, así que en la práctica suele convivir con Gzip como alternativa según el cliente.
Los beneficios prácticos de comprimir son inmediatos:
- Menor tiempo de carga: un archivo JavaScript de 500 KB puede quedar en unos 130 KB comprimido.
- Mejor SEO: Google utiliza la velocidad de carga como señal de posicionamiento.
- Ahorro de ancho de banda: relevante en servidores con tráfico alto o planes con límite de transferencia.
- Mejor experiencia móvil: en redes 4G lentas, la compresión marca una diferencia enorme.
La cosa es simple: la compresión es una de las optimizaciones con mejor relación esfuerzo-beneficio que existen. Unos minutos de configuración aportan mejoras visibles sin tocar una línea de código de tu aplicación.
Verificar si tu servidor Nginx ya comprime las respuestas
Antes de tocar la configuración, conviene saber qué está haciendo tu servidor ahora mismo. Tienes varias formas de comprobarlo.
Comprobación con curl
El método más directo es usar curl desde la terminal, solicitando explícitamente compresión y observando las cabeceras de respuesta:
curl -I -H «Accept-Encoding: gzip, br» https://tudominio.com
Si la compresión está activa, verás una cabecera Content-Encoding: gzip o Content-Encoding: br. Si no aparece, tu servidor está enviando las respuestas sin comprimir. Tal cual.
Comprobación con herramientas online
Servicios como Gift of Speed o la pestaña Network de las DevTools de Chrome (clic derecho sobre la petición, opción «Copy as cURL») también te permiten ver el valor de Content-Encoding. Fíjate en la columna Size de las DevTools: si muestra dos valores (por ejemplo, «1.2 MB / 350 KB»), el segundo es el tamaño transferido ya comprimido.
Comprobación en la configuración
Revisa también el estado del módulo y su configuración actual:
- nginx -V 2>&1 | tr — – ‘\n’ | grep gzip para confirmar que el módulo http_gzip está compilado (viene incluido por defecto).
- Busca directivas gzip en /etc/nginx/nginx.conf y en los archivos de /etc/nginx/conf.d/ y /etc/nginx/sites-enabled/.
- Comprueba si existe el paquete ngx_brotli con nginx -V 2>&1 | grep -o with-brotli.
Con este diagnóstico claro, sabrás exactamente desde qué punto partes antes de editar nada.
Cómo habilitar Gzip en Nginx: configuración completa
Habilitar Gzip en Nginx es muy sencillo porque el módulo viene incluido por defecto. Edita tu bloque http (normalmente en /etc/nginx/nginx.conf) o el archivo de configuración del sitio y añade:
- gzip on; activa la compresión.
- gzip_vary on; añade la cabecera Vary: Accept-Encoding, imprescindible para cachés y proxys.
- gzip_comp_level 5; nivel de compresión; 5 ofrece el mejor equilibrio entre CPU y tamaño (el rango va de 1 a 9).
- gzip_min_length 256; no comprime respuestas menores de 256 bytes, donde el ahorro no compensa.
- gzip_proxied any; comprime también respuestas de proxied requests.
- gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml; define los tipos MIME comprimidos.
Un detalle importante: no necesitas incluir text/html en gzip_types porque Nginx siempre lo comprime cuando gzip está activo. Y evita comprimir formatos que ya vienen comprimidos de fábrica (imágenes JPEG, WebP, vídeos, PDF o WOFF2); solo desperdiciarías CPU.
Tras guardar los cambios, valida la sintaxis y recarga el servicio:
nginx -t && systemctl reload nginx
Vuelve a lanzar el comando curl de verificación y deberías ver Content-Encoding: gzip en la respuesta. Si usas WordPress, esta configuración por sí sola puede reducir el peso de tus páginas a menos de un tercio del original.
Cómo habilitar Brotli en Nginx: instalación del módulo y configuración
Brotli comprime entre un 15 y un 25 por ciento mejor que Gzip gastando más o menos la misma CPU. El problema: Nginx no lo trae de serie. La salida más rápida es instalar dos paquetes desde el repositorio oficial de Nginx, libnginx-mod-http-brotli-filter y libnginx-mod-http-brotli-static:
- Ubuntu/Debian: apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static
- CentOS/AlmaLinux (repositorio nginx.org): los paquetes nginx-mod-http-brotli-static y nginx-mod-http-brotli-filter están disponibles en versiones recientes.
- Comprueba que el módulo se cargó con nginx -V 2>&1 | grep brotli. Debería aparecer el flag –with-http_brotli_module o los módulos dinámicos.
¿Compilas Nginx desde el código fuente o usas una versión sin soporte? Entonces toca recurrir al módulo de Google (ngx_brotli) y compilarlo con –add-module. Una vez instalado, añade este bloque en el contexto http de nginx.conf:
- brotli on;
- brotli_comp_level 6;
- brotli_min_length 256;
- brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
- brotli_static on; para servir archivos precomprimidos con extensión .br, ideal combinado con brotli_static del proceso de build.
Para verificar, lanza curl -I -H «Accept-Encoding: br» https://tudominio.com y mira que te llegue content-encoding: br. No hace falta nada más: Nginx negocia solo, así que los navegadores modernos recibirán Brotli y los más veterános, Gzip.
Gzip y Brotli en Nginx: buenas prácticas y errores comunes
No comprimas lo que ya está comprimido
Las imágenes JPG, PNG, WebP, los vídeos o los ZIP ya llevan compresión interna. Volver a comprimirlos solo quema CPU para nada. Exclúyelos de gzip_types y brotli_types.
Evita niveles de compresión extremos
El nivel 9 en Gzip o el 11 en Brotli puede duplicar el tiempo de CPU por petición a cambio de ganancias mínimas. No compensa. Para contenido dinámico, el punto óptimo ronda el nivel 5-6. Con assets estáticos la cosa cambia: precomprímelos en el pipeline de despliegue al nivel máximo y sírvelos con gzip_static o brotli_static.
Cuida la interacción con CDNs y proxys
Si tienes Cloudflare o similar delante, ojo: el CDN ya negocia la compresión por su cuenta. Los errores típicos son comprimir dos veces, o no comprimir ninguna. Pon gzip_proxied any si tu Nginx va detrás de un proxy inverso y comprueba siempre las cabeceras reales con curl.
Caché y Vary
Que las respuestas comprimidas incluyan la cabecera Vary: Accept-Encoding. Si falta, una caché intermedia puede servir contenido Brotli a un navegador que solo entiende Gzip. El resultado: errores de renderizado difíciles de rastrear.
Tip rápido: después de cada cambio, ejecuta nginx -t antes de recargar. Me he encontrado más de un servidor caído por un simple error de sintaxis en nginx.conf que saltó en el siguiente reinicio.
Conclusión: comprimir tu web en Nginx para ganar velocidad
Pocas optimizaciones dan tanto por tan poco. Unas líneas de configuración reducen el peso de HTML, CSS, JavaScript y SVG entre un 60 y un 80 por ciento, y se nota en el Time to First Byte, en los Core Web Vitals y en el SEO. La estrategia que recomiendo es sencilla: Gzip como base universal, Brotli encima para navegadores modernos, assets estáticos precomprimidos y fuera los formatos que ya comprimen por sí solos.
Verifica siempre el resultado con curl, y contrástalo con PageSpeed Insights o WebPageTest para confirmar que content-encoding aparece en las respuestas. ¿Tu sitio va sobre WordPress? Combina esta configuración con caché y un CDN para multiplicar el efecto.
Y si prefieres no tocar el servidor, o te has topado con un error que se resiste, en RedServicio (redservicio.net) encontrarás ayuda profesional de expertos en administración de sistemas y WordPress para dejar tu web funcionando a máxima velocidad.
