Comprimir web en Nginx: Gzip y Brotli paso a paso

📅 Publicado el 27 de octubre, 2026 · Por Equipo RedServicio

Configurar gzip y Brotli en Nginx es, probablemente, la mejora más rentable que le puedes hacer a tu servidor web: con un par de directivas reduces el peso de tus páginas entre un 60% y un 80%, ganas velocidad de carga y, de paso, tu SEO se beneficia. Sin tocar una línea de código de la aplicación. Aquí vamos a ver cómo activar ambos compresores en Nginx, en qué se diferencian y qué configuración usamos nosotros en producción.

¿Por qué comprimir tu web? Beneficios de Gzip y Brotli

Pensemos en lo que pasa cuando alguien pide una página. El servidor envía el HTML, el CSS y el JavaScript tal cual están. Sin compresión, un CSS de 250 KB ocupa 250 KB de transferencia. Con compresión, quizá 40-60 KB. La diferencia, multiplicada por miles de visitas, se nota:

• Menor tiempo de carga: menos bytes viajando por la red. En móvil, donde las conexiones suelen ser peores, se nota todavía más.
• Mejor SEO: Google usa los Core Web Vitals (el LCP, por ejemplo) como factor de posicionamiento, y la compresión influye directamente en ellos.
• Ahorro de ancho de banda: menos tráfico saliente del servidor. Menos costes de transferencia a final de mes.
• Mejor experiencia de usuario: los estudios de Google llevan años mostrando que cada segundo extra de carga dispara la tasa de rebote.

Y lo mejor: comprimir texto (HTML, CSS, JS, JSON, SVG) apenas consume CPU en un servidor moderno, así que la relación coste-beneficio es difícil de mejorar. Ojo con las imágenes y vídeos, eso sí. Los formatos que ya vienen comprimidos de fábrica (JPG, WebP, vídeo) no se recomprimen: no ganarían casi nada y solo malgastarías ciclos de CPU.

Gzip vs Brotli: ¿cuál deberías usar?

Los dos son algoritmos de compresión sin pérdida, pero no son iguales. Las diferencias que importan:

• Gzip: compatible con el 100% de los navegadores. Lleva décadas siendo el estándar. Comprime bien, sin más.
• Brotli: lo desarrolló Google y consigue entre un 15% y un 25% más de compresión que Gzip a máximo nivel. Todos los navegadores modernos lo soportan (Chrome, Firefox, Edge, Safari desde 2017), aunque siempre sobre HTTPS.
• CPU: Brotli a niveles altos (10-11) es caro en CPU. Por eso tiene más sentido la compresión estática: comprimes una vez, al desplegar. Gzip a nivel 6 es rápido incluso comprimiendo al vuelo.

¿Mi recomendación? Usa los dos. Sirve Brotli a los navegadores que lo pidan en la cabecera Accept-Encoding y deja Gzip como respaldo universal. Nginx negocia el algoritmo solo, según lo que soporte cada cliente. Y si tu hosting se encarga de esto, como pasa en los planes de RedServicio.net con soporte 24/7, ya tendrás ambas compresiones activas de serie.

Cómo configurar gzip y Brotli en Nginx paso a paso

Antes de editar nada, conviene saber si tu Nginx ya comprime y con qué módulos cuenta. Toma nota:

1. Verifica la respuesta del servidor con curl -I -H «Accept-Encoding: gzip, br» https://tudominio.com y busca la cabecera Content-Encoding.
2. Comprueba los módulos compilados con nginx -V. Busca http_gzip_module (viene de serie) y el módulo de Brotli, que casi siempre requiere instalación aparte.
3. Si no tienes Brotli, instálalo desde los paquetes de tu distribución o compílalo como módulo dinámico: en Ubuntu/Debian, sudo apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static.
4. Edita tu configuración (por ejemplo /etc/nginx/nginx.conf o el bloque server de tu sitio) y añade las directivas de compresión, que detallamos más abajo.
5. Recarga Nginx con sudo nginx -t && sudo systemctl reload nginx y vuelve a mirar la cabecera Content-Encoding.

Con esto ya tienes el terreno preparado. En la siguiente parte entramos en las directivas concretas de gzip y Brotli, con ejemplos listos para copiar y ajustar a tu proyecto.

Verificar que la compresión funciona correctamente

Una vez aplicada la configuración de gzip y Brotli en Nginx, falta lo más importante: comprobar que la compresión se está sirviendo de verdad. No basta con guardar el archivo y rezar. Lo más rápido es usar curl desde la terminal, indicando que el cliente acepta contenido comprimido:

Si todo va bien, verás en la respuesta la cabecera content-encoding: br (Brotli tiene prioridad) o content-encoding: gzip. ¿No aparece ninguna de las dos? Entonces revisa que el módulo correspondiente esté cargado y que el tipo MIME del recurso figure en gzip_types o brotli_types.

También puedes mirarlo desde el navegador. Abre las herramientas de desarrollo (F12), ve a la pestaña Network, recarga y selecciona un recurso cualquiera. En Response Headers está la cabecera de codificación; y junto al tamaño de transferencia verás el tamaño descomprimido, así que calcular el ahorro real es cuestión de restar.

Para un análisis más completo, herramientas online como GTmetrix, PageSpeed Insights o WebPageTest te dicen qué recursos están comprimidos y cuáles no, además de mostrar el impacto en el tiempo de carga. Como objetivo razonable: reducir entre un 60% y un 80% el peso de los archivos HTML, CSS y JavaScript.

Comprobar el nivel de compresión

¿Cuánto comprime cada nivel? Puedes medirlo con este comando:

Repítelo ajustando brotli_comp_level en tu configuración hasta dar con el equilibrio entre tamaño final y consumo de CPU en tu servidor. Ese punto dulce varía según el hardware, así que no te fíes de lo que funciona en otra máquina.

Errores comunes al comprimir en Nginx y cómo evitarlos

Aunque la configuración sea correcta, hay fallos frecuentes que impiden que la compresión funcione como esperas. Estos son los que más me suelo encontrar:

• No incluir los tipos MIME correctos. Si sirves fuentes WOFF2 o JSON de API y no están en gzip_types, se enviarán sin comprimir. Ojo con esto: text/html siempre se comprime por defecto y no debe listarse.
• Comprimir contenido ya comprimido. Formatos como PNG, JPG, WebP o vídeos ganan poco o nada al recomprimirse, y solo consumen CPU. Exclúyelos de las directivas de compresión.
• Niveles demasiado altos en gzip. Poner gzip_comp_level 9 para peticiones dinámicas dispara el uso de CPU sin apenas beneficio frente al nivel 5. Los niveles altos (10-11) resérvalos para Brotli con ficheros estáticos precomprimidos.
• Conflicto entre gzip y brotli activados. Nginx no sirve ambos a la vez: usa el módulo que cargues en el bloque http con prioridad. Si los dos están activos, el orden de carga determina cuál se aplica; verifica la cabecera para confirmar el resultado.
• Cabeceras intermedias o CDN. Un proxy o CDN puede eliminar la compresión de origen o renegociarla. Si usas Cloudflare o similar, revisa su configuración de compresión para no duplicar esfuerzos.
• No regenerar los ficheros .br estáticos. Con brotli_static on, si olvidas regenerar los ficheros tras cada despliegue acabarás sirviendo versiones antiguas comprimidas. Pasa más de lo que parece.

Y cuando algo falle, mira el log de errores de Nginx con sudo tail -f /var/log/nginx/error.log mientras lanzas una petición de prueba. Casi siempre ahí aparece la pista exacta del problema.

Conclusión: una web más rápida con la compresión adecuada

Activar gzip y Brotli en Nginx es de las optimizaciones con mejor relación esfuerzo-resultado que puedes aplicar a tu web. Con unas pocas directivas bien configuradas reduces el peso de tus recursos entre un 60% y un 80%, mejoras el tiempo de carga, gastas menos ancho de banda y envías señales positivas a Google para el posicionamiento.

Las claves, resumidas: habilita gzip como base universal con nivel 5-6, usa Brotli para los navegadores modernos, precomprime los ficheros estáticos cuando puedas, comprime solo los formatos que lo aprovechan y verifica siempre el resultado con las cabeceras HTTP.

Un último consejo. La compresión rinde mucho mejor sobre una infraestructura cuidada. En RedServicio nuestros planes de hosting incluyen servidores optimizados con Nginx, soporte 24/7 y ayuda para configurar gzip y Brotli en tu proyecto si lo necesitas. Buena compresión más un hosting de calidad: tu web cargará más rápido que la de tu competencia.