La auditoría de PageSpeed recomienda Brotli. El equipo activo brotli on; brotli_comp_level 11 en nginx para todo, incluida una API JSON de doscientos kilobytes generada en cada solicitud. El tiempo hasta el primer byte aumenta de ciento veinte milisegundos a trescientos ochenta en un VPS de dos vCPU; la puntuación de Lighthouse aumenta en la métrica de “bytes transferidos”. Los usuarios de dispositivos móviles sienten la lentitud.
La compresión reduce los bytes: cuesta CPU y, a veces, retrasa el primer byte. Brotli versus gzip no es una religión: es una decisión sobre dónde y a qué nivel comprimir, dependiendo del tipo de contenido y la carga del servidor.
gzip vs Brotli: los compromisos
| Algoritmo | Compresión | Velocidad de compresión | Uso típico |
|---|---|---|---|
| gzip nivel 6 | Bueno | Rápido | HTML dinámico, API |
| brotli nivel 4 al 6 | Mejor | Moderado | Dinámico si hay procesador disponible |
| brotli nivel 11 + precompresión | Máximo | Sin conexión | .js/.css estático |
La precompresión consiste en generar file.js.br en sentido ascendente (brotli -k file.js) y luego servirlo con Content-Encoding: br: carga cero de CPU en el momento de la solicitud.
Comprimir una imagen JPEG significa pagar al procesador por cero bytes guardados.
nginx, Apache, CDN: una sola capa
En nginx, configure gzip activado; tipos_gzip...; brotli encendido; brotli_types...; con niveles moderados (cuatro a seis). Cloudflare y CDN similares a menudo incluyen compresión en el borde: deshabilite la doble compresión en el lado de origen.
En compartido, a veces el panel de control impone la compresión. Mida el impacto en el retraso hasta el primer byte antes de apilar varias capas.
Dinámico vs estático: dos estrategias
Para estático, la canalización de compilación produce archivos .gz y .br; nginx habilita gzip_static activado; brotli_static encendido;. Para dinámico, el nivel cinco de gzip suele ser suficiente: mida el retraso en el percentil 95 antes de activar un Brotli agresivo. Para API JSON, la compresión resulta útil más allá de uno o dos kilobytes; las microrespuestas no se benefician de esto.
HTTP/2 y HTTP/3 cambian la compresión del encabezado, no la lógica del cuerpo comprimible.
Compartido y VPS: limitaciones del host
En compartido, la compresión a menudo la habilita globalmente el host; no siempre se elige el algoritmo o el nivel. Mida antes de agregar una capa PHP o un complemento de WordPress que ya comprima lo que comprime el servidor. En VPS, usted controla nginx o Apache, pero un VPS de dos vCPU se saturará rápidamente con el nivel once de Brotli en HTML dinámico bajo la carga del Black Friday.
Verifique el archivo de alojamiento en el directorio para verificar si se incluye compresión perimetral o CDN; a veces, la mejor ganancia proviene del producto de alojamiento en lugar de una configuración agresiva de nginx.
Medida: bytes versus latencia
Compare los bytes transferidos (herramientas de desarrollo del navegador), el tiempo hasta el primer byte (temporización de navegación) y la carga de CPU del origen bajo carga real. El objetivo es ganar bytes sin aumentar el retraso en más de cincuenta milisegundos en páginas críticas.
Errores comunes
Doble compresión PHP más nginx. Olvidé gzip_min_length 256. Brotli se aplicó a transmisiones SSE o WebSocket, donde no es apropiado. Nivel máximo en HTML generado bajo carga, transformando un VPS modesto en un cuello de botella de CPU.
La cumbre: puntuación del faro, experiencia degradada
Comprimir sin agregar latencia significa comprimir previamente lo estático, moderar lo dinámico y comprimir en el salto de red correcto (borde de la red en lugar de origen).
Decide y avanza sin puntos ciegos
Audite los tipos MIME servidos y elimine la compresión innecesaria en formatos ya comprimidos. Precomprima activos estáticos en la compilación y sírvalos a través de nginx o CDN. Aplique gzip o Brotli moderado en HTML dinámico después de la medición. Asegúrate de que solo una capa comprima cada respuesta. Mida el retraso hasta el primer byte antes y después de cualquier cambio. Compare hosts y CDN a través del directorio y el comparador.
Preguntas frecuentes
¿Brotli siempre es mejor que gzip?
Brotli generalmente comprime mejor el texto, especialmente en niveles altos, pero es más lento de comprimir. Es ideal para activos estáticos precomprimidos; gzip o Brotli en un nivel moderado son los más adecuados para HTML dinámico.
¿Dónde comprimir: nginx, CDN o PHP?
Prefiera network edge o nginx para archivos estáticos. Evite comprimir en PHP si nginx ya lo hace. En compartido, verifique los límites del procesador impuestos por el host.
¿Qué tipos MIME comprimir?
text/html, text/css, application/javascript, application/json, image/svg+xml, no el JPEG, PNG o WebP ya comprimido.
¿Cómo servir Brotli a navegadores más antiguos?
Negociación mediante Accept-Encoding: Brotli si es compatible, en caso contrario gzip. La CDN a menudo administra las dos versiones en caché separada usando el encabezado Vary.
Menos bytes solo cuentan si el primer byte llega a tiempo.