Durante la Speed Week, hemos hablado de la importancia de optimizar el rendimiento. La compresión desempeña un papel clave, ya que reduce el tamaño de los archivos transmitidos por Internet. Los archivos de menor tamaño permiten descargas más rápidas, tiempos de carga de sitios web más cortos y, mejoran las experiencias del usuario.
Tomemos como ejemplo real, los productos de limpieza del hogar. Se calcula que "un producto típico de limpieza contiene un 90 % de agua y menos de un 10 % de ingredientes realmente útiles". Si eliminamos el 90 % del líquido de una botella típica de 500 ml de producto de limpieza, reduciremos el peso de 600 a 60 gramos. Esta reducción significa que solo hay que enviar un paquete de 60 g, con instrucciones para rehidratarlo una vez se reciba el producto en casa. Extrapolado a galones, esta reducción de peso se convierte sin más en un enorme ahorro en los envíos de las empresas, por no hablar del impacto medioambiental.
Así funciona la compresión. El remitente comprime el archivo tanto como sea posible, y luego envía el archivo más pequeño con instrucciones sobre cómo tratarlo cuando se reciba. La reducción del tamaño de los archivos enviados garantiza que la cantidad de ancho de banda necesaria para enviar archivos por Internet sea mucho menor. Cuando los archivos se almacenan en proveedores de nube caros, como AWS, la reducción del tamaño de los archivos enviados puede equivaler directamente a un importante ahorro de costes en ancho de banda.
Los archivos de menor tamaño también son especialmente beneficiosos para los usuarios finales con conexiones a Internet limitadas, como dispositivos móviles en redes móviles o usuarios ubicados en zonas con velocidades de red lentas.
Cloudflare siempre ha admitido el sistema de compresión GZIP. GZIP es un algoritmo de compresión muy utilizado que existe desde 1992 y proporciona compresión de archivos a todos los usuarios de Cloudflare. Sin embargo, en 2013, Google implementó Brotli, que admite mayores niveles de compresión y un mejor rendimiento en general. El cambio de GZIP a Brotli se traduce en archivos de menor tamaño y tiempos de carga de páginas web más rápidos. Cloudflare incluyó la compatibilidad con Brotli en 2017 para conectar Cloudflare y los navegadores de los clientes. Hoy, anunciamos la compatibilidad con Brotli de extremo a extremo para el contenido web en los niveles más altos posibles, desde el servidor de origen hasta el cliente.
Si tu servidor de origen es compatible con Brotli, actívalo, aumenta el nivel de compresión y optimiza el rendimiento.
Usamos el nivel 11 de la compresión Brotli
Brotli tiene 12 niveles de compresión que van de 0 a 11, siendo 0 el que proporciona la mayor velocidad de compresión, pero la menor relación de compresión, y 11 el que ofrece la mayor relación de compresión, pero necesita más recursos informáticos y tiempo. Durante nuestra implementación inicial de Brotli hace cinco años, identificamos que el nivel 4 de compresión ofrecía un equilibrio entre el ahorro de bytes y el tiempo de compresión sin afectar el rendimiento.
Desde 2017, Cloudflare ha estado utilizando el nivel 4 de compresión Brotli para todos los activos comprimibles en función del encabezado "accept-encoding" del usuario final. Sin embargo, uno de los problemas era que Cloudflare solo solicitaba compresión GZIP al servidor de origen, aunque este admitiera Brotli. Además, Cloudflare siempre descomprimía el contenido recibido del servidor de origen antes de comprimirlo y enviarlo al usuario final, lo que añadía tiempo de procesamiento. Como resultado, los clientes no podían aprovechar plenamente las ventajas que ofrecía la compresión Brotli.
El pasado
Ahora que Cloudflare es totalmente compatible con Brotli de extremo a extremo, los clientes empezarán a recibir en sus servidores de origen nuestro encabezado actualizado accept-encoding. Una vez disponible, los clientes podrán transferir, almacenar en caché y servir directamente archivos Brotli comprimidos, hasta el nivel máximo de 11. Esta ventaja ayudará a reducir la latencia y el consumo de ancho de banda. Si el dispositivo del usuario final no admite la compresión Brotli, descomprimiremos automáticamente el archivo y lo serviremos en su formato descomprimido o como archivo comprimido con GZIP, dependiendo del encabezado Accept-Encoding.
Compatibilidad completa de la compresión Brotli de extremo a extremo
El usuario final no admite la compresión Brotli
Los clientes pueden implementar la compresión Brotli en su servidor de origen consultando los materiales en línea adecuados. Por ejemplo, los clientes que utilicen NGINX, pueden implementar Brotli siguiendo este tutorial y configurando la compresión en el nivel 11 dentro del archivo de configuración `nginx.conf` de la siguiente manera:
brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript text/xml
application/xml application/xml+rss text/javascript image/x-icon
image/vnd.microsoft.icon image/bmp image/svg+xml;
Cloudflare servirá entonces estos activos al cliente exactamente con el mismo nivel de compresión (11) para el archivo brotli_types coincidente. De esta forma, cualquier imagen SVG o BMP se enviará al cliente comprimida al nivel 11 de Brotli.
Pruebas
Aplicamos la compresión a un archivo CSS sencillo, midiendo el impacto de varios algoritmos y niveles de compresión. Nuestro objetivo era identificar las posibles mejoras que podrían experimentar los usuarios optimizando las técnicas de compresión. Puedes ver estos resultados en la siguiente tabla:
| Prueba | Tamaño (bytes) | % de reducción del archivo original (mejor a mayor %) |
|---|---|---|
| Respuesta sin comprimir (sin utilizar compresión) | 2747 | - |
| Compresión GZIP por defecto de Cloudflare (nivel 8) | 1121 | 59,21 % |
| Compresión Brotli por defecto de Cloudflare (nivel 4) | 1110 | 59,58 % |
| Compresión con el nivel máximo de GZIP (nivel 9) | 1121 | 59,21 % |
| Compresión con el nivel máximo de Brotli (nivel 11) | 909 | 66,94 % |
El nivel 11 de la compresión Brotli permite a los usuarios reducir un 19 % el tamaño de sus archivos en comparación con el mejor nivel de compresión de GZIP. Además, el nivel de compresión Brotli más eficaz es un 18 % menor que el nivel por defecto utilizado por Cloudflare. Este dato pone de relieve la reducción de tamaño significativa que se consigue utilizando la compresión Brotli, sobre todo en sus niveles más altos, lo que puede mejorar el rendimiento del sitio web, acelerar los tiempos de carga de las páginas y reducir las tarifas de salida.
Para aprovechar las mayores tasas de compresión de extremo a extremo, es necesario desactivar las siguientes funciones del proxy de Cloudflare.
- Ofuscación de la dirección de correo electrónico
- Rocket Loader
- Exclusiones del lado del servidor (SSE)
- Mirage
- Minificación de HTML - JavaScript y CSS pueden seguir activos.
- Automatic HTTPS RewritesLa razón es que Cloudflare necesita descomprimir y acceder al cuerpo para aplicar los ajustes solicitados. Como alternativa, el cliente puede desactivar estas funciones para rutas específicas con Configuration Rules.
Si alguna de estas funciones de reescritura está activada, tu servidor de origen puede seguir enviando la compresión Brotli a niveles superiores. Sin embargo, descomprimiremos, aplicaremos la(s) función(es) de Cloudflare habilitada(s) y volveremos a comprimir sobre la marcha utilizando el nivel 4 de Brotli o el nivel 8 de GZIP predeterminado de Cloudflare, en función del encabezado accept-encoding del usuario.
Para los navegadores que no admitan la compresión Brotli, seguiremos descomprimiendo y enviando respuestas comprimidas con GZIP o sin comprimir.
Implementación
El paso inicial para implementar Brotli desde el servidor de origen consistió en la creación de un módulo de descompresión que se pudiera integrar en la pila de software de Cloudflare. Este módulo nos permite convertir eficazmente los bits comprimidos recibidos del origen en el archivo original sin comprimir. Este paso era clave, ya que numerosas funciones, como Email Obfuscation y Cloudflare Workers Customers, dependen del acceso al cuerpo de una respuesta para aplicar personalizaciones.
Integramos el descompresor en el núcleo del proxy web inverso de Cloudflare. Esta integración garantizó que todos los productos y funciones de Cloudflare pudieran acceder a la descompresión Brotli sin problema. Ademas, permitió al equipo de Cloudflare Workers incorporar Brotli directamente en Cloudflare Workers, lo que facilitó la interactuación de nuestros clientes con las respuestas devueltas en Brotli o pasarlas al usuario final sin modificarlas.
Novedad: Compression Rules, control granular de la compresión para usuarios finales
Por defecto, Cloudflare comprime ciertos tipos de contenido en función del encabezado Content-Type del archivo. Hoy, también anunciamos Compression Rules, una herramienta que permitirá a nuestros clientes Enterprise obtener todavía más control sobre la forma y el contenido que comprimimos.
Compression Rules es una herramienta que concederá a nuestros clientes Enterprise un mayor control sobre las capacidades de compresión de Cloudflare a fin de personalizar la forma y el contenido que comprimimos para optimizar el rendimiento de tu sitio web.
Por ejemplo, el uso de Compression Rules para archivos .ktx permitirá a los clientes optimizar la entrega de texturas en aplicaciones webGL, mejorando así la experiencia general del usuario. La activación de la compresión minimiza el uso de ancho de banda y garantiza que las aplicaciones webGL se carguen de forma rápida y sencilla, incluso cuando se trata de texturas grandes y detalladas.
Como alternativa, los clientes pueden desactivar la compresión o especificar una preferencia sobre cómo comprimimos. Otro ejemplo podría ser una empresa de infraestructuras que solo quisiera admitir la compresión GZIP para sus dispositivos IoT, y permitir la compresión Brotli para todos los demás nombres de host.
Compression Rules usa los filtros sobre los que se desarrollan nuestros otros productos de reglas, pero añade los campos de Tipo de medio y Tipo de extensión. De esta forma, los usuarios pueden especificar fácilmente el contenido que desean comprimir.
Eliminamos el botón de activación Brotli
Algunos navegadores web admiten Brotli desde 2016. Cloudflare ofreció compatibilidad con Brotli en 2017. Como ocurre con todas las nuevas tecnologías web, Brotli era desconocido y ofrecimos a los clientes la posibilidad de activar o desactivar Brotli de forma selectiva a través de la API y de nuestra interfaz de usuario.
Ahora que Brotli ha evolucionado y es compatible con todos los navegadores, tenemos previsto habilitar Brotli en todas las zonas por defecto en los próximos meses. Así, reflejaremos el comportamiento de GZIP que admitimos actualmente y eliminaremos el botón de activación de nuestro panel de control. Si los navegadores no admiten Brotli, Cloudflare seguirá admitiendo sus tipos de codificación aceptados, como GZIP o sin comprimir, y los clientes Enterprise podrán seguir utilizando Compression Rules para controlar de forma granular cómo comprimimos los datos para sus usuarios.
El futuro de la compresión web
La implementación y el rendimiento de Brotli como nueva técnica de compresión para la web han tenido muy buena acogida. De cara al futuro, seguiremos de cerca las tendencias y los nuevos algoritmos de compresión, como zstd, como posible algoritmo de compresión de próxima generación.
Al mismo tiempo, intentaremos mejorar la compresión Brotli directamente donde seamos capaces. Un desarrollo en el que estamos trabajando especialmente es el de los diccionarios compartidos con Brotli. Siempre que comprimes un activo, utilizas un "diccionario" que ayuda a que la compresión sea más eficiente. Una analogía sencilla de esto es escribir OMW en un mensaje del iPhone. El iPhone lo traducirá automáticamente a "On My Way" utilizando su propio diccionario interno.
| O | M | W | ||||||
|---|---|---|---|---|---|---|---|---|
| O | n | M | Y | W | Un | Y |
Este diccionario interno ha cogido tres caracteres y los ha transformado en nueve caracteres (espacios incluidos). El diccionario interno ha ahorrado seis caracteres, lo que se traduce en ventajas de rendimiento para los usuarios.
Por defecto, la RFC de Brotli define un diccionario estático que utilizan tanto los clientes como los servidores de origen. El diccionario estático se diseñó para ser de uso general y aplicable a todo el mundo. El tamaño del diccionario se optimizó para que no fuera demasiado grande y, al mismo tiempo, pudiera generar los mejores resultados de compresión. Sin embargo, ¿qué pasaría si un servidor de origen pudiera generar un diccionario a medida adaptado a un sitio web específico? Por ejemplo, un diccionario específico para Cloudflare nos permitiría comprimir las palabras y frases que aparecen repetidamente en nuestro sitio, como la palabra "Cloudflare". El diccionario a medida se diseñaría para comprimirlo al máximo y el navegador que utilizaría el mismo diccionario podría volver a traducirlo.
Una nueva propuesta de la Web Incubator Community Group (WICG) pretende hacer precisamente eso, permitir especificar diccionarios propios que los navegadores puedan utilizar para que los sitios web optimicen aún más la compresión. Estamos entusiasmados por contribuir a esta propuesta y tenemos previsto publicar en breve los resultados de nuestra investigación.
Probar ahora
Compression Rules ya está disponible, y en las próximas semanas lanzaremos Brotli de extremo a extremo para que puedas mejorar el rendimiento, reducir el ancho de banda y controlar de forma granular cómo Cloudflare gestiona la compresión para tus usuarios finales.