Brotli y GZIP son métodos de compresión utilizados para reducir el tamaño de las respuestas web antes de enviarlas al navegador. Ambos resultan útiles para HTML, CSS, JavaScript, JSON, XML y otros contenidos de texto, pero difieren en eficiencia, consumo de procesamiento y disponibilidad.
No siempre es necesario elegir uno de forma absoluta. Un servidor o CDN puede entregar Brotli a navegadores compatibles, utilizar GZIP como alternativa y enviar contenido sin comprimir cuando el cliente no admite ninguno.
Cómo el navegador elige la compresión
El navegador anuncia los algoritmos aceptados mediante el encabezado Accept-Encoding. El servidor o la CDN selecciona una representación disponible y responde con Content-Encoding. El valor br identifica Brotli y gzip identifica GZIP.
La descompresión se realiza automáticamente en el dispositivo. La página no cambia visualmente: solamente se reduce la cantidad de datos transmitidos.
Qué es GZIP
GZIP es un formato de compresión consolidado y ampliamente compatible. Durante muchos años fue la opción habitual para comprimir respuestas HTTP y continúa siendo una alternativa segura cuando Brotli no está disponible.
En Apache puede implementarse mediante el módulo mod_deflate. En otros servidores y CDN se habilita desde su propia configuración. La guía sobre cómo activar GZIP incluye comprobaciones y un ejemplo para .htaccess.
Qué es Brotli
Brotli es un formato de compresión diseñado para conseguir buenas relaciones de compresión, especialmente en contenido web. En muchos archivos de texto puede generar respuestas más pequeñas que GZIP, aunque el resultado depende del tipo de recurso y del nivel configurado.
En Apache puede requerir mod_brotli; NGINX y otras plataformas también necesitan soporte específico. En un hosting compartido, la disponibilidad depende del administrador y no puede suponerse solamente porque el navegador sea compatible.
Diferencia de tamaño
Brotli suele aventajar a GZIP en HTML, CSS y JavaScript, pero no existe un porcentaje universal. Un archivo pequeño, ya minificado o con poca repetición puede mostrar una diferencia mínima. La única comparación válida es medir los mismos recursos con configuraciones equivalentes.
Una mejor relación de compresión reduce transferencia, pero no siempre produce una mejora visible si el tiempo de procesamiento aumenta demasiado. La configuración debe equilibrar tamaño y velocidad.
Consumo de CPU y niveles de compresión
Los niveles altos pueden producir archivos más pequeños a costa de más CPU y tiempo. En contenido generado en cada solicitud, comprimir con el máximo nivel puede resultar contraproducente. Para respuestas dinámicas se utilizan niveles moderados; para archivos estáticos precomprimidos se puede invertir más tiempo una sola vez.
Una CDN reduce esta preocupación porque puede comprimir o almacenar las respuestas en su red. El servidor de origen no necesariamente repite el trabajo para cada visitante.
Compatibilidad y fallback
GZIP posee compatibilidad muy amplia. Brotli también está disponible en los navegadores modernos, pero una implementación correcta debe conservar una alternativa. La negociación mediante encabezados permite que cada cliente reciba un método compatible.
No conviene obligar a descargar un archivo Brotli sin comprobar la capacidad del cliente. El servidor debe enviar además el encabezado adecuado para que navegadores y cachés distingan las variantes.
Qué contenidos conviene comprimir
- HTML y texto plano.
- CSS y JavaScript.
- JSON, XML, RSS y fuentes basadas en texto.
- SVG, que internamente utiliza XML.
JPEG, PNG, WebP, AVIF, MP3, MP4, PDF y ZIP ya suelen estar comprimidos. Aplicar Brotli o GZIP sobre ellos consume recursos sin aportar una reducción relevante.
Brotli y GZIP no reemplazan otras optimizaciones
La compresión de transferencia no corrige imágenes demasiado grandes, código innecesario, consultas lentas ni recursos que bloquean el renderizado. Debe combinarse con dimensiones correctas, formatos modernos, caché, minificación prudente y una aplicación eficiente.
Tampoco equivale a la caché. La caché evita regenerar o volver a descargar ciertos recursos; la compresión reduce el tamaño de la respuesta que finalmente se transfiere.
Servidor de origen o CDN
La compresión puede realizarse en Apache, NGINX, la aplicación o una CDN. Conviene elegir una capa principal y verificar el resultado público. Configuraciones redundantes añaden complejidad y dificultan el diagnóstico.
Si usás Cloudflare, su red puede entregar Brotli, GZIP y otros métodos compatibles según las opciones disponibles. En ese caso, lo que recibe el visitante puede ser diferente de la respuesta obtenida al consultar directamente el origen.
La guía para activar Cloudflare explica la incorporación del dominio y los cuidados con DNS, correo y SSL/TLS.
Cómo comprobar qué método se está utilizando
- Abrí las herramientas para desarrolladores del navegador.
- Seleccioná la pestaña de red y recargá la página.
- Elegí el documento HTML o un archivo CSS o JavaScript.
- Revisá el encabezado
Content-Encoding. - Compará el tamaño transferido con el tamaño del recurso sin comprimir.
Realizá la prueba sobre HTTPS y desde la URL pública. Una CDN, un proxy o la caché pueden modificar la respuesta. Probá varios tipos de archivo porque la compresión podría estar activa para unos y no para otros.
Seguridad y contenido sensible
La compresión de respuestas cifradas puede requerir precauciones cuando una página combina secretos con datos controlados por un atacante. Este riesgo se relaciona con ataques de la familia BREACH. Las aplicaciones con información sensible deben seguir las recomendaciones de su framework y evitar reflejar datos no confiables junto a secretos.
En un sitio convencional, no conviene desactivar toda la compresión sin analizar el contexto. La protección debe concentrarse en las respuestas sensibles y en un diseño seguro de la aplicación.
Qué opción conviene utilizar
Si el servidor o la CDN ya negocia Brotli con fallback a GZIP, no hace falta hacer cambios. Si solamente está disponible GZIP, continúa siendo una mejora válida. Si podés habilitar Brotli de forma compatible y medir una reducción real sin aumentar demasiado la carga, puede ofrecer una ventaja adicional.
La decisión final debe basarse en mediciones, no solamente en el nombre del algoritmo. Revisá tamaño transferido, tiempo de respuesta, consumo del servidor y comportamiento de la caché después de cada modificación.
