Compression

Introduction

La compression HTTP est une technique qui permet de coder des informations en utilisant moins de bits que la représentation originale. Lorsqu’elle est utilisée pour la diffusion de contenu web, elle permet aux serveurs web de réduire la quantité de données transmises aux clients. La compression HTTP augmente l’efficacité de la bande passante disponible au client, réduit le poids des pages, et améliore les performances web.

Les algorithmes de compression sont souvent classés comme avec ou sans perte :

• Lorsqu’un algorithme de compression avec perte est utilisé, le processus est irréversible et le fichier original ne peut pas être restauré par décompression. Cette méthode est couramment utilisée pour comprimer les ressources medias, comme les images et les contenus vidéo, lorsque la perte de certaines données n’affecte pas sensiblement la ressource.
• La compression sans perte est un processus entièrement réversible, et est couramment utilisée pour compresser les ressources textuelles, comme HTML, JavaScript, CSS, etc.

Dans ce chapitre, nous allons analyser comment le contenu textuel est compressé sur le web. L’analyse des contenus non textuels est traité dans le chapitre Media.

Comment fonctionne la compression HTTP

Lorsqu’un client effectue une requête HTTP, celle-ci comprend souvent un en-tête Accept-Encoding pour communiquer les algorithmes qu’il est capable de décoder. Le serveur peut alors choisir parmi eux un encodage qu’il prend en charge et servir la réponse compressée. La réponse compressée comprendra un en-tête Content-Encoding afin que le client sache quelle compression a été utilisée. En outre, l’en-tête Content-Type est souvent utilisé pour indiquer le type MIME de la ressource servie.

Dans l’exemple ci-dessous, le client indique supporter la compression Gzip, Brotli et deflate. Le serveur a décidé de renvoyer une réponse compressée avec Gzip contenant un document text/html.

    > GET / HTTP/1.1
    > Host: httparchive.org
    > Accept-Encoding: gzip, deflate, br

    < HTTP/1.1 200
    < Content-type: text/html; charset=utf-8
    < Content-encoding: gzip

HTTP Archive contient des mesures pour 5,3 millions de sites web, et chaque site a chargé au moins une ressource texte compressée sur sa page d’accueil. En outre, les ressources ont été compressées dans le domaine principal sur 81 % des sites web.

Algorithmes de compression

L’IANA tient à jour une liste des encodages de contenu HTTP valide qui peuvent être utilisés avec les en-têtes « Accept-Encoding » et « Content-Encoding ». On y retrouve notamment gzip, deflate, br (Brotli), ainsi que de quelques autres. De brèves descriptions de ces algorithmes sont données ci-dessous :

• Gzip utilise les techniques de compression LZ77 et le codage de Huffman qui sont plus ancienes que le web lui-même. Elles ont été développés à l’origine pour le programme gzip d’UNIX en 1992. Une implémentation pour la diffusion sur le web existe depuis HTTP/1.1, et la plupart des navigateurs et clients web la prennent en charge.
• Deflate utilise le même algorithme que Gzip, mais avec un conteneur différent. Son utilisation n’a pas été largement adoptée sur le web pour des raisons de compatibilité avec d’autres serveurs et navigateurs.
• Brotli est un algorithme de compression plus récent qui a été inventé par Google. Il utilise la combinaison d’une variante moderne de l’algorithme LZ77, le codage de Huffman et la modélisation du contexte du second ordre. La compression via Brotli est plus coûteuse en termes de calcul par rapport à Gzip, mais l’algorithme est capable de réduire les fichiers de 15-25 % de plus que la compression Gzip. Brotli a été utilisé pour la première fois pour la compression de contenu web en 2015 et est supporté par tous les navigateurs web modernes.

Environ 38 % des réponses HTTP sont fournies avec de la compression de texte. Cette statistique peut sembler surprenante, mais n’oubliez pas qu’elle est basée sur toutes les requêtes HTTP de l’ensemble de données. Certains contenus, tels que les images, ne bénéficieront pas de ces algorithmes de compression. Le tableau ci-dessous résume le pourcentage de requêtes servies pour chaque type de compression.

Parmi les ressources qui sont servies compressées, la majorité utilise soit Gzip (80 %), soit Brotli (20 %). Les autres algorithmes de compression sont peu utilisés.

Explorez les résultats

• Voir l'image

Diagramme circulaire du tableau de données de la figure 15.1.

De plus, il y a 67k requêtes qui renvoient un Content-Encoding invalide, tel que « none », « UTF-8 », « base64 », « text », etc. Ces ressources sont probablement servies sans compression.

Nous ne pouvons pas déterminer les niveaux de compression à partir des diagnostics recueillis par HTTP Archive, mais les bonnes pratiques pour compresser du contenu sont :

• Au minimum, activez le niveau 6 de compression Gzip pour les ressources textuelles. Cela permet un bon compromis entre le coût de calcul et le taux de compression, c’est la valeur par défaut pour de nombreux serveurs web. Toutefois Nginx utilise par défaut le niveau 1, c’est souvent trop bas.
• Si vous pouvez supporter Brotli et la précompression des ressources, alors compressez au niveau 11. Cette méthode est plus coûteuse en termes de calcul que Gzip - la précompression est donc absolument nécessaire pour éviter les délais.
• Si vous pouvez supporter le Brotli et que vous ne pouvez pas le précompresser, alors compressez au niveau 5. Ce niveau se traduira par un cout de compression plus petit que Gzip, avec un coût de calcul similaire.

Quels types de contenus compressons-nous ?

La plupart des ressources textuelles (telles que HTML, CSS et JavaScript) peuvent bénéficier de la compression Gzip ou Brotli. Cependant, il n’est souvent pas nécessaire d’utiliser ces techniques sur des ressources binaires, telles que les images, les vidéos et certaines polices Web, leurs formats de fichiers sont déjà compressés.

Dans le graphique ci-dessous, les 25 premiers types de contenus sont affichés sous forme de boîtes dont les dimensions représentent le nombre de requêtes correspondantes. La couleur de chaque boîte représente le nombre de ces ressources qui ont été servies compressées. La plupart des contenus médias sont nuancés en orange, ce qui est normal puisque Gzip et Brotli ne leur apporteraient que peu ou pas d’avantages. La plupart des contenus textuels sont nuancés en bleu pour indiquer qu’ils sont compressés. Cependant, la teinte bleu clair de certains types de contenu indique qu’ils ne sont pas compressés de manière aussi cohérente que les autres.

Explorez les résultats

• Voir l'image

Diagramme arborescent montrant les formats image/jpeg (167 912 373 requêtes - 3,23 % de compression), application/javascript (121 058 259 requêtes - 81,29 % de compression), image/png (113 530 400 requêtes - 3,81 % de compression), text/css (86 634 570 requêtes - 81,81 % de compression), text/html (81 975 252 requêtes - 43,44 % de compression), image/gif (70 838 761 requêtes - 3. 87 % de compression), text/javascript (60 645 767 demandes - 89,52 % de compression), application/x-javascript (38 816 387 demandes - 91,02 % de compression), font/woff2 (22 622 918 demandes - 3. 87 % de compression), application/json (16 501 326 demandes - 59,02 % de compression), image/webp (12 911 688 demandes - 1,66 % de compression), image/svg+xml (9 862 643 demandes - 64. 42 % de compression), text/plain (6.622.361 demandes - 24,72 % de compression), application/octet-stream (3.884.287 demandes - 6,01 % de compression), image/x-icon (3 737 030 demandes - 37. 60 % de compression), application/font-woff2 (3.061.857 demandes - 5,90 % de compression), application/font-woff (2 117 999 demandes - 23,61 % de compression), image/vnd.microsoft.icon (1.774.995 demandes - 15. 55 % de compression), video/mp4 (1 472 880 requêtes - 0,03 % de compression), font/woff (1 255 093 requêtes - 24,33 % de compression), font/ttf (1 062 747 requêtes - 84. 27 % de compression), application/x-font-woff (1 048 398 demandes - 30,77 % de compression), image/jpg (951 610 demandes - 6,66 % de compression), application/ocsp-response (883 603 demandes - 0,00 % de compression).

La sélection des huit types de contenus les plus populaires nous permet de voir plus clairement les tendances de compression de ces types de contenus.

Explorez les résultats

• Voir l'image

Diagramme arborescent montrant les polices/woff2 (22 622 918 demandes - 3,87 % de compression), application/json (16 501 326 demandes - 59,02 % de compression), image/webp (12 911 688 demandes - 1,66 % de compression), image/svg+xml (9 862 643 demandes - 64. 42 % de compression), text/plain (6 622 361 demandes - 24,72 % de compression), application/octet-stream (3 884 287 demandes - 6,01 % de compression), image/x-icon (3 737 030 demandes - 37,60 % de compression), application/font-woff2 (3 061 857 demandes - 5. 90 % de compression), application/font-woff (2 117 999 requêtes - 23,61 % de compression), image/vnd.microsoft.icon (1 774 995 requêtes - 15,55 % de compression), video/mp4 (1 472 880 requêtes - 0,03 % de compression), font/woff (1 255 093 requêtes - 24. 33 % de compression), font/ttf (1 062 747 demandes - 84,27 % de compression), application/x-font-woff (1 048 398 demandes - 30,77 % de compression), image/jpg (951 610 demandes - 6,66 % de compression), application/ocsp-response (883 603 demandes - 0,00 % de compression)

Les types de contenus application/json et image/svg+xml sont compressés moins de 65 % du temps.

La majeure partie des polices web customisées sont servies sans compression, car elles sont déjà dans un format compressé. Cependant, font/ttf est compressible, mais seulement 84 % des requêtes de polices TTF sont servies avec compression, il y a donc encore des possibilités d’amélioration dans ce domaine.

Les graphiques ci-dessous illustrent la répartition des techniques de compression utilisées pour chaque type de contenu. En examinant les trois premiers types de contenus, on constate que, tant sur les ordinateurs de bureau que sur les téléphones portables, il existe des écarts importants dans la compression de certains des types de contenus les plus fréquemment demandés. 56 % des ressources texte/html ainsi que 18 % des ressources application/javascript et text/css ne sont pas compressées. Cela représente une opportunité de performance significative.

Explorez les résultats

• Voir l'image

Le graphique à barres empilées montrant l’application/javascript est de 36,18 M/8,97 M/10,47 M par type de compression (Gzip/Brotli/None), text/css est de 24,29 M/8,31 M/7,20 M, text/html est de 11,37 M/4,89 M/20,57 M, text/javascript est de 23,21 M/1,72 M/3,03 M, application/x-javascript est de 11. 86 M/4,97 M/1,66 M, application/json est 4,06 M/0,50 M/3,23 M, image/svg+xml est 2,54 M/0,46 M/1,74 M, text/plain est 0,71 M/0,06 M/2,42 M, et image/x-icon est 0,58 M/0,10 M/1,11 M. Deflate n’est presque jamais utilisé à aucun moment et ne s’inscrit pas sur la carte.

Explorez les résultats

• Voir l'image

Le graphique à barres empilées montrant l’application/javascript est de 43,07 M/10,17 M/12,19 M par type de compression (Gzip/Brotli/None), text/css est de 28,3 M/9,91 M/8,56 M, text/html est de 13,86 M/5,48 M/25,79 M, text/javascript est de 27. 41 M/1,94 M/3,33 M, application/x-javascript est 12,77 M/5,70 M/1,82 M, application/json est 4,67 M/0,50 M/3,53 M, image/svg+xml est 2,91 M/ 0,44 M/1,77 M, text/plain est 0,80 M/0,06 M/1,77 M, et image/x-icon est 0,62 M/0,11 M/1,22M. La fonction Deflate n’est presque jamais utilisée et ne s’inscrit pas sur la carte.

Les types de contenus ayant les taux de compression les plus faibles sont application/json, texte/xml et text/plain. Ces ressources sont couramment utilisées pour les requêtes XHR afin de fournir des données que les applications web peuvent utiliser pour créer des expériences riches. Leur compression améliorera certainement l’expérience de l’utilisateur. Les graphiques vectoriels tels que image/svg+xml et image/x-icon ne sont pas souvent considérés comme du texte, mais ils le sont et les sites qui les utilisent bénéficieraient de la compression.

Explorez les résultats

• Voir l'image

Le graphique à barres empilées montrant l’application/javascript est de 65,1 %/16,1 %/18,8 % par type de compression (Gzip/Brotli/None), text/css est de 61,0 %/20,9 %/18,1 %, text/html est de 30,9 %/13,3 %/55,8 %, text/javascript est de 83,0 %/6. 1 %/10,8 %, application/x-javascript est de 64,1 %/26,9 %/9,0 %, application/json est de 52,1 %/6,4 %/41,4 %, image/svg+xml est de 53,5 %/9,8 %/36,7 %, text/plain est de 22,2 %/2,0 %/75,8 %, et image/x-icon est de 32,6 %/5,3 %/62,1 %. Deflate n’est presque jamais utilisé et ne s’inscrit pas sur le graphique.

Explorez les résultats

• Voir l'image

Le graphique à barres empilées montrant l’application/javascript est de 65,8 %/15,5 %/18,6 % par type de compression (Gzip/Brotli/None), text/css est de 60,5 %/21,2 %/18,3 %, text/html est de 30,7 %/12,1 %/57,1 %, text/javascript est de 83,9 %/5. 9 %/10,2 %, application/x-javascript est 62,9 %/28,1 %/9,0 %, application/json est 53,6 %/8,6 %/34,6 %, image/svg+xml est 23,4 %/1,8 %/74,8 %, text/plain est 23,4 %/1,8 %/74,8 %, et image/x-icon est 31,8 %/5,5 %/62,7 %. Deflate n’est presque jamais utilisé et ne s’inscrit pas sur le graphique.

Dans tous les types de contenus, Gzip est l’algorithme de compression le plus populaire. La compression Brotli, plus récente, est utilisée moins fréquemment, et les types de contenus où elle apparaît le plus sont application/javascript, text/css et application/x-javascript. Cela est probablement dû aux CDN qui appliquent automatiquement la compression Brotli pour le trafic qui y transite.

Compression de première partie et tierce partie

Dans le chapitre les tierces parties, nous avons appris le rôle des tiers et leur impact sur les performances. Lorsque nous comparons les techniques de compression entre les premières et les tierces parties, nous pouvons constater que le contenu des tierces parties a tendance à être plus compressé que le contenu des premières parties.

En outre, le pourcentage de compression Brotli est plus élevé pour les contenus tiers. Cela est probablement dû au nombre de ressources servies par les grands tiers qui soutiennent généralement le Brotli, comme Google et Facebook.

Identifier les possibilités de compression

L’outil Google Lighthouse permet aux utilisateurs d’effectuer une série d’audits sur les pages web. L’audit de la compression de texte évalue si un site peut bénéficier d’une compression de texte supplémentaire. Pour ce faire, il tente de comprimer les ressources et évalue si la taille d’un objet peut être réduite d’au moins 10 % et de 1 400 octets. En fonction du score, vous pouvez voir une recommandation de compression dans les résultats, avec une liste de ressources spécifiques qui pourraient être compressées.

Explorez les résultats

• Voir l'image

Une capture d’écran d’un rapport Lighthouse montrant une liste de ressources (avec les noms flouté) et montrant la taille et l’économie potentielle. Pour le premier élément, il y a une économie potentiellement importante de 91 KB à 73 KB, tandis que pour d’autres fichiers plus petits de 6 KB ou moins, il y a une économie plus faible de 4 KB à 1 KB.

Comme HTTP Archive effectue des audits Lighthouse pour chaque page mobile, nous pouvons agréger les scores de tous les sites pour savoir dans quelle mesure il est possible de compresser davantage le contenu. Dans l’ensemble, 62 % des sites web ont réussi cet audit et près de 23 % des sites web ont obtenu une note inférieure à 40. Cela signifie que plus de 1,2 million de sites web pourraient bénéficier d’une compression du texte supplémentaire.

Explorez les résultats

• Voir l'image

Diagramme à barres empilées montrant que 7,6 % des sites coûtent moins de 10 %, 13,2 % des sites ont un score compris entre 10 et 39 %, 13,7 % des sites ont un score compris entre 40 et 79 %, 2,9 % des sites ont un score compris entre 80 et 99 %, et 62,5 % des sites ont un laissez-passer avec plus de 100 % des textes compressés.

Lighthouse indique également combien d’octets pourraient être économisés en permettant la compression du texte. Parmi les sites qui pourraient bénéficier de la compression de texte, 82 % d’entre eux peuvent réduire le poids de leur page de 1 Mo !

Explorez les résultats

• Voir l'image

Diagramme à barres empilées montrant que 82,11 % des sites pourraient économiser moins de 1 Mo, 15,88 % des sites pourraient économiser 1 - 2 Mo et 2 % des sites pourraient économiser > 3 Mo.<

Conclusion

La compression HTTP est une fonctionnalité très utilisée et très précieuse pour réduire la taille des contenus web. La compression Gzip et Brotli sont les deux algorithmes les plus utilisés, et la quantité de contenu compressé varie selon le type de contenu. Des outils comme Lighthouse peuvent aider à découvrir des solutions pour comprimer le contenu.

Bien que de nombreux sites fassent bon usage de la compression HTTP, il y a encore des possibilités d’amélioration, en particulier pour le format text/html sur lequel le web est construit ! De même, les formats de texte moins bien compris comme font/ttf, application/json, text/xml, text/plain, image/svg+xml, et image/x-icon peuvent nécessiter une configuration supplémentaire qui manque à de nombreux sites web.

Au minimum, les sites web devraient utiliser la compression Gzip pour toutes les ressources textuelles, car elle est largement prise en charge, facile à mettre en œuvre et a un faible coût de traitement. Des économies supplémentaires peuvent être réalisées grâce à la compression Brotli, bien que les niveaux de compression doivent être choisis avec soin en fonction de la possibilité de précompression d’une ressource.