Cuando trabajamos en aplicaciones web, la transferencia de archivos entre el servidor y el navegador es uno de los puntos donde se puede ganar velocidad con pequeños ajustes. La compresión HTTP es una de esas optimizaciones que tiene un impacto directo en el tiempo de carga. Brotli y Gzip son dos de los algoritmos más comunes para este propósito. Ambos están ampliamente soportados, pero tienen diferencias en cuanto a rendimiento, tamaño final y tiempos de compresión.

Analizaremos cada uno, evaluamos cuándo conviene usar uno u otro y mostramos cómo integrarlos en distintos entornos.

Brotli y Gzip: ¿qué son exactamente?

Brotli y Gzip son algoritmos de compresión sin pérdida. Eso significa que los datos originales pueden ser recuperados sin alteraciones una vez descomprimidos. Ambos fueron diseñados para comprimir texto plano, como HTML, CSS y JavaScript, y son compatibles con la mayoría de los navegadores actuales.

• Gzip fue creado en los 90 y es un estándar de facto para compresión HTTP. Utiliza el algoritmo DEFLATE.
• Brotli, más reciente (Google lo liberó en 2015), ofrece mejores tasas de compresión a costa de mayor tiempo de procesamiento en niveles altos.

Ambos son compatibles con HTTP/1.1 y HTTP/2, y pueden ser utilizados directamente en servidores como Nginx o Apache, así como en herramientas de build modernas (Webpack, esbuild, Vite, etc.).

Comparativa técnica

Tamaño de salida

Brotli logra archivos más pequeños, especialmente en niveles de compresión altos. Esto es más notable en archivos JavaScript y CSS grandes. Veamos un ejemplo a modo de demostración, aunque no es una prueba muy científica servirá para ver claramente las diferencias:

En muchos casos, Brotli reduce entre un 10% y 20% más que Gzip.

Tiempo de compresión

Aquí Gzip suele ser más rápido, sobre todo en niveles de compresión medios y bajos.

• Gzip nivel 6: 120 ms
• Brotli nivel 6: 280 ms

En servidores con alta carga, esa diferencia puede ser relevante si la compresión se hace al vuelo (on-the-fly).

Compatibilidad

Ambos están soportados por la mayoría de los navegadores:

• Brotli: Chrome, Firefox, Edge, Safari, Android WebView
• Gzip: prácticamente universal

Uso en servidores web

Como configurar los principales servidores para que sirvan contenido comprimido con Gzip o Brotli:

Nginx

Para Gzip:

gzip on;
gzip_types text/plain application/javascript text/css;
gzip_min_length 1000;

Para Brotli (requiere módulo extra):

brotli on;
brotli_comp_level 5;
brotli_types text/plain application/javascript text/css;

Apache

# Gzip
AddOutputFilterByType DEFLATE text/html text/css application/javascript

# Brotli
AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript

CDN y proxies

Cloudflare, Fastly y otros proxies modernos ya soportan Brotli. Si usamos alguno de estos servicios, vale la pena verificar que esté activado.

En proyectos front-end

Si trabajamos con herramientas como Webpack, podemos generar archivos comprimidos en build para servirlos precomprimidos desde el servidor.

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [
    new CompressionPlugin({
      algorithm: 'brotliCompress',
      filename: '[path][base].br',
      compressionOptions: { level: 11 },
      test: /\.(js|css|html|svg)$/,
    }),
    new CompressionPlugin({
      algorithm: 'gzip',
      filename: '[path][base].gz',
      test: /\.(js|css|html|svg)$/,
    }),
  ],
};

De esta forma, el servidor puede entregar la versión más adecuada según el encabezado Accept-Encoding del navegador.

¿Cuál conviene usar?

Depende del contexto:

• Si el servidor puede precomprimir los archivos (por ejemplo, en builds estáticos), Brotli suele ser preferible.
• Si se necesita compresión al vuelo en tiempo real, Gzip es más rápido y menos demandante.
• También es posible usar ambos: servir Brotli si el cliente lo soporta, y Gzip como fallback.

Conclusión

Brotli y Gzip son herramientas relevantes para mejorar la carga de aplicaciones web. Brotli ofrece mejor compresión, mientras que Gzip es más rápido en compresión dinámica. La decisión no tiene por qué ser excluyente; podemos configurarlos juntos y dejar que el navegador elija. Con una configuración adecuada en el servidor o en el pipeline de build, obtenemos beneficios de rendimiento.