El sitio tarda 4 segundos en abrirse y el visitante se va. ¿Le suena familiar? La mayoría de las veces el problema no está en el hosting ni en las imágenes. Las páginas simplemente pesan más de lo que deberían porque el servidor las entrega «tal cual», sin compresión.

La compresión GZIP reduce el tamaño de HTML, CSS y JavaScript entre un 60 y un 80% antes de que viajen al navegador. Para WordPress esto no es un plugin pesado con multitud de ajustes, sino una directiva en la configuración o una casilla de verificación en el panel de administración. Según W3Techs, la compresión la utiliza más del 85% de los sitios web en internet y, si el suyo no está entre ellos, está perdiendo posiciones en buscadores y conversiones sin motivo alguno.

A continuación, le presento siete formas efectivas de activar GZIP: desde la edición manual de.htaccess hasta un par de clics en un plugin. Al final le mostraré cómo comprobar el resultado y repasaré las preguntas frecuentes sobre la compatibilidad con CDN, Brotli y la caché.

💡 Resumen rápido:

• Añadir el código de compresión al .htaccess por FTP
• Escribir gzip on y gzip_types en nginx.conf
• Activar la compresión con una casilla en W3 Total Cache o WP Rocket
• Comprobar el resultado en Chrome DevTools o GiftOfSpeed

Qué es la compresión GZIP y por qué un sitio WordPress la necesita

GZIP es un algoritmo de compresión que funciona a nivel de servidor: antes de enviarlos al navegador, «empaqueta» los archivos de texto en un formato más compacto. El navegador los desempaqueta sobre la marcha y muestra la página como de costumbre. El usuario no nota ninguna diferencia, mientras que el volumen de datos transmitidos se reduce varias veces.

Qué se comprime exactamente: el código HTML de la página, las hojas de estilo CSS, los scripts de JavaScript, los archivos XML, las fuentes y los SVG. GZIP no afecta a las imágenes; para ellas existen formatos de compresión específicos (WebP, AVIF) y plugins de optimización.

La diferencia en cifras es fácil de ver en Chrome DevTools: la misma página antes y después de la compresión difiere en tamaño de dos a tres veces. Multiplique eso por el número de visitantes al mes y obtendrá un ahorro considerable en tráfico y tiempo de carga.

Un matiz importante: GZIP no es la única opción. Los servidores modernos admiten Brotli, un algoritmo de Google que comprime archivos de texto entre un 15 y un 25% mejor que GZIP. Pero Brotli no está disponible en todos los proveedores de hosting, mientras que GZIP funciona en todas partes, incluidas las configuraciones más antiguas. Por lo tanto, siempre vale la pena empezar con GZIP y conectar Brotli como el siguiente nivel cuando la base esté lista.

Método 1: mediante.htaccess en Apache

El escenario más común: el sitio funciona con Apache y solo necesita añadir unas líneas al archivo .htaccess en la raíz del sitio.

Dónde se encuentra.htaccess. Conéctese al servidor por FTP (por ejemplo, a través de FileZilla) o acceda al gestor de archivos del hosting. En la carpeta raíz del sitio (donde están wp-config.php y las carpetas wp-content, wp-admin) busque .htaccess. Descárguelo en su ordenador; lo editaremos localmente para que, en caso de error, pueda revertir los cambios rápidamente.

Qué añadir. Abra .htaccess en un editor de texto (Notepad++, VS Code, Sublime Text) y añada el siguiente bloque ANTES de las líneas # BEGIN WordPress:

1
<IfModule mod_deflate.c>
2
  AddOutputFilterByType DEFLATE text/html text/css text/javascript
3
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
4
  AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml
5
  AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
6
  AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf
7
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
8
 
9
  BrowserMatch ^Mozilla/4 gzip-only-text/html
10
  BrowserMatch ^Mozilla/4.0[678] no-gzip
11
  BrowserMatch bMSIE !no-gzip !gzip-only-text/html
12
  Header append Vary User-Agent
13
</IfModule>

Qué está sucediendo aquí. El bloque <IfModule mod_deflate.c> comprueba si el módulo mod_deflate está habilitado en el servidor (en la mayoría de los proveedores de hosting lo está por defecto). Las directivas AddOutputFilterByType DEFLATE especifican qué tipos de archivo comprimir. Las líneas BrowserMatch son un parche para versiones antiguas de Internet Explorer que evita errores de gzip en IE6 e inferiores. Header append Vary User-Agent indica a los servidores proxy que tengan en cuenta el navegador del usuario al almacenar en caché.

Guarde el archivo y súbalo de nuevo al servidor reemplazando el original. Antes de hacerlo, asegúrese de hacer una copia de seguridad del .htaccess original; si el sitio se cae, simplemente restaure la versión anterior y todo funcionará como antes.

Si después de subirlo el sitio arroja un error 500, compruebe si hay espacios o saltos de línea adicionales antes de <?php o después de las etiquetas de cierre en el archivo. Un error en .htaccess rompe todo el sitio, por lo que es mejor hacer las modificaciones de una en una y comprobar después de cada una.

Método 2: en un servidor NGINX

NGINX gestiona la compresión de manera diferente a Apache. Aquí no existe .htaccess y todos los ajustes se escriben en el archivo nginx.conf o en el archivo de configuración de un sitio específico (normalmente en /etc/nginx/sites-available/).

Añada o descomente las siguientes líneas en la sección http o server:

1
gzip on;
2
gzip_vary on;
3
gzip_min_length 1000;
4
gzip_comp_level 6;
5
gzip_types text/plain text/css text/javascript
6
           application/javascript application/x-javascript
7
           application/rss+xml application/xml application/xhtml+xml
8
           image/svg+xml image/x-icon
9
           font/ttf font/otf application/x-font-ttf
10
           application/vnd.ms-fontobject;
11
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Después de realizar los cambios, compruebe la sintaxis de la configuración con el comando nginx -t y recargue NGINX: sudo systemctl reload nginx.

El parámetro gzip_comp_level 6 es un equilibrio entre el nivel de compresión y la carga del procesador. Un valor de 1 es la compresión mínima, 9 es la máxima. En la práctica, el nivel 6 proporciona casi el mismo ahorro que el 9, pero consume notablemente menos recursos del servidor.

Método 3: en un servidor IIS (Windows Server)

IIS es un servidor web de Microsoft utilizado en alojamientos Windows. La activación de la compresión aquí se realiza de dos maneras: a través de la interfaz gráfica o de la línea de comandos.

A través de la interfaz de IIS. Abra el Administrador de IIS. En la sección «Componentes» → «Servicios» busque «Compresión». Marque las casillas «Habilitar compresión de contenido estático» y «Habilitar compresión de contenido dinámico». En el panel «Acciones» haga clic en «Aplicar».

A través de la línea de comandos (como administrador):

1
:: Static compression
2
appcmd set config /section:urlCompression /doStaticCompression:True
3
 
4
:: Dynamic compression
5
appcmd set config /section:urlCompression /doDynamicCompression:True

La compresión estática almacena en caché versiones ya comprimidas de los archivos en disco, ahorrando tiempo de procesador. La compresión dinámica comprime las respuestas «sobre la marcha» y es adecuada para páginas personalizadas, pero carga el procesador. En la práctica, para WordPress se habilitan ambos modos: la estática se encarga del CSS/JS mientras que la dinámica maneja el HTML de cada página.

Método 4: a través del panel del proveedor de hosting

La mayoría de los proveedores de hosting modernos habilitan GZIP por defecto. Si usted está en cPanel, vaya a la sección «Optimización del sitio» o «Rendimiento» y busque el interruptor «Compresión» o «Comprimir contenido». En Plesk la ruta es similar: «Rendimiento» → «Compresión de salida».

Si no encuentra el interruptor, escriba al soporte del hosting. Esta es una solicitud estándar; el soporte técnico la responde en minutos y a menudo habilita la compresión a nivel de servidor en una sola respuesta. No necesita explicar qué es GZIP; basta con escribir «Por favor, habilite la compresión GZIP para mi sitio».

Puede comprobar si el hosting ya está comprimiendo las páginas antes de realizar cualquier modificación; el método se describe en la sección «Cómo comprobar si la compresión está habilitada» más abajo. Si la comprobación muestra que GZIP está funcionando, omita todos los métodos de servidor y pase a los plugins solo si desea gestionar la compresión desde el panel de administración de WordPress.

Método 5: plugin W3 Total Cache

W3 Total Cache es uno de los plugins de caché más antiguos del repositorio de WordPress, con un millón de instalaciones activas y una calificación de 4.5 en WordPress.org. La compresión GZIP se activa con una casilla de verificación independiente y no requiere modificar archivos del servidor.

Instale el plugin desde el repositorio de WordPress, vaya a Performance → Browser Cache y localice la sección «HTTP (gzip) compression». Marque la casilla «Enable HTTP (gzip) compression» y guarde los ajustes. El plugin añadirá automáticamente las directivas necesarias a .htaccess o configurará las reglas de NGINX según el servidor en el que se ejecute el sitio.

• Ventajas: no modifica manualmente los archivos del servidor, un millón de instalaciones confirma su estabilidad, compatible con CDN y Brotli
• Desventajas: la interfaz está sobrecargada de opciones, un principiante puede estropear fácilmente la caché con una casilla incorrecta

Método 6: plugin WP Rocket

WP Rocket es un plugin premium de rendimiento que añade automáticamente las reglas GZIP al .htaccess tras la activación. No tiene ajustes de compresión; se habilita de forma automática al instalarlo.

• Ventajas: cero trabajo manual, la compresión se habilita automáticamente, el plugin también resuelve varias tareas relacionadas (caché, carga diferida, minificación)
• Desventajas: es de pago (desde $59 al año), pagar de más solo por GZIP no se justifica

Si ya compró WP Rocket para otras tareas, la compresión ya está funcionando. Si está pensando en adquirir el plugin solo por el GZIP, no lo haga: .htaccess o W3 Total Cache hacen lo mismo gratis.

Método 7: plugin WP Super Cache

WP Super Cache es un plugin de caché gratuito de Automattic (los mismos responsables de WordPress.com). Funciona de forma más sencilla que W3 Total Cache: menos ajustes, menos probabilidad de romper algo.

Instale el plugin, vaya a Ajustes → WP Super Cache → Avanzado y busque la opción «Comprimir páginas para que se sirvan más rápido a los visitantes». Actívela y guarde.

• Ventajas: gratuito, interfaz sencilla, código estable de Automattic
• Desventajas: inferior a W3 Total Cache en funcionalidad de caché, sin ajuste fino de los tipos de compresión

Cómo funciona la compresión GZIP en la práctica

Cuando un navegador solicita una página envía la cabecera Accept-Encoding: gzip, deflate, br, que significa «entiendo gzip, deflate y brotli, envíe en cualquiera de estos formatos». El servidor ve esta cabecera, comprueba si la compresión está habilitada para el tipo de archivo solicitado y, si es así, comprime la respuesta y añade la cabecera Content-Encoding: gzip.

El navegador recibe los datos comprimidos, los descomprime en memoria y renderiza la página. Para el usuario todo ocurre al instante; la descompresión gzip tarda fracciones de milisegundo incluso en un dispositivo móvil poco potente.

Este mecanismo es universal: funciona igual para Apache, NGINX, IIS y cualquier plugin de WordPress. Los plugins no inventan su propio método de compresión; simplemente añaden las mismas directivas de servidor que escribimos manualmente en los tres primeros métodos.

Qué muestran Google PageSpeed Insights y GTmetrix

Ambos servicios, PageSpeed Insights y GTmetrix, verifican la compresión durante cada auditoría y señalan explícitamente el problema si los recursos de texto se sirven sin GZIP.

En PageSpeed Insights la advertencia aparece como «Habilitar la compresión de texto» en la sección «Oportunidades» de la auditoría. Lighthouse (el motor de PageSpeed Insights) estima directamente el ahorro potencial en kilobytes para cada recurso sin comprimir. En GTmetrix existe una comprobación similar, «Enable GZIP compression» en la categoría «Content».

Un punto importante: ni PageSpeed Insights ni GTmetrix distinguen entre GZIP y Brotli a nivel de recomendación. Si la compresión está habilitada por cualquiera de estos métodos, la auditoría mostrará una marca de verificación verde. Así que GZIP es suficiente para superar la auditoría.

Cómo comprobar si la compresión está habilitada

Tres métodos, del visual al de bajo nivel.

Método 1: Chrome DevTools. Abra el sitio, pulse F12, vaya a la pestaña Red. Actualice la página, haga clic en cualquier fila y mire la pestaña Cabeceras. Busque la línea Content-Encoding: gzip en la sección Cabeceras de respuesta.

Ahí también puede ver el tamaño real y el comprimido: en el ejemplo anterior la página pesaba 51.6 KB, y tras la compresión 17.7 KB.

Método 2: comprobadores en línea. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) o Check GZIP Compression (checkgzipcompression.net): pegue la URL y obtendrá un veredicto y el porcentaje de compresión. Más rápido que DevTools si necesita comprobar el sitio de un tercero o varias páginas seguidas.

Método 3: curl desde la línea de comandos. Si está en Linux/macOS o en WSL en Windows:

1
curl -I -H "Accept-Encoding: gzip" https://yoursite.com | grep Content-Encoding

La respuesta Content-Encoding: gzip significa que la compresión funciona. Una respuesta vacía significa que no.

Breve explicación en vídeo

Para cerrar el tema con un apoyo visual, aquí tiene un breve vídeo que muestra todo el proceso de habilitar GZIP mediante .htaccess y comprobar el resultado en Chrome DevTools:

⁉️🤔 Preguntas frecuentes

¿La compresión GZIP ralentiza el servidor?

Al contrario. Sí, el procesador gasta recursos en comprimir, pero es una carga microscópica comparada con la ganancia por la reducción de datos transmitidos. En el nivel de compresión 6 (el compromiso estándar) el procesador lo gestiona en milisegundos. El único escenario donde la compresión puede ser perceptible es un VPS muy débil con 512 MB de memoria y miles de visitantes simultáneos. Pero en esa situación tiene problemas más graves que el GZIP. En la práctica la compresión no ralentiza el servidor: una página típica de WordPress se comprime en 2-5 milisegundos, mientras que el ahorro en transmisión de datos por la red asciende a decenas y cientos de milisegundos para cada visitante. La compresión siempre es más beneficiosa que su ausencia.

¿GZIP o Brotli: qué elegir en 2026?

Empiece con GZIP; funciona en cualquier alojamiento y lo soportan todos los navegadores sin excepción. Brotli comprime notablemente mejor pero requiere HTTPS (no es un problema en 2026) y soporte del lado del servidor. Si el alojamiento o la CDN (Cloudflare, BunnyCDN) soportan Brotli, habilítelo como complemento a GZIP. La mayoría de los sitios modernos usan ambos: el servidor sirve Brotli a los navegadores que lo entienden y GZIP a todos los demás.

¿Es compatible la compresión GZIP con las CDN?

Totalmente. Las CDN como Cloudflare o BunnyCDN comprimen el contenido en sus propios servidores perimetrales, a menudo en Brotli, incluso si su alojamiento no lo soporta. Si el sitio ya está detrás de Cloudflare, compruebe que la opción «Brotli» esté habilitada en «Velocidad» → «Optimización». En este escenario, configurar GZIP a nivel de servidor sigue siendo útil como respaldo para las solicitudes directas al servidor de origen.

Tengo un plugin de caché. ¿Necesito habilitar GZIP por separado?

Depende del plugin. WP Rocket habilita GZIP automáticamente, W3 Total Cache con una casilla separada, WP Super Cache con una casilla separada. Revise los ajustes de su plugin; casi todos los plugins de caché tienen una opción de compresión pero no todos la habilitan por defecto. No confíe en que «debería funcionar»; compruébelo mediante DevTools después de la configuración.

¿Puedo comprimir páginas a través de functions.php?

Técnicamente se puede, mediante la función PHP ob_start('ob_gzhandler'), pero no lo recomendamos. Este método comprime la salida PHP y no afecta a los archivos estáticos (CSS, JS) que constituyen el grueso del tráfico. La compresión del lado del servidor (Apache/NGINX) funciona para todos los tipos de archivo y no carga el procesador PHP. Deje la compresión PHP para esos casos excepcionales en los que el acceso a las configuraciones del servidor es físicamente imposible.

Conclusiones: qué y cuándo habilitar

GZIP no es una opción de «configurar y olvidar», sino higiene básica para un sitio WordPress. Si ahora mismo no sabe si su servidor comprime las páginas, abra DevTools y compruebe la cabecera Content-Encoding. ¿Falta? Vuelva al método 1 y añada tres líneas al .htaccess.

Matriz de decisión resumida:

• Sitio en Apache y no le teme al FTP → método 1 (.htaccess), 5 minutos
• Sitio en NGINX y tiene acceso a las configuraciones → método 2 (nginx.conf), 10 minutos con verificación de sintaxis
• Por principio no toca los archivos del servidor → W3 Total Cache o WP Super Cache, 2 minutos
• Ya paga por WP Rocket → no haga nada, la compresión funciona de fábrica
• No quiere configurar absolutamente nada → escriba al soporte de hosting

Verifique el resultado con cualquiera de los tres métodos anteriores y cierre esta cuestión para siempre. Esta es esa rara optimización que realmente se hace una sola vez y sigue ahorrando tráfico y acelerando el sitio años después, sin actualizaciones, suscripciones ni configuraciones repetidas.