👩‍👩‍👦‍👦 🔗 🏹 Brotli Performance en el mundo real 👩‍👩‍👧‍👦 👨 👎🏼

Una de las reglas más fundamentales para desarrollar sitios web rápidos es optimizar sus recursos. Si estamos hablando de recursos de texto, sobre código escrito en HTML, CSS y JavaScript, esto significa que estamos hablando de compresión de datos. El estándar de facto para comprimir recursos de texto en la web es el método Gzip. Es decir, aproximadamente el 80% de los recursos comprimidos obtenidos durante las descargas del sitio se comprimen usando Gzip. Para comprimir el 20% restante de los recursos, se utiliza un algoritmo mucho más nuevo: Brotli.

Por supuesto, estos 100% de los recursos comprimidos que entran en los navegadores cuando reciben respuestas a las solicitudes a los sitios no incluyen absolutamente todos los recursos. Todavía hay muchos recursos que podrían comprimirse, o que podrían comprimirse. Pero estos recursos permanecen sin comprimir. Se pueden encontrar métricas más detalladas con respecto a la compresión en la sección Compresión del recurso Web Almanac.

El método de compresión gzip es increíblemente eficiente. Todo el trabajo de Shakespeare en texto plano ocupa 5.3 MB. Y después de la compresión Gzip (nivel de compresión 6) ocupan solo 1.9 MB. Esto significa que el tamaño del archivo en el que se almacenan estos datos ha disminuido en 2,8 veces. Al mismo tiempo, los datos no se pierden durante la compresión. ¡Excelente!

Aún mejor, el grado de compresión de Gzip se ve afectado por la presencia de líneas duplicadas en los archivos. Cuantas más repeticiones en el texto, más eficiente será la compresión. Esto es muy bueno para la web, ya que el código escrito en HTML, CSS y JS tiene una sintaxis uniforme y contiene muchas repeticiones.

Pero, aunque Gzip es un método de compresión muy eficiente, también es bastante antiguo. Apareció en 1992 (lo que, por supuesto, ayuda a explicar su prevalencia generalizada). Después de 21 años, en 2013, Google lanzó Brotli, un nuevo algoritmo que promete niveles de compresión aún más altos que los que el método Gzip es capaz de hacer. Los mismos trabajos de Shakespeare de 5.2 MB de tamaño se comprimen usando Brotli a un tamaño de 1.7 MB (con un nivel de compresión de 6). Y esto ya significa una reducción de 3,1 veces en el tamaño del archivo. Esto es incluso mejor que usar Gzip.

Usando una herramienta para estimar el nivel de compresión de datos usando Gzip y Brotli, es probable que descubras que al comprimir algunos datos, Brotli es mucho más eficiente que Gzip. Por ejemplo, los datos de ReactDOM son un 27% más pequeños cuando se comprimen usando Brotli con un nivel de compresión máximo (11) que cuando se usa Gzip con un nivel de compresión máximo (9).

Aquí hay una comparación de la compresión Brotli con la compresión Gzip al procesar ReactDOM.

Nivel de compresión	Tamaño (en bytes)	Eficiencia de compresión (en comparación con los datos sin comprimir)	% De mejora sobre Gzip
1	43456	2,73	3%
2	39898	2.97	once%
3	39416	3,08	quince%
4 4	38488	3,08	quince%
5 5	36323	3.27	diecinueve%
6 6	36048	3.29	veinte%
7 7	35804	3.31	veinte%
8	35709	3.32	21%
9 9	35659	3,33	21%
10	33590	3,53	25%
once	33036	3,59	27%

Como puede ver, en todos los niveles de compresión, Brotli evita Gzip. Con el nivel de compresión máximo disponible con Brotli, es un 27% más eficiente que Gzip.

Y, en base a la observación personal, observo que la transición de uno de mis clientes de Gzip a Brotli condujo a una reducción media en el tamaño de los archivos en un 31%.

Como resultado, en los últimos años, junto con otros expertos en rendimiento, he estado alentando a los clientes a cambiar de Gzip a Brotli.

Diré algunas palabras sobre la compatibilidad del navegador para Gzip y Brotli. Gzip está tan extendido que CanIUse ni siquiera muestra una tabla con información de soporte. Lo dice así: "Este encabezado HTTP es compatible con casi todos los navegadores (comenzando con IE6 +, Firefox 2+, Chrome 1+, etc.)". Y Brotli, mientras escribe este material, disfruta de un nivel de apoyo muy agradable .a 93.17%. ¡Y esto es mucho, mucho! Por lo tanto, si su sitio tiene al menos un tamaño significativo, es posible que no le guste particularmente el retorno de recursos sin comprimir a más del 6% de sus usuarios. Pero usando Brotli, no perderás nada. Los clientes usan un modelo progresivo de soporte para nuevos algoritmos, por lo que los usuarios que no pueden aceptar los recursos de Brotli simplemente usarán la opción de respaldo en forma de Gzip. Hablaremos más sobre esto a continuación.

En general, especialmente si usa CDN, encender Brotli es cuestión de segundos. Al menos este es el caso con Cloudflare, el servicio que uso para el sitio CSS Wizardry. Sin embargo, muchos de mis clientes, si hablamos de los últimos años, no tienen tanto éxito. Algunos de ellos soportan su propia infraestructura, y la práctica muestra que instalar e implementar Brotli no es tan simple. Algunos usan servicios CDN que no difieren en capacidades fácilmente accesibles para admitir el nuevo algoritmo.

En aquellos casos en que no podíamos cambiar a Brotli, siempre teníamos una pregunta sin respuesta: "¿Qué pasaría si ...?". Como resultado, finalmente decidí armarme con números y dar una respuesta a la pregunta de qué le da al sitio la transición a Brotli.

Menos no es necesariamente más rápido.

Por lo general, "menos", sin embargo, significa "más rápido". Como regla general, si reduce el tamaño del archivo, se transferirá más rápido del servidor al cliente. Pero si crea un archivo, digamos, un 20% más pequeño, esto no significa que llegará un 20% más rápido. El punto aquí es que el tamaño del archivo es solo un aspecto del rendimiento web. Y sea cual sea el tamaño del archivo, el recurso entregado al navegador está asociado con muchos otros factores y con muchas limitaciones del sistema: retrasos en la red, pérdida de paquetes y similares. En otras palabras, ahorrar en el tamaño del archivo ayuda a transferir los mismos datos que antes, enviando menos paquetes, pero la transferencia de datos entre el servidor y el cliente está limitada por demoras en la red, como resultado, la velocidad con la que los paquetes que llegan al cliente será menor no cambiará.

TCP, paquetes, retraso de ida y vuelta

Si es muy simplista considerar transferir archivos del servidor al cliente, tendremos que echar un vistazo al protocolo TCP. Cuando recibimos un archivo del servidor, no nos llega de una vez. El protocolo TCP, sobre el cual funciona HTTP, divide los archivos en segmentos llamados paquetes. Estos paquetes se envían al cliente en orden, en secuencia. El cliente confirma la recepción de cada paquete de la serie antes de comenzar la transferencia de la siguiente serie. Esto sucede hasta que el cliente recolecta todos los paquetes necesarios, hasta que no haya paquetes no enviados en el servidor y hasta que el cliente pueda recolectar los paquetes en algo que pueda reconocerse como un archivo. Para que la sesión de transferencia de secuencia de paquetes se complete con éxito, el servidor debe enviarlos al cliente, y el cliente debe acusar recibo. Hora,La cantidad de datos necesarios para recibir datos y recibir la confirmación de recepción se denomina Tiempo de ida y vuelta (RTT).

Cada nueva conexión TCP no puede saber cuál es el ancho de banda disponible y qué tan confiable es la conexión (es decir, cuál es el nivel de pérdida de paquetes). Si el servidor intenta enviar megabytes de datos a través de una conexión que admite una velocidad de transferencia de datos de un megabit por segundo, dicha transferencia abrumará la conexión y provocará una sobrecarga del canal de comunicación. Y viceversa: si el servidor intenta transferir una pequeña cantidad de datos a través de una conexión muy rápida, la conexión se utilizará de manera ineficiente, estará inactiva.

Para resolver este rompecabezas, TCP utiliza un mecanismo llamado inicio lento. Esto es parte de la estrategia de gestión de la ventana de sobrecarga. Cada nueva conexión TCP está limitada por la capacidad de enviar solo 10 paquetes de datos en la primera secuencia de paquetes (10 paquetes, el tamaño de la ventana de congestión inicial). Diez segmentos TCP son aproximadamente 14 KB de datos. Si el cliente recibe con éxito estos paquetes, la segunda serie ya contendrá 20 paquetes, entonces habrá 40, 80, 160 y así sucesivamente. El crecimiento exponencial de los paquetes en secuencias continuará hasta que ocurra uno de los siguientes eventos:

El sistema enfrentará la pérdida de paquetes. En este punto, el servidor reducirá el número de paquetes en la siguiente secuencia, dividiendo el número anterior de paquetes por 2, e intentará transferir los datos nuevamente.
Hemos alcanzado el límite del ancho de banda disponible y podemos usarlo a plena capacidad.

Esta estrategia simple y elegante le permite equilibrarse al borde de la precaución y el optimismo. Se aplica a cada nueva conexión TCP establecida por la aplicación web.

En palabras simples, el tamaño inicial de la ventana de congestión de la nueva conexión TCP es de solo 14 Kb. O aproximadamente el 11.8% de los datos de ReactDOM sin comprimir. O 36.94% de los datos comprimidos usando Gzip, o 42.38% de los datos comprimidos usando Brotli (en el nivel de compresión máximo).

Y luego disminuiremos la velocidad. ¡La transición del 11.8% al 36.94% ya es una mejora muy notable! Pero la transición de 36.94% a 42.38%, esto está lejos de ser tan impresionante. ¿Qué esta pasando?

Número de sesión de datos	La cantidad de datos transferidos en una sesión, Kb	Cantidad acumulada de datos transferidos, Kb	La secuencia en la que se transfieren los datos de ReactDOM
1	14	14
2	28	42	Gzip (37.904 Kb), Brotli (33.036 Kb)
3	56	98
4 4	112	210	Opción sin comprimir (118.656 Kb)
5 5	224	434

Resulta que tanto los datos comprimidos con Gzip como los datos comprimidos con Brotli se transmiten en la misma serie de paquetes. La transferencia de un archivo requiere dos secuencias. Si el RTT resulta ser bastante uniforme cuando se transmiten todas las secuencias, esto significa que lleva el mismo tiempo transmitir datos comprimidos usando Gzip y Brotli. Por otro lado, la transferencia de una versión sin comprimir de datos requiere cuatro series de paquetes, no dos. Y esto, especialmente en conexiones con altas latencias de red, puede resultar en un tiempo bastante notable requerido para la transferencia de datos.

Aquí tiendo al hecho de que la velocidad de transferencia de datos depende no solo del tamaño de los archivos. Está influenciado por las características del funcionamiento del protocolo TCP. No solo necesitamos hacer los archivos más pequeños. Necesitamos hacerlos mucho más pequeños, llevándolos a un tamaño que les permita ser transmitidos en menos secuencias de paquetes.

Esto significa, en teoría, que para que el algoritmo de Brotli sea notablemente más eficiente que Gzip, debe poder comprimir los datos de manera mucho más agresiva. Esto es necesario para que los datos puedan transmitirse en menos secuencias de paquetes que cuando se usa Gzip. Y no sé cómo se desarrollará este algoritmo ...

Vale la pena señalar que el modelo anterior está bastante simplificado. Hay muchos otros factores a considerar. Por ejemplo, ¿es una conexión TCP nueva o ya abierta? ¿Se está utilizando la conexión para otra cosa? ¿Están los mecanismos de priorización del tráfico del servidor deteniendo e iniciando la transferencia de datos? ¿Las transmisiones H / 2 tienen acceso exclusivo al ancho de banda? Esta sección es un estudio más serio. Debe considerarse como un buen punto de partida para su propia investigación. Pero considere analizar a fondo los datos utilizando algo como Wireshark, y lea este material, que proporciona una descripción más profunda de la "magia" de los primeros 14 Kb.

Lo anterior se aplica solo a las nuevas conexiones TCP. Los archivos transferidos a través de una conexión existente no pasarán por el procedimiento de inicio lento. Esto nos lleva a dos conclusiones importantes:

No creo que valga la pena repetirlo, pero lo repetiré: los recursos estáticos deben ser alojados. Esta es una excelente manera de evitar retrasos de inicio lento, ya que el uso de su propio servidor, ya "calentado", significa que los paquetes que salen de este servidor tienen acceso a un ancho de banda más amplio. Esta conclusión me lleva a la segunda conclusión.
, , . , . .

	, ,	,
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1778
8	1792	3570
9	3584	7154
10	7168	14322
…	…	…
20	7340032	14680050

Al final de la décima sesión de transferencia de datos, la cantidad de datos transferidos en una sesión es de 7168 Kb, mientras que, en total, 14322 Kb de datos ya se han transferido. Esto es más que suficiente para el trabajo ordinario en Internet (es decir, no para ver Game of Thrones). De hecho, generalmente sucede que cargamos toda la página web y todos sus recursos sin siquiera alcanzar el límite de nuestro ancho de banda. En otras palabras, el uso de un canal de comunicación de fibra óptica de 1 Gbit / s (es decir, 0,125 GB / s) no hará que la navegación normal parezca mucho más rápida que usar una conexión más lenta, ya que la mayoría de este canal ni siquiera se utilizará.

Y para la vigésima sesión de transferencia de datos, teóricamente transferimos 7.34 GB de datos en una secuencia de paquetes.

¿Qué hay del mundo real?

Hasta ahora, nos hemos involucrado en consideraciones teóricas. Y comencé a trabajar en este material debido al hecho de que me gustaría saber sobre el impacto que Brotli puede tener en sitios reales.

Hasta ahora, los números dados aquí han señalado la gran diferencia entre la falta de compresión y el uso de Gzip, y el hecho de que la ganancia de usar Brotli, en comparación con Gzip, es bastante modesta. Esto nos dice que la transición de la falta de compresión al uso de Gzip dará una mejora notable, mientras que la transición de Gzip a Brotli probablemente parezca mucho menos impresionante.

Seleccioné, como ejemplos, varios sitios, guiados por las siguientes consideraciones:

El sitio debe ser relativamente conocido (es mejor usar sitios que se puedan comparar con algo).
El sitio debe ser adecuado para la prueba. Es decir, debe ser de un tamaño adecuado (por lo que será más interesante analizar sus materiales para la compresión) y, al mismo tiempo, no debe contener principalmente materiales que no estén comprimidos con Gzip / Brotli, como, por ejemplo, YouTube.
No todos los sitios de la colección deberían pertenecer a grandes corporaciones (vale la pena analizar algunos, digamos, sitios "regulares").

Teniendo en cuenta estos requisitos, seleccioné los sitios enumerados a continuación y comencé a probar. Aquí están los sitios que seleccioné:

No quería complicar las pruebas, así que me decidí por los siguientes indicadores:

La cantidad de datos transferidos.
Primer tiempo de pintura contenta (FCP).

Se analizaron en las siguientes situaciones:

Falta de compresión.
Usando gzip.
Usando brotli.

La métrica FCP se ve cercana al mundo real y lo suficientemente universal como para su aplicación en cualquier sitio, ya que le permite evaluar lo que la gente necesita de los sitios web, es decir, el contenido de estos sitios. Además, elegí esta métrica porque Paul Calvano , una persona inteligente, dijo esto: "La experiencia me dice que el uso de Brotli conduce a un FCP mejorado, especialmente cuando los recursos críticos de CSS / JS son grandes" .

Pruebas

Te diré un secreto sucio. Muchos estudios de rendimiento web (no todos, pero muchos) no se basan en investigaciones sobre mejoras de rendimiento, sino en sacar conclusiones de lo contrario, de la degradación del rendimiento. Por ejemplo, la BBC es mucho más fácil afirmar que "pierden el 10% de los usuarios por cada segundo adicional que necesitan para cargar su sitio" que averiguar qué sucede gracias a una mejora de un segundo. Es mucho más fácil ralentizar el sitio en lugar de acelerarlo, y tiene la sensación de que es por eso que muchas personas hacen este trabajo tan bien.

Dado esto, no intenté descargar primero sitios que usan Gzip, y luego, sin conexión, comprimir sus contenidos de alguna manera usando Brotli. En cambio, encontré sitios que usan Brotli, y luego apagué la compresión. Pasé de Brotli a Gzip, y luego de Gzip a la no compresión, midiendo cómo funciona esto en el sitio.

Aunque, por ejemplo, no puedo conectarme al servidor Linkedin y desconectar Brotli, simplemente puedo acceder a este sitio desde un navegador que no es compatible con Brotli. Aunque no puedo desactivar el soporte de Brotli en Chrome, puedo ocultar del servidor el hecho de que mi navegador es compatible con Brotli. Los navegadores le dicen a los servidores qué algoritmos de compresión admiten utilizando el encabezado de solicitudcontent-encoding. Con Webpagetest, puedo personalizar los encabezados yo mismo. ¡Entonces, todo es muy simple!

Las funciones avanzadas de WebPageTest nos permiten configurar encabezados de solicitud personalizados.

Así es como configuro el campo Encabezados personalizados:

Apagado completo de la compresión: accept-encoding: randomstring.
Desactivación Brotli, pero el soporte Gzip: accept-encoding: gzip.
Para usar Brotli si este método de compresión es compatible con el sitio (y siempre que sea compatible con el navegador): el campo permanece vacío.

Puede averiguar si esto funciona según lo previsto al verificar la presencia (o ausencia) del encabezado content-encodingen la respuesta del servidor.

resultados

Como se esperaba, la transición de la falta de compresión a Gzip significó una mejora significativa, pero la transición de Gzip a Brotli no parece tan impresionante. Los datos sin procesar de mis experimentos se pueden encontrar aquí . Los siguientes son los hallazgos que más me interesan:

Gzip : 73%.
FCP Gzip : 23.305%.
Brotli Gzip: 5.767%.
FCP Brotli Gzip: 3.462%.

Todos estos son valores medios. Hablando de "tamaños de material", me refiero solo a HTML, CSS y JavaScript.

Gracias al uso de Gzip, los tamaños de archivo se redujeron en un 73% en comparación con sus versiones sin comprimir. Y el uso de Brotli permitió reducir el tamaño de los archivos solo en un 5.7% adicional. Si hablamos de FCP, gracias a Gzip, este indicador mejoró en un 23% en comparación con la falta de compresión, y Brotli agregó solo un 3.5% adicional a esto.

Aunque parece que tales resultados refuerzan la teoría, hay varias formas de mejorar estos resultados. El primero es probar un número mucho mayor de sitios, me gustaría discutir dos más con más detalle.

Datos de recursos propios y datos de fuentes externas.

En mis pruebas, apagué Brotli en todas partes, y no solo para los servidores que almacenan datos del sitio. Esto significa que medí no solo los beneficios que obtienen los sitios al usar Brotli, sino que, en términos de potencial, los beneficios que Brotli obtiene de las fuentes externas que usan estos sitios. Esto cae dentro del alcance de nuestros intereses solo si los recursos de terceros se utilizan en las formas críticas de los sitios bajo investigación, pero vale la pena recordarlo.

Niveles de compresión

Hablando de compresión, a menudo discutimos los resultados obtenidos con el mejor escenario de aplicación de compresión. Es decir, cuando usamos Gzip tenemos en cuenta el noveno nivel de compresión, y cuando usamos Brotli - 11 ° nivel. Sin embargo, es poco probable que el servidor bajo investigación se configure de la manera más óptima. Por ejemplo, Apache usa compresión gzip de nivel 6, mientras que NGINX usa solo la primera.

Deshabilitar Brotli significa que estamos cambiando a la opción de reserva, a Gzip, y dada la forma en que probé los sitios, no pude cambiar dicha configuración de reserva ni actuar de alguna manera. Digo esto porque los materiales de los dos sitios en la prueba en realidad aumentaron de tamaño cuando se activó Brotli. Esto me indica que el nivel de compresión Gzip fue tal que proporcionó una compresión más fuerte que el nivel de compresión Brotli.

Elegir un nivel de compresión es un compromiso. A todos les gustaría pedir el más alto nivel de compresión y, en este sentido, considerar el problema resuelto. Pero este enfoque no es práctico. El hecho es que el tiempo extra que necesitará el servidor para realizar dinámicamente esta compresión es muy probable que niegue los beneficios de un mayor nivel de compresión. Para hacer frente a este problema, puede recurrir a lo siguiente:

Puede usar un nivel pragmático de compresión que proporcione el equilibrio correcto de velocidad y eficiencia durante la compresión dinámica de datos.
Puede cargar recursos estáticos precomprimidos en el servidor, cuyo nivel de compresión es mayor que el utilizado para la compresión dinámica. En este caso, para seleccionar el nivel de compresión dinámica, puede usar la idea descrita en el primer párrafo.

Resumen

Uno tiene la impresión de que, razonando con sensatez, puede reconocer la insignificancia de las ventajas de Brotli sobre Gzip.

Si habilitar el soporte de Brotli es cuestión de un par de movimientos del mouse en el panel de control de su CDN, entonces debe tomar Brotli y encenderlo ahora mismo. La compatibilidad con este algoritmo de compresión es lo suficientemente amplia, los navegadores que no son compatibles con Brotli cambian fácilmente a mecanismos de reserva, e incluso una ligera mejora es mejor que nada.

Si es posible, cargue recursos estáticos precomprimidos en el nivel de compresión máximo en los servidores. Y para la compresión dinámica, no use los niveles de compresión más altos, pero no los más bajos. Si usa NGINX, asegúrese de no estar usando el primer nivel de compresión estándar para NGINX.

Sin embargo, si para usar Brotli, es posible que necesite semanas de desarrollo, prueba e implementación, no se preocupe, solo asegúrese de usar la compresión Gzip para todo lo que se puede comprimir (esto incluye, además de recursos de texto, archivos .ico y .ttf: si, por supuesto, se usan en su proyecto).

Supongo que una versión corta de este artículo podría verse así: si no puede o no puede habilitar Brotli, no está perdiendo mucho.

¡Queridos lectores! ¿Planeas usar Brotli?

Brotli Performance en el mundo real