WordPress no comprime GZIP o Brotli cómo activarlo

Si WordPress no comprime GZIP o Brotli, lo normal es que el problema no esté en WordPress como núcleo. La compresión HTTP suele activarse en el servidor, en el hosting, en un plugin de caché que actúe como capa de configuración o en un CDN. La forma correcta de comprobarlo es revisar la cabecera Content-Encoding en la respuesta HTTP.

En la práctica, si una web no entrega HTML, CSS o JavaScript comprimidos, conviene revisar primero qué servidor usa, si Cloudflare o un CDN similar está delante y si el stack permite compresión GZIP o compresión Brotli. Muchos plugins ayudan, pero no siempre pueden habilitar la compresión si el servidor no la soporta.

Qué significa que WordPress no comprime GZIP o Brotli

Significa que los recursos que entrega tu web pueden estar viajando sin compresión HTTP, ocupando más bytes de los necesarios. Esto afecta sobre todo a HTML, CSS, JavaScript, JSON o SVG. Las imágenes JPEG, PNG o WebP no suelen beneficiarse tanto porque ya van comprimidas por otros métodos.

WordPress genera o sirve contenido, pero la decisión de enviarlo con GZIP o Brotli depende normalmente del software web que responde la petición. Por eso, cuando se habla de activar GZIP en WordPress o activar Brotli en WordPress, en realidad se suele estar hablando de la configuración del entorno que lo sirve.

Cómo comprobar si tu web está enviando contenido comprimido

La verificación debe hacerse mirando la respuesta HTTP, no solo una opción del plugin o del panel. Lo importante es detectar la cabecera Content-Encoding.

Métodos prácticos

• En DevTools del navegador, abre la pestaña Red, recarga la página y revisa un archivo HTML, CSS o JS.
• Con curl, consulta las cabeceras y comprueba si aparece Content-Encoding: gzip o Content-Encoding: br.
• También puedes usar comprobadores fiables, pero conviene confirmar el resultado manualmente.

Si no aparece esa cabecera en recursos textuales, es probable que la entrega comprimida no esté activa o que un proxy intermedio la esté gestionando de otra forma.

Dónde se activa GZIP o Brotli según tu servidor o CDN

Aquí está la clave: depende del stack real. No existe un ajuste universal dentro de WordPress que lo resuelva por sí solo.

• Apache: puede configurarse con módulos de compresión del servidor.
• Nginx: suele activarse en la configuración del servicio o del bloque del sitio.
• LiteSpeed: puede gestionarlo desde su propia configuración o desde el entorno del hosting.
• Cloudflare Brotli: si usas Cloudflare, la compresión puede servirse desde su red, según la configuración disponible.

Los plugins de caché a veces añaden reglas, facilitan la integración o muestran avisos, pero no siempre habilitan por sí mismos la compresión si el servidor o CDN no la soporta o si el proveedor no permite modificar ese ajuste.

Qué opción conviene más: GZIP o Brotli

En términos prácticos, Brotli suele ofrecer mejor compresión que GZIP para recursos textuales, lo que puede ayudar a mejorar velocidad WordPress. A cambio, su disponibilidad depende más del servidor, del proxy o del CDN que tengas delante.

GZIP sigue siendo una opción muy compatible y ampliamente soportada. Si tu infraestructura permite Brotli de forma estable, suele ser la opción preferible para CSS, JS y HTML. Si no, GZIP sigue siendo una mejora válida frente a no comprimir nada.

Errores frecuentes al intentar activar la compresión en WordPress

• Pensar que instalar un plugin basta en cualquier hosting.
• Dar por hecho que una opción marcada significa que ya se está enviando contenido comprimido.
• Comprobar solo la portada y no revisar recursos concretos.
• Intentar comprimir archivos ya optimizados, como imágenes o vídeos.
• No tener en cuenta que un CDN puede sobrescribir o gestionar la compresión de forma distinta al servidor de origen, como ocurre con una caché mal configurada.

Qué hacer si no puedes activarlo desde WordPress

Si no tienes acceso al servidor o al panel del hosting, lo razonable es pedir al proveedor que confirme si la compresión HTTP está disponible y cómo la gestiona. Si usas un CDN, conviene revisar si puede activar Brotli o GZIP desde su capa perimetral.

Si el hosting es muy cerrado, puede que solo te quede validar la configuración actual, documentar la ausencia de Content-Encoding y solicitar soporte técnico. En entornos WordPress administrados, esta parte suele depender más del proveedor que del CMS.

En resumen, el problema rara vez es “WordPress” en sí. Lo importante es revisar hosting, CDN y configuración real del servidor Apache Nginx LiteSpeed. Si no puedes modificar esa capa, una auditoría técnica puede ayudarte a localizar el bloqueo exacto y decidir el siguiente paso con criterio.