Yo no era muy fan de las compresiones hasta que, hace un par de años, vi en una presentación usada en una ponencia por el director de UI de Netflix una cosa que me llamó bastante la atención y que explicaré en este post cuando hable de la compresión GZIP.
Vamos a empezar por el principio. Desde hace ya años, los servidores web y los navegadores web son compatibles con GZIP, un formato de compresión y descompresión rápida que permite que el servidor web comprima los archivos antes de enviarlos al navegador web del visitante y que posteriormente el navegador web del visitante pueda descomprimirlos. Todo esto de forma totalmente transparente para el usuario final.
GZIP es un formato opensource y está basado en el algoritmo LZ77, es un formato de compresión sin perdida. Como es normal en este tipo de formatos de compresión, son mucho más eficaces en archivos de texto y eso es precisamente de lo que están formados la mayor parte de los sitios web: archivos HTML, archivos CSS, archivos JS, etc. Todos estos son archivos de base texto y, por lo tanto, la compresión puede hacer maravillas.
Para que te hagas una idea, esto es lo que me ahorro yo en mi sitio web (este blog) utilizando una mezcla de GZIP y Brotli:
Como puedes ver, la compresión ronda el 82%. Es decir, vamos a ahorrar un 82% de ancho de banda al servir esta web.
Si quieres probar con tus propios sitios, puedes hacerlo con esta herramienta: https://www.giftofspeed.com/gzip-test/
Volviendo al tema, como ves, el ahorro de ancho de banda es una de las principales ventajas que obtendremos al implementar una compresión en nuestro servidor web. Además, hay algunas ventajas indirectas:
- Se reducen los tiempos de descarga y, a causa de ello, mejoramos de forma casi inapreciable los tiempos de carga. Cuanto más grande y compleja sea la web, más se va a notar la compresión en los tiempos de carga.
- Mejoramos la experiencia de usuario, ya que normalmente estos algoritmos de compresión son muy rápidos y el navegador del visitante casi ni lo nota. De todos modos, es importante combinar la compresión con el cache de navegador o browser cache para conseguir mejores resultados.
El tema de ahorrar ancho de banda puede parecer una tontería con las conexiones actuales, pero hay que tener en cuenta que los smartphones con conexiones móviles no siempre tienen buena cobertura y ahí es precisamente donde más se nota esto y también la implementación de HTTP/3 en el servidor web.
Otro factor importante en este tipo de formatos de compresión para web es que no solo afecta la ratio de compresión que sea capaz de conseguir el algoritmo, sino también la velocidad de compresión y descompresión. Este último factor será vital para que todo sea transparente para los visitantes y no se retrase la carga de la web.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
Compresión GZIP y Deflate
Como he dicho, la compresión GZIP lleva muchos años entre nosotros y es bastante común. De hecho, la mayoría de plugins de cache para WordPress y la mayoría de módulos de cache de página para PrestaShop implementan automáticamente la compresión GZIP.
Existe una alternativa a GZIP, llamada Deflate, que tiene muchas similitudes a nivel interno con GZIP. Sin embargo, Deflate es un formato de compresión sin patentar y puede tener múltiples implementaciones diferentes. De hecho, GZIP utiliza Deflate para comprimir datos, aunque añade posteriormente un checksum de verificación y un encabezado de datos.
A nivel práctico, normalmente en servidores de hosting se utiliza Deflate cuando GZIP no está disponible, ya que la activación se hace exactamente de la misma forma. Actualmente, todos los servidores de hosting deberían tener activo GZIP, ya que puede ser un poquito más estable que Deflate al llevar checksum.
Configurar o activar GZIP y Deflate
En caso de que no quieras implementar GZIP mediante plugin en WordPress o si utilizas otro CMS, puedes hacerlo también con este código en el .htaccess para Apache o LiteSpeed (servidor web optimizado que usamos en Raiola Networks).
| 1 2 3 4 5 6 7 8 9 10 | <ifModule mod_gzip.c> mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* </ifModule> |
Y si quieres activar Deflate también con el .htaccess, puedes utilizar el siguiente código:
| 1 2 3 4 5 6 7 8 9 10 11 12 | <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/shtml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript </IfModule> |
Si GZIP está habilitado en el servidor web Apache o LiteSpeed, con este código en el .htaccess se activará. Deflate normalmente siempre está activo, por lo que puede servirte si GZIP no lo está.
En el caso de Nginx, debes realizar los ajustes necesarios en los archivos de configuración. En cambio, en VestaCP viene activado por defecto, así que si usas uno de los servidores VPS optimizados de Raiola Networks no tendrás que preocuparte.
En caso contrario, tienes que modificar estas opciones de configuración dentro del archivo nginx.conf.
| 1 2 3 4 5 6 7 8 | gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; |
Después puedes usar la herramienta que hemos mostrado anteriormente para probar si GZIP está funcionando correctamente en tu sitio web: https://www.giftofspeed.com/gzip-test/
En el navegador web no tienes que hacer nada, ya que todos los navegadores son compatibles con GZIP.
Configurar o activar GZIP en WordPress
Como he dicho antes, en WordPress podemos instalar un plugin de cache y ya tendremos GZIP activado, ya que la mayoría de plugins de este tipo (como WP Rocket o LiteSpeed Cache) realizan esta configuración.
Si queremos utilizar un plugin de cache que no admita esto o si queremos usar un plugin para activar GZIP, existen varias opciones gratuitas para hacerlo:
- Enable Gzip Compression: https://es.wordpress.org/plugins/enable-gzip-compression/
- PageSpeed Ninja: https://es.wordpress.org/plugins/psn-pagespeed-ninja/
- WP Performance Score Booster: https://es.wordpress.org/plugins/wp-performance-score-booster/
Estos solo son tres ejemplos, pero existen mucho más plugins. Sin embargo, la mayoría se basan en el .htaccess, por lo que también puedes implementarlo así.
Compresión Brotli
Vamos a cambiar completamente de tema para pasar a hablar de Brotli, un nuevo formato de compresión que ha aparecido hace relativamente poco.
Brotli es un formato de compresión de datos opensource basado en el algoritmo LZ77, al igual que GZIP, pero con aspectos mejorados. En 2015 se lanzó Brotli para la compresión de fuentes web, pero ha ido evolucionando hasta lo que actualmente es: una buena alternativa a GZIP que se ha ido introduciendo poco a poco en navegadores y servidores web (aunque por el momento hay muchos servidores que aún no son compatibles).
La diferencia entre GZIP y Brotli es que Brotli ya no utiliza Deflate. Eso mejora en un 20% la compresión en archivos de base texto como los HTML, CSS y JS, mientras que se mantienen unos tiempos de compresión y descompresión aceptables.
Si quieres ver la mejora de compresión que ofrece Brotli en relación a GZIP, esta herramienta puede ayudarte a hacer una estimación: https://tools.paulcalvano.com/compression.php
En el nivel más alto de compresión de Brotli, se mejora alrededor de un 20% la compresión del nivel más alto de GZIP, como dice la teoría.
Aunque en casos más extremos la mejora de compresión puede llegar al 30%, el problema viene en la descompresión, ya que puede ser lenta y podemos perder el tiempo ganado en la descarga.
Si quieres probar si tienes Brotli en tu web o si está funcionando, puedes utilizar esta herramienta de KeyCDN: https://tools.keycdn.com/brotli-test
Configurar o activar Brotli
Como he dicho antes, en el momento de publicar este artículo todavía es complicado encontrar servidores web que sean compatibles con Brotli. No obstante, los principales servicios CDN como KeyCDN o CloudFlare ya son compatibles con Brotli y LiteSpeed Web Server también. En la actualidad, Apache y Nginx requieren mod_brotli y muchos proveedores de hosting no lo implementan porque es una funcionalidad bastante nueva.
Por otro lado, aún hay algunas versiones antiguas de navegadores que no son compatibles con Brotli: https://caniuse.com/#search=brotli
Si el servidor web tiene Brotli activado y tenemos .htaccess (Apache y LiteSpeed), podemos utilizar este código en el .htaccess:
| 1 2 3 | <IfModule mod_brotli.c> AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/x-javascript application/javascript application/json application/x-font-ttf application/vnd.ms-fontobject image/x-icon </IfModule> |
En Nginx, una vez más, debemos modificar el archivo de configuración nginx.conf como si fuera para GZIP:
| 1 2 3 | brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript; |
Para probar si funciona correctamente Brotli, podemos utilizar la herramienta de KeyCDN: https://tools.keycdn.com/brotli-test
Como he dicho, en servicios CDN como CloudFlare también podemos activar Brotli, aunque tendremos que hacerlo directamente desde el panel de control.
Configurar o activar Brotli en WordPress
En WordPress, algunos plugins permiten activar Brotli. Sin embargo, todos están basados en la modificación del .htaccess, por lo que van a funcionar en todos los servidores web excepto en Nginx (que no utiliza el .htaccess).
Algunos plugins de cache, como W3 Total Cache, llevan una opción para activar la compresión Brotli.
Desgraciadamente, no existen muchos plugins que permitan activar Brotli fácilmente, ya que por el momento es una tecnología que se está implementando poco a poco. Por esta razón, mi recomendación es que hagas la implementación mediante un tweak en el .htaccess de tu dominio.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
14 Responses
hola alvaro los servidores compartido de raiola son compatibles tienen brotli???
Hola Marcos, si, nuestros servidores de hosting cPanel de Raiola llevan LiteSpeed y por lo tanto son compatibles con Brotli.
gracias alvaro me encanta segirte la verdad que le pones mucho empeño
Gracias a ti 🙂
Entiendo que recomiendas totalmente la instalación de un plugin de cache que contemple el activar gzip e incluso brotli en lugar de hacerlo a mano (en código), verdad?
O serias más de hacerlo a mano?
Yo he activado una opción que tenéis en vuestro servidor en optimización que he leído en un tutorial vuestro que es compresión deflate. Con eso basta o sigues pensando que mejor instalar el plugin de cache con gzip? De hecho es que ahora mismo con mi web no activa y estando editándola (newspaper template) se han gastado 33 GB de ancho!!! No sé qué demonios ha pasado.. ¿Realmente editar la template puede hacer que se gaste eso? (No tenía ni el defalte ese activado). Entiendo que editar tb es gasto de bandwidth pero tantísimo? Ponle que haya abierto, cerrado la plantilla de la home unas 15-20 veces al día y la web (abriéndola con el host de Windows cambiado para poder acceder) un número similar de veces… Tus compañeros están estudiando el caso porque les he abierto un ticket al darme cuenta… Entenderás mi preocupacion porque editar la template es algo que sí o sí tengo que hacer.
Muchas gracias
Hola Raul, todos los plugins hacen el mismo proceso que harias tu manualmente, es decir, meter el snippet en el .htaccess, por lo que da igual como lo hagas.
Alguno puede hacerlo por cabeceras, pero si el server no tiene el modulo activo, es indiferente. Por esa razón todos usan el .htaccess.
En cuanto al ancho de banda, pueden ser bots, pero me parece muy raro, nunca he visto algo así. Si puedes pasame tu email de cliente por el formulario de contacto de este blog y lo miro.
Hola Alvaro.
¿Entonces recomiendas GZIP o Brotli?
Cuando accedo a la url que nos has dejado en el artículo en mi web que tengo en Raiola me pone brotli, pero en este blog GZIP.
Cambié a brotli hace un tiempo, pero al ver que tu no la tienes en tu web me ha surgido la duda de si estoy haciendo bien. Me obsesiona la velocidad…. 🙂
Gracias!!!!!
Hola Marcos, ahora mismo este blog tiene GZIP porque tengo CloudFlare desactivado por un tema de mantenimiento y como voy liado, llevo 2 semanas con el desactivado.
En los servidores LiteSpeed de Raiola utilizamos ya Brotli (activable), pero yo en este servidor el Brotli lo tengo mediante CloudFlare, ya que uso Nginx por temas de “logística”, vamos a llamarle así.
Yo recomiendo Brotli siempre que se pueda usar, aunque ya te adelanto que la velocidad no será perceptible al ojo humano ni con GZIP ni con Brotli.
Genial. Muchas gracias por la aclaración, es un placer poder realizar pequeñas consultas a través de este blog a un experto de tu calibre.
Gracias a ti Marcos por el comentario 🙂
si tengo gzip activado en mi cpanel y brotli activado en cloudflare, no habria doble proceso ?
Realmente no, porque quien realmente esta sirviendo el contenido comprimido es CloudFlare y lo hará con Brotli.
Hace años, al combinar Apache con Nginx como proxy inverso, si que habia problemas con el doble GZIP, pero CloudFlare ya esta preparado para esto.
Hola Álvaro,
Me surge una duda. He pasado los tests tanto de comprobar si tengo gzip activado como si tengo brotli activado y ambos me dan positivo, por lo que no entiendo muy bien cuál de las dos se está aplicando realmente en mi web.
He preguntado en el hosting y me han dicho que ellos utilizan brotli pero luego si compruebo las cabeceras correspondientes en el front me sale gzip pero si lanzo un curl -I para ver las cabeceras, no me aparece ninguna relacionada con la compresión gzip.
La verdad es que tengo un mar de dudas. ¿Hay alguna forma de comprobar al 100% que la compresión se está realizando y cuál de ellas se está realizando?
Muchas gracias!! La verdad que el artículo ha sido muy ameno de leer.
Hola Raul, la forma idónea de comprobarlo es en las cabeceras, pero vamos, que un CURL tampoco debería mentir.