Tout au long de la Speed Week, nous avons parlé de l'importance de l'optimisation des performances. La compression joue un rôle crucial en réduisant la taille des fichiers transmis via Internet. La réduction de la taille des fichiers permet des téléchargements plus rapides, accélère le chargement des sites web et offre une meilleure expérience utilisateur.
Prenons l'exemple d'un produit d'entretien ménager. On estime « qu'une bouteille de produit nettoyant habituel contient 90 % d'eau et moins de 10 % d'ingrédients utiles. » Si l'on retire 90 % d'un flacon de 500 ml de nettoyant ménager, on réduit de 600 g à 60 g le poids du flacon. Grâce à cette réduction, il suffit d'expédier à l'utilisateur un colis de 60 g seulement, avec des instructions expliquant comment réhydrater le produit à réception. Si l'on extrapole cet exemple à l'échelle de litres de produit, cette réduction de poids se traduit rapidement, pour le fabricant, par des économies considérables sur les frais d'expédition, sans parler de l'impact sur l'environnement.
C'est ainsi que fonctionne la compression. L'expéditeur compresse le fichier jusqu'à ce que sa taille soit aussi réduite que possible, puis il transmet le fichier, devenu plus petit, avec des instructions concernant son traitement à réception. En réduisant la taille des fichiers envoyés, la compression permet de réduire considérablement la bande passante nécessaire à l'envoi de fichiers via Internet. Lorsque les fichiers sont stockés chez d'onéreux fournisseurs de cloud tels qu'AWS, la réduction de la taille des fichiers envoyés peut directement se traduire par des économies de bande passante considérables.
La réduction de la taille des fichiers s'avère également particulièrement avantageuse pour les utilisateurs finaux disposant d'une connexion Internet limitée, à l'image des appareils mobiles connectés aux réseaux cellulaires ou des utilisateurs résidant dans des zones desservies par un réseau à faible débit.
Cloudflare a toujours pris en charge la compression au format Gzip. Gzip est un algorithme de compression très répandu, qui existe depuis 1992 et assure la compression des fichiers pour tous les utilisateurs de Cloudflare. En 2013, toutefois, Google a inauguré Brotli, qui prend en charge des niveaux de compression plus élevés et offre de meilleures performances globales. La transition de Gzip vers Brotli permet de réduire la taille des fichiers et les temps de chargement des pages web. Nous prenons en charge Brotli depuis 2017 pour la connexion entre Cloudflare et les navigateurs des clients. Nous annonçons aujourd'hui la prise en charge intégrale de Brotli pour les contenus web, c'est-à-dire la prise en charge de la compression Brotli, aux niveaux les plus élevés possibles, depuis le serveur d'origine jusqu'au client.
Si votre serveur d'origine prend en charge Brotli, activez la fonctionnalité, augmentez le niveau de compression et profitez de l'augmentation des performances.
Compression Brotli jusqu'au niveau 11
Brotli propose 12 niveaux de compression, allant de 0 à 11 ; le niveau 0 offrant la compression la plus rapide, mais également le taux de compression le plus faible, tandis que le niveau 11 offre le taux de compression le plus élevé, mais demande davantage de ressources informatiques et de temps. Lors de la mise en œuvre initiale de Brotli, il y a cinq ans de cela, nous avons constaté que la compression au niveau 4 offrait un équilibre entre les octets économisés et le temps de compression, sans compromettre les performances.
Depuis 2017, Cloudflare utilise une compression Brotli maximale de niveau 4 pour toutes les ressources compressibles, en fonction de l'en-tête Accept-Encoding de l'utilisateur final. Cependant, un problème demeurait : Cloudflare demandait uniquement la compression Gzip au serveur d'origine, même si celui-ci prenait en charge Brotli. Par ailleurs, Cloudflare décompressait toujours les contenus reçus du serveur d'origine avant de les compresser et de les transmettre à l'utilisateur final, ce qui entraînait une augmentation du temps de traitement. Par conséquent, les clients ne pouvaient pas pleinement tirer parti des avantages qu'offre la compression Brotli.
L'ancien monde
Suite au déploiement de la prise en charge intégrale de Brotli par Cloudflare, les clients commenceront à recevoir notre en-tête Accept-Encoding mis à jour sur leurs serveurs d'origine. Lorsque cet en-tête sera disponible, les clients pourront transférer, mettre en cache et servir directement vers Cloudflare des fichiers Brotli fortement compressés, jusqu'au niveau maximum de 11, ce qui permettra de réduire la latence et la consommation de bande passante. Si l'appareil d'un utilisateur final ne prend pas en charge la compression Brotli, nous décompresserons automatiquement le fichier et le servirons soit dans son format décompressé, soit sous forme de fichier compressé Gzip, en fonction de l'en-tête Accept-Encoding.
Prise en charge de la compression Brotli de bout en bout
L'appareil de l'utilisateur final ne prend pas en charge la compression Brotli
Les clients peuvent mettre en œuvre la compression Brotli sur leur serveur d'origine en se référant aux documents en ligne appropriés. Par exemple, les clients qui utilisent NGINX peuvent mettre en œuvre Brotli en suivant ce tutoriel et en configurant la compression au niveau 11 dans le fichier de configuration `nginx.conf`, comme indiqué ici :
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 servira alors ces ressources au client en utilisant exactement le même niveau de compression (11) pour le fichier brotli_types correspondant. Cela signifie que toutes les images au format SVG ou BMP seront transmises au client après compression au niveau 11 de Brotli.
Test
Nous avons appliqué la compression à un simple fichier CSS, en mesurant l'impact de différents algorithmes et niveaux de compression. Notre objectif était d'identifier les améliorations potentielles que pourrait offrir l'optimisation des techniques de compression aux utilisateurs. Ces résultats sont présentés dans le tableau suivant :
| test | Taille (octets) | % de réduction du fichier original (un % plus élevé est meilleur) |
|---|---|---|
| Réponse non compressée (aucune compression utilisée) | 2 747 | , |
| Compression Gzip (niveau 8) par défaut de Cloudflare | 1 121 | 59,21 % |
| Compression Brotli (niveau 4) par défaut de Cloudflare | 1 110 | 59,58 % |
| Compression avec Gzip, niveau max. (niveau 9) | 1 121 | 59,21 % |
| Compression avec Brotli, niveau max. (niveau 11) | 909 | 66,94 % |
L'utilisation de la compression Brotli au niveau 11 permet aux utilisateurs de réduire de 19 % la taille des fichiers par rapport au meilleur niveau de compression Gzip. En outre, le niveau maximal de compression Brotli permet d'obtenir une taille de fichier inférieure d'environ 18 % à celle offerte par le niveau par défaut utilisé par Cloudflare. Ces résultats révèlent que l'utilisation de la compression Brotli permet une réduction significative de la taille des fichiers, notamment aux niveaux les plus élevés, ce qui peut conduire à une amélioration des performances du site web, à une diminution des temps de chargement des pages et à une réduction globale des frais de trafic sortant.
Pour obtenir de taux de compression de bout en bout plus élevés, les fonctions suivantes du proxy Cloudflare doivent être désactivées :
- obscurcissement de l'adresse e-mail
- Rocket Loader
- Server Side Excludes (SSE)
- Mirage
- Minimisation HTML – JavaScript et CSS peuvent rester actifs.
- Réécritures HTTPS automatiques
En effet, Cloudflare doit décompresser le corps d'une réponse et accéder à celui-ci pour appliquer les paramètres demandés. À l'aide de Configuration Rules, le client peut également désactiver ces fonctionnalités pour des chemins spécifiques.
Si l'une de ces fonctionnalités de réécriture est activée, le serveur d'origine peut toujours transmettre des données utilisant la compression Brotli à des niveaux plus élevés. Cependant, nous décompresserons les données, appliquerons les fonctionnalités Cloudflare activées et recompresserons les données à la volée au niveau 4 de compression Brotli (c'est-à-dire au niveau par défaut utilisé par Cloudflare) ou au niveau 8 de Gzip, en fonction de l'en-tête Accept-Encoding de l'utilisateur.
Pour les navigateurs qui n'acceptent pas la compression Brotli, nous continuerons à décompresser et transmettre des réponses avec la compression Gzip ou sans aucune compression.
Mise en œuvre
La première étape de la mise en œuvre de la compression Brotli depuis le serveur d'origine a impliqué la construction d'un module de décompression pouvant être intégré dans la pile logicielle de Cloudflare. Celui-ci nous permet de convertir efficacement les bits compressés reçus depuis le serveur d'origine en fichier original non compressé. Cette étape était cruciale, car de nombreuses fonctionnalités, telles que la dissimulation des adresses e-mail et Cloudflare Workers Customers, reposent sur l'accès au corps d'une réponse pour l'application des personnalisations.
Nous avons intégré le module de décompression au proxy web inverse central de Cloudflare. Cette intégration permet à l'ensemble des produits et fonctionnalités de Cloudflare d'accéder facilement à la fonctionnalité de décompression Brotli ; elle a également permis à notre équipe Cloudflare Workers d'incorporer Brotli directement dans Cloudflare Workers, et permet ainsi à nos clients Workers d'interagir avec les réponses renvoyées avec la compression Brotli ou de les transmettre sans modification à l'utilisateur final.
Présentation de Compression Rules – Contrôle granulaire de la compression des données transmises aux utilisateurs finaux
Par défaut, Cloudflare compresse certains types de contenu, en fonction de l'en-tête Content-Type du fichier. Aujourd'hui, nous annonçons également Compression Rules pour nos clients Entreprise, qui vous permet de mieux contrôler le choix et la méthode de compression des données par Cloudflare.
Aujourd'hui, nous annonçons également l'introduction de Compression Rules pour nos clients Entreprise. Avec Compression Rules, vous bénéficiez d'un contrôle renforcé sur les capacités de compression de Cloudflare, vous permettant de personnaliser le choix des contenus et la méthode de compression utilisée par Cloudflare, afin d'optimiser les performances de votre site web.
Par exemple, en utilisant le service Compression Rules de Cloudflare pour les fichiers .ktx, les clients peuvent optimiser la mise en œuvre de textures dans les applications webGL, améliorant ainsi l'expérience utilisateur globale. L'activation de la compression minimise la consommation de bande passante et garantit le chargement rapide et fluide des applications WebGL, même en présence de textures volumineuses et détaillées.
Les clients peuvent également désactiver la compression ou spécifier leur préférence quant à la compression utilisée par Cloudflare. Un autre exemple pourrait être celui d'une société d'infrastructure souhaitant uniquement prendre en charge Gzip pour ses appareils IdO, mais souhaitant également autoriser la compression Brotli pour tous les autres noms d'hôte.
Compression Rules utilise les filtres sur lesquels sont basés nos autres produits Rules, avec les champs supplémentaires Media Type et Extension Type. Les utilisateurs peuvent ainsi facilement spécifier le contenu qu'ils souhaitent compresser.
Dépréciation de la fonction d'activation/de désactivation de Brotli
Brotli est pris en charge par certains navigateurs web depuis 2016, et Cloudflare propose la prise en charge de Brotli depuis 2017. À l'instar de toutes les nouvelles technologies web, Brotli était inconnu, et nous avons offert aux clients la possibilité d'activer ou de désactiver sélectivement Brotli via l'API et notre interface utilisateur.
Maintenant que la compression Brotli a évolué et est prise en charge par tous les navigateurs, nous prévoyons d'activer Brotli sur toutes les zones par défaut dans les mois à venir. Cette évolution reprendra le comportement de Gzip que nous prenons actuellement en charge et entraînera la suppression de la fonction d'activation/de désactivation de notre tableau de bord. Si les navigateurs ne prennent pas en charge Brotli, Cloudflare continuera à prendre en charge les types d'encodage acceptés, tels que Gzip ou les données non compressées, et les clients Enterprise pourront toujours utiliser Compression Rules pour bénéficier d'un contrôle granulaire de la compression des données transmises à leurs utilisateurs.
L'avenir de la compression web
Nous avons constaté que Brotli, utilisé en tant que nouvelle technique de compression dédiée au web, a bénéficié d'une large adoption et a donné d'excellents résultats. Pour l'avenir, nous suivons de près les tendances et les nouveaux algorithmes de compression tels que zstd, qui pourrait constituer la prochaine génération d'algorithmes de compression.
Dans le même temps, nous cherchons à améliorer Brotli directement là où nous le pouvons. Un développement sur lequel nous nous concentrons particulièrement est celui des dictionnaires partagés avec Brotli. Chaque fois que vous comprimez une ressource, vous utilisez un « dictionnaire » qui améliore l'efficacité de la compression. Une analogie simple est la saisie des premières lettres de l'expression « J'arrive bientôt » (par exemple, « J'arr ») dans un message sur iPhone. L'iPhone traduit automatiquement cette saisie en « J'arrive bientôt » à l'aide de son propre dictionnaire interne.
| O | M | W | ||||||
|---|---|---|---|---|---|---|---|---|
| O | n | M | y | W | a | y |
Ce dictionnaire interne a analysé quatre caractères et les a transformés en seize caractères (espaces inclus). Le dictionnaire interne a ainsi économisé douze caractères, ce qui se traduit par de meilleures performances pour les utilisateurs.
Par défaut, le document RFC Brotli définit un dictionnaire statique, utilisé par les clients et les serveurs d'origine. Le dictionnaire statique a été conçu pour être d'usage général et applicable à tous les utilisateurs. La taille du dictionnaire a été optimisée, afin qu'il ne soit pas excessivement volumineux, tout en permettant d'obtenir les meilleurs résultats en matière de compression. Mais que se passerait-il si un serveur d'origine pouvait générer un dictionnaire sur mesure, adapté à un site web spécifique ? Par exemple, un dictionnaire spécifique à Cloudflare nous permettrait de compresser les mots et les phrases qui apparaissent à plusieurs reprises sur notre site, à l'image du mot « Cloudflare ». Le dictionnaire sur mesure serait conçu pour compresser ces mots aussi fortement que possible, et le navigateur utilisant le même dictionnaire serait en mesure de les traduire.
C'est précisément ce que vise à mettre en œuvre une nouvelle proposition formulée par la communauté Web Incubator CG, en vous permettant de spécifier vos dictionnaires, que les navigateurs pourront ensuite utiliser pour permettre aux sites web d'optimiser davantage la compression. Nous sommes ravis de contribuer à cette proposition et prévoyons de publier prochainement nos recherches.
Essayer maintenant
Compression Rules est disponible maintenant ! La compression Brotli de bout en bout sera, quant à elle, déployée dans les semaines à venir. Elle vous permettra d'améliorer les performances, de réduire la bande passante et de bénéficier d'un contrôle granulaire de la façon dont Cloudflare gère la compression des données transmises à vos utilisateurs finaux.