🌖 🕹️ 🔗 L'efficacité Brotli dans le monde réel 🤞🏻 👩‍👩‍👧‍👧 👨‍👩‍👦

L'une des règles les plus fondamentales pour développer des sites Web rapides est d'optimiser leurs ressources. Si nous parlons de ressources textuelles - de code écrit en HTML, CSS et JavaScript, cela signifie que nous parlons de compression de données. La norme de facto pour la compression des ressources textuelles sur le Web est la méthode Gzip. À savoir, environ 80% des ressources compressées obtenues lors des téléchargements du site sont compressées à l'aide de Gzip. Pour compresser les 20% restants des ressources, un algorithme beaucoup plus récent est utilisé - Brotli.

Bien sûr, ces 100% des ressources compressées qui entrent dans les navigateurs lorsqu'ils reçoivent des réponses aux demandes des sites n'incluent absolument pas toutes les ressources. Il existe encore de nombreuses ressources qui pourraient être compressées ou qui pourraient être compressées. Mais ces ressources restent non compressées. Des mesures plus détaillées concernant la compression peuvent être trouvées dans la section Compression de la ressource Web Almanac.

La méthode de compression gzip est incroyablement efficace. Tout le travail de Shakespeare en texte brut prend 5,3 Mo. Et après compression Gzip (niveau de compression 6), ils n'occupent que 1,9 Mo. Cela signifie que la taille du fichier dans lequel ces données sont stockées a diminué de 2,8 fois. Dans le même temps, les données ne sont pas perdues pendant la compression. Génial!

Encore mieux, le degré de compression Gzip est affecté par la présence de lignes en double dans les fichiers. Plus il y a de répétitions dans le texte, plus la compression est efficace. C'est très bon pour le web, car le code écrit en HTML, CSS et JS a une syntaxe uniforme et contient de nombreuses répétitions.

Mais, bien que Gzip soit une méthode de compression très efficace, il est également assez ancien. Il est apparu en 1992 (ce qui, bien sûr, aide à expliquer sa prévalence généralisée). Après 21 ans, en 2013, Google a publié Brotli, un nouvel algorithme qui promet des niveaux de compression encore plus élevés que ceux dont la méthode Gzip est capable. Les mêmes œuvres de Shakespeare de 5,2 Mo sont compressées en utilisant Brotli à une taille de 1,7 Mo (avec un niveau de compression de 6). Et cela signifie déjà une réduction de 3,1 fois la taille du fichier. C'est encore mieux que d'utiliser Gzip.

En utilisant un outil pour évaluer le niveau de compression des données à l'aide de Gzip et Brotli, vous découvrirez probablement que lors de la compression de certaines données, Brotli est beaucoup plus efficace que Gzip. Par exemple, les données ReactDOM sont 27% plus petites lorsqu'elles sont compressées à l'aide de Brotli avec un niveau de compression maximum (11) que lors de l'utilisation de Gzip avec un niveau de compression maximum (9).

Voici une comparaison de la compression Brotli avec la compression Gzip lors du traitement de ReactDOM.

Niveau de compression	Taille (en octets)	Efficacité de la compression (par rapport aux données non compressées)	% D'amélioration par rapport à Gzip
1	43456	2,73	3%
2	39898	2,97	Onze%
3	39416	3.08	quinze%
4	38488	3.08	quinze%
5	36323	3.27	dix-neuf%
6	36048	3.29	vingt%
7	35804	3,31	vingt%
8	35709	3,32	21%
9	35659	3,33	21%
dix	33590	3,53	25%
Onze	33036	3,59	27%

Comme vous pouvez le voir, à tous les niveaux de compression, Brotli contourne Gzip. Au niveau de compression maximal disponible avec Brotli, il est 27% plus efficace que Gzip.

Et, sur la base d'une observation personnelle, je note que la transition d'un de mes clients de Gzip à Brotli a entraîné une réduction médiane de la taille des fichiers de 31%.

En conséquence, au cours des dernières années, avec d'autres experts en performance, j'ai encouragé les clients à passer de Gzip à Brotli.

Je vais dire quelques mots sur la prise en charge du navigateur pour Gzip et Brotli. Gzip est si répandu que CanIUse n'affiche même pas un tableau avec des informations de support. Il le dit: "Cet en-tête HTTP est pris en charge dans presque tous les navigateurs (à commencer par IE6 +, Firefox 2+, Chrome 1+, etc.)." Et Brotli, tout en écrivant ce matériel, bénéficie d'un soutien très agréable .à 93,17%. Et c'est très, beaucoup! Ainsi, si votre site a au moins une taille importante, vous n'aimerez pas particulièrement le retour de ressources non compressées à plus de 6% de vos utilisateurs. Mais en utilisant Brotli, vous ne perdrez rien. Les clients utilisent un modèle progressif de prise en charge de nouveaux algorithmes, de sorte que les utilisateurs qui ne peuvent pas accepter les ressources Brotli utiliseront simplement l'option de secours sous la forme de Gzip. Nous en parlerons plus loin ci-dessous.

En général, surtout si vous utilisez CDN, activer Brotli est une question de secondes. C'est du moins le cas avec Cloudflare, le service que j'utilise pour le site CSS Wizardry. Cependant, beaucoup de mes clients, si nous parlons des deux dernières années, ne réussissent pas aussi bien. Certains d'entre eux prennent en charge leur propre infrastructure, et la pratique montre que l'installation et le déploiement de Brotli n'est pas si simple. Certains utilisent des services CDN qui ne diffèrent pas par des capacités facilement accessibles pour prendre en charge le nouvel algorithme.

Dans les cas où nous ne pouvions pas passer à Brotli, nous avions toujours une question sans réponse: "Et si ...". En conséquence, j'ai finalement décidé de m'armer de chiffres et de répondre à la question de savoir ce qui donne au site la transition vers Brotli.

Moins n'est pas nécessairement plus rapide.

Habituellement, «moins» signifie cependant «plus vite». En règle générale, si vous réduisez la taille du fichier, il sera transféré plus rapidement du serveur vers le client. Mais si vous faites un fichier, disons, 20% plus petit, cela ne signifie pas qu'il arrivera 20% plus rapidement. Le point ici est que la taille du fichier n'est qu'un aspect des performances Web. Et quelle que soit la taille du fichier, la ressource livrée au navigateur est associée à de nombreux autres facteurs et à de nombreuses limitations du système - retards réseau, perte de paquets, etc. En d'autres termes, économiser sur la taille du fichier aide à transférer les mêmes données qu'auparavant, en envoyant moins de paquets, mais le transfert de données entre le serveur et le client est limité par les retards du réseau, par conséquent, la vitesse à laquelle les paquets arrivant au client seront plus petits ne changera pas.

TCP, paquets, délai d'aller-retour

S'il est très simpliste d'envisager de transférer des fichiers du serveur vers le client, nous devrons jeter un œil au protocole TCP. Lorsque nous recevons un fichier du serveur, il ne nous parvient pas en une seule fois. Le protocole TCP, au-dessus duquel HTTP fonctionne, divise les fichiers en segments appelés paquets. Ces paquets sont envoyés au client dans l'ordre, dans l'ordre. Le client confirme la réception de chaque paquet de la série avant de commencer le transfert de la série suivante. Cela se produit jusqu'à ce que le client collecte tous les packages nécessaires, jusqu'à ce qu'il n'y ait aucun package non envoyé sur le serveur et jusqu'à ce que le client puisse collecter les packages dans quelque chose qui peut être reconnu comme un fichier. Pour que la session de transfert de séquence de paquets se termine avec succès, le serveur doit les envoyer au client et le client doit accuser réception. Temps,La quantité de données nécessaires pour recevoir des données et recevoir une confirmation de réception est appelée Round Trip Time (RTT).

Chaque nouvelle connexion TCP ne peut pas connaître la bande passante disponible et la fiabilité de la connexion (c'est-à-dire quel est le niveau de perte de paquets). Si le serveur essaie d'envoyer des mégaoctets de données sur une connexion qui prend en charge un taux de transfert de données d'un mégabit par seconde, un tel transfert submergera la connexion et entraînera une surcharge du canal de communication. Et vice versa - si le serveur essaie de transférer une petite quantité de données via une connexion très rapide, la connexion sera utilisée de manière inefficace, elle sera inactive.

Pour résoudre ce casse-tête, TCP utilise un mécanisme appelé démarrage lent. Cela fait partie de la stratégie de gestion des fenêtres de surcharge. Chaque nouvelle connexion TCP est limitée par la possibilité d'envoyer seulement 10 paquets de données dans la première séquence de paquets (10 paquets - la taille de la fenêtre de congestion initiale). Dix segments TCP représentent environ 14 Ko de données. Si ces paquets sont reçus avec succès par le client, la deuxième série contiendra déjà 20 paquets, puis il y en aura 40, 80, 160 et ainsi de suite. La croissance exponentielle des paquets en séquences se poursuivra jusqu'à ce que l'un des événements suivants se produise:

Le système fera face à une perte de paquets. À ce stade, le serveur réduira le nombre de paquets dans l'ordre suivant, en divisant le nombre de paquets précédent par 2, et essaiera de transférer à nouveau les données.
Nous avons atteint la limite de bande passante disponible et pouvons l'utiliser à pleine capacité.

Cette stratégie simple et élégante vous permet d'équilibrer au bord de la prudence et de l'optimisme. Elle s'applique à chaque nouvelle connexion TCP établie par l'application Web.

En termes simples, la taille initiale de la fenêtre d'encombrement de la nouvelle connexion TCP n'est que d'environ 14 Ko. Soit environ 11,8% des données ReactDOM non compressées. Soit 36,94% des données compressées à l'aide de Gzip, soit 42,38% des données compressées à l'aide de Brotli (au niveau de compression maximal).

Et puis nous allons ralentir. Le passage de 11,8% à 36,94% est déjà une amélioration très sensible! Mais la transition de 36,94% à 42,38% - c'est loin d'être aussi impressionnant. Que ce passe-t-il?

Numéro de session de données	La quantité de données transférées en une seule session, Kb	Quantité cumulée de données transférées, Kb	La séquence dans laquelle les données ReactDOM sont transférées
1	14	14
2	28	42	Gzip (37,904 Ko), Brotli (33,036 Ko)
3	56	98
4	112	210	Option non compressée (118,656 Ko)
5	224	434

Il s'avère que les données compressées avec Gzip et les données compressées avec Brotli sont transmises dans la même série de paquets. Le transfert d'un fichier prend deux séquences. Si le RTT s'avère assez uniforme lors de la transmission de toutes les séquences, cela signifie qu'il faut le même temps pour transmettre des données compressées à l'aide de Gzip et Brotli. En revanche, le transfert d'une version non compressée de données nécessite quatre séries de paquets, pas deux. Et cela, en particulier sur les connexions avec des latences de réseau élevées, peut entraîner un temps assez important requis pour le transfert de données.

J'ai tendance ici au fait que la vitesse de transfert de données ne dépend pas seulement de la taille des fichiers. Il est influencé par les caractéristiques du fonctionnement du protocole TCP. Nous n'avons pas seulement besoin de réduire la taille des fichiers. Nous devons les rendre beaucoup plus petits, en les portant à une taille qui leur permettra d'être transmis en moins de séquences de paquets.

Cela signifie, en théorie, que pour que l'algorithme de Brotli soit sensiblement plus efficace que Gzip, il doit être capable de compresser les données de manière beaucoup plus agressive. Ceci est nécessaire pour que les données puissent être transmises en moins de séquences de paquets que lors de l'utilisation de Gzip. Et je ne sais pas comment cet algorithme va se développer ...

Il convient de noter que le modèle ci-dessus est assez simplifié. Il y a de nombreux autres facteurs à considérer. Par exemple - s'agit-il d'une connexion TCP nouvelle ou déjà ouverte? La connexion est-elle utilisée pour autre chose? Les mécanismes de priorisation du trafic serveur arrêtent-ils et démarrent-ils le transfert de données? Les flux H / 2 ont-ils un accès exclusif à la bande passante? Cette section est une étude plus sérieuse. Cela devrait être considéré comme un bon point de départ pour vos propres recherches. Mais pensez à analyser en profondeur les données à l'aide de quelque chose comme Wireshark, et lisez ce document, qui fournit une description plus approfondie des 14 premiers Ko «magiques».

Ce qui précède s'applique uniquement aux nouvelles connexions TCP. Les fichiers transférés via une connexion existante ne passeront pas par la procédure de démarrage lent. Cela nous amène à deux conclusions importantes:

Je ne pense pas que cela vaille la peine d'être répété, mais je le répète: les ressources statiques doivent être hébergées. C'est un excellent moyen d'éviter les retards de démarrage lent, car en utilisant votre propre serveur, déjà «réchauffé», les paquets quittant ce serveur ont accès à une bande passante plus large. Cette conclusion m'amène à la deuxième conclusion.
, , . , . .

	, ,	,
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

À la fin de la 10e session de transfert de données, la quantité de données transférées en une seule session est de 7168 Ko, alors qu'au total, 14322 Ko de données ont déjà été transférées. C'est plus que suffisant pour un travail ordinaire sur Internet (c'est-à-dire pas pour visionner Game of Thrones). En fait, il arrive généralement que nous chargions la page Web entière et toutes ses ressources sans même atteindre la limite de notre bande passante. En d'autres termes, l'utilisation d'un canal de communication à fibre optique de 1 Gbit / s (c'est-à-dire 0,125 Go / s) ne rendra pas la navigation normale beaucoup plus rapide que l'utilisation d'une connexion plus lente, car la plupart de ce canal ne sera utilisé.

Et à la 20e session de transfert de données, nous transférons théoriquement 7,34 Go de données dans une séquence de paquets.

Et le monde réel?

Jusqu'à présent, nous nous sommes engagés dans des considérations théoriques. Et j'ai commencé à travailler sur ce matériel car j'aimerais connaître l'impact que Brotli peut avoir sur des sites réels.

Jusqu'à présent, les chiffres donnés ici ont montré l'énorme différence entre le manque de compression et l'utilisation de Gzip, et le fait que le gain de l'utilisation de Brotli, par rapport à Gzip, est assez modeste. Cela nous indique que la transition du manque de compression à l'utilisation de Gzip donnera une amélioration notable, tandis que la transition de Gzip à Brotli peut probablement sembler beaucoup moins impressionnante.

J'ai sélectionné, à titre d'exemples, plusieurs sites, guidés par les considérations suivantes:

Le site doit être relativement connu (il vaut mieux utiliser des sites comparables à quelque chose).
Le site doit être adapté au test. C'est-à-dire qu'il devrait être d'une taille appropriée (il sera donc plus intéressant d'analyser ses matériaux pour la compression), et en même temps, il ne devrait pas contenir principalement des matériaux qui ne sont pas compressés en utilisant Gzip / Brotli - comme, par exemple, YouTube.
Tous les sites de la collection ne doivent pas appartenir à de grandes sociétés (cela vaut la peine d'analyser certains, disons, des sites «réguliers»).

Compte tenu de ces exigences, j'ai sélectionné les sites répertoriés ci-dessous et commencé les tests. Voici les sites que j'ai sélectionnés:

Je ne voulais pas compliquer les tests, j'ai donc opté pour les indicateurs suivants:

La quantité de données transférées.
Premier temps de peinture contentieuse (FCP).

Ils ont été analysés dans les situations suivantes:

Manque de compression.
Utilisation de gzip.
Utilisation de brotli.

La métrique FCP semble proche du monde réel et suffisamment universelle pour être appliquée à n'importe quel site, car elle vous permet d'évaluer ce dont les gens ont besoin de sites Web - c'est-à-dire le contenu de ces sites. De plus, j'ai choisi cette métrique parce que Paul Calvano , une personne intelligente, a déclaré ceci: "L'expérience me dit que l'utilisation de Brotli conduit à une amélioration de FCP, en particulier lorsque les ressources CSS / JS critiques sont importantes" .

Essai

Je vais vous dire un sale secret. De nombreuses études sur les performances Web (pas toutes, mais beaucoup) ne sont pas basées sur des recherches sur l'amélioration des performances, mais sur des conclusions contraires - de la dégradation des performances. Par exemple, la BBC est beaucoup plus facile à affirmer qu '«ils perdent 10% des utilisateurs pour chaque seconde supplémentaire dont ils ont besoin pour charger leur site» que pour comprendre ce qui se passe grâce à une amélioration d'une seconde. Il est beaucoup plus facile de ralentir le site plutôt que de l'accélérer, et vous avez le sentiment que c'est pourquoi de nombreuses personnes font si bien ce travail.

Compte tenu de cela, je n'ai pas essayé de télécharger d'abord les sites qui utilisent Gzip, puis, hors ligne, de compresser leur contenu à l'aide de Brotli. Au lieu de cela, j'ai trouvé des sites qui utilisent Brotli, puis j'ai désactivé la compression. Je suis passé de Brotli à Gzip, puis de Gzip à la non-compression, mesurant comment cela fonctionne sur le site.

Bien que je ne puisse pas, par exemple, me connecter au serveur Linkedin et déconnecter Brotli, je peux simplement accéder à ce site à partir d'un navigateur qui ne prend pas en charge Brotli. Bien que je ne puisse pas désactiver la prise en charge de Brotli dans Chrome, je peux cacher au serveur le fait que mon navigateur prend en charge Brotli. Les navigateurs indiquent aux serveurs les algorithmes de compression qu'ils prennent en charge à l'aide de l'en-tête de demandecontent-encoding. En utilisant Webpagetest, je peux personnaliser les en-têtes moi-même. Donc, tout est très simple!

Les fonctionnalités avancées de WebPageTest nous permettent de définir des en-têtes de demande personnalisés.

Voici comment configurer le champ En-têtes personnalisés:

Arrêt complet de la compression: accept-encoding: randomstring.
Désactivation Brötli, mais gzip: accept-encoding: gzip.
Pour utiliser Brotli si cette méthode de compression est supportée par le site (et à condition qu'elle soit supportée par le navigateur): le champ reste vide.

Vous pouvez savoir si cela fonctionne comme prévu en vérifiant la présence (ou l'absence) de l'en-tête content-encodingdans la réponse du serveur.

résultats

Comme prévu, la transition du manque de compression vers Gzip signifiait une amélioration significative, mais la transition de Gzip à Brotli ne semble pas aussi impressionnante. Les données brutes de mes expériences peuvent être trouvées ici . Voici les constatations qui m'intéressent le plus:

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

Ce sont toutes des valeurs médianes. En parlant de «tailles de matériaux», je veux dire uniquement HTML, CSS et JavaScript.

Grâce à l'utilisation de Gzip, la taille des fichiers a été réduite de 73% par rapport à leurs versions non compressées. Et l'utilisation de Brotli n'a permis de réduire la taille des fichiers que de 5,7% supplémentaires. Si nous parlons de FCP, grâce à Gzip, cet indicateur s'est amélioré de 23% par rapport au manque de compression, et Brotli n'y a ajouté que 3,5% supplémentaires.

Bien qu'il semble que de tels résultats renforcent la théorie, il existe plusieurs façons d'améliorer ces résultats. La première consiste à tester un nombre beaucoup plus grand de sites, j'aimerais en discuter deux de plus en détail.

Données sur les ressources propres et données provenant de sources externes

Lors de mes tests, j'ai désactivé Brotli partout, et pas seulement pour les serveurs qui stockent les données du site. Cela signifie que j'ai mesuré non seulement les avantages que les sites retirent de l'utilisation de Brotli, mais, en termes de potentiel, les avantages que Brotli reçoit des sources externes utilisées par ces sites. Cela n'entre dans le champ de nos intérêts que si des ressources tierces sont utilisées de la manière critique des sites sous enquête, mais cela mérite d'être rappelé.

Niveaux de compression

En parlant de compression, nous discutons souvent des résultats obtenus avec le meilleur scénario d'application de compression. À savoir - lorsque vous utilisez Gzip, nous avons à l'esprit le 9e niveau de compression et lorsque vous utilisez Brotli - 11e niveau. Cependant, il est peu probable que le serveur étudié soit configuré de la manière la plus optimale. Par exemple, Apache utilise la compression gzip de niveau 6, tandis que NGINX utilise uniquement la première.

La désactivation de Brotli signifie que nous passons à l'option de secours, à Gzip, et compte tenu de la façon dont j'ai testé les sites, je ne pouvais pas changer une telle configuration de secours ou agir en quelque sorte. Je dis cela parce que les matériaux des deux sites du test ont augmenté de taille lorsque Brotli a été allumé. Cela m'indique que le niveau de compression Gzip était tel qu'il fournissait une compression plus forte que le niveau de compression Brotli.

Le choix d'un niveau de compression est un compromis. Tout le monde aimerait demander le niveau de compression le plus élevé et à ce propos, considérer le problème résolu. Mais une telle approche n'est pas pratique. Le fait est que le temps supplémentaire dont le serveur aura besoin pour effectuer dynamiquement cette compression est très susceptible d'annuler les avantages d'un niveau de compression plus élevé. Pour faire face à ce problème, vous pouvez recourir aux éléments suivants:

Vous pouvez utiliser un niveau de compression pragmatique qui offre le bon équilibre entre vitesse et efficacité pendant la compression dynamique des données.
Vous pouvez télécharger des ressources statiques précompressées sur le serveur, dont le niveau de compression est supérieur à celui utilisé pour la compression dynamique. Dans ce cas, pour sélectionner le niveau de compression dynamique, vous pouvez utiliser l'idée décrite dans le premier paragraphe.

Sommaire

On a l'impression que, raisonnablement, on peut reconnaître l'insignifiance des avantages de Brotli sur Gzip.

Si l'activation de la prise en charge de Brotli est une question de mouvements de souris dans le panneau de configuration de votre CDN, alors vous devriez prendre Brotli et l'activer maintenant. La prise en charge de cet algorithme de compression est suffisamment large, les navigateurs qui ne prennent pas en charge Brotli passent facilement à des mécanismes de rechange, et même une légère amélioration vaut mieux que rien.

Si possible, téléchargez des ressources statiques précompressées au niveau de compression maximal sur les serveurs. Et pour la compression dynamique, n'utilisez pas les niveaux de compression les plus élevés, mais pas les plus bas. Si vous utilisez NGINX, assurez-vous que vous n'utilisez pas le premier niveau de compression standard pour NGINX.

Cependant, si pour utiliser Brotli, vous pouvez avoir besoin de semaines de développement, de test et de déploiement, ne paniquez pas - assurez-vous simplement d'utiliser la compression Gzip pour tout ce qui peut être compressé (cela inclut, en plus des ressources textuelles, des fichiers .ico et .ttf - s'ils sont bien sûr utilisés dans votre projet).

Je suppose que la version courte de cet article peut ressembler à ceci: si vous ne devez pas ou ne pouvez pas activer Brotli, vous ne perdez pas autant.

Chers lecteurs! Envisagez-vous d'utiliser Brotli?

L'efficacité Brotli dans le monde réel