Optimiser la taille d'encodage et de transfert des éléments textuels

En plus d'éliminer les téléchargements de ressources inutiles, la meilleure chose à faire pour améliorer la vitesse de chargement des pages est de réduire la taille globale des téléchargements en optimisant et en compressant les ressources restantes.

Présentation de la compression des données

Une fois que vous avez configuré votre site Web pour éviter de télécharger des ressources inutilisées, l'étape suivante consiste à compresser les ressources éligibles restantes que le navigateur doit télécharger. Selon le type de ressource (texte, images, polices, etc.), vous pouvez choisir parmi de nombreuses techniques : outils génériques pouvant être activés sur le serveur Web, optimisations de prétraitement pour des types de contenu spécifiques et optimisations spécifiques aux ressources qui nécessitent une intervention du développeur.

Pour obtenir les meilleures performances, vous devez combiner toutes les techniques suivantes :

  • La compression est le processus d'encodage des informations à l'aide de moins de bits.
  • L'élimination des données inutiles donne toujours les meilleurs résultats.
  • Il existe de nombreuses techniques et algorithmes de compression.
  • Vous aurez besoin de différentes techniques pour obtenir la meilleure compression.

Le processus de réduction de la taille des données est la compression des données. Usage général, optimisé pour le calcul, optimisé pour la mémoire et optimisé pour les accélérateurs.

Une discussion complète sur la compression des données dépasse largement le cadre de ce guide. Toutefois, il est important de comprendre, à un niveau élevé, le fonctionnement de la compression et les techniques que vous pouvez utiliser pour réduire la taille des différents éléments requis par vos pages.

Pour expliquer les principes de base de ces techniques, prenons l'exemple d'un format tout simple contenant un message sous forme de texte, et voyons comment l'optimiser.

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
  1. Les messages peuvent contenir des annotations arbitraires, parfois appelées commentaires, qui sont indiquées par le préfixe "#". Les annotations n'affectent pas la signification du message ni son comportement.
  2. Les messages peuvent contenir des en-têtes, qui sont des paires clé-valeur (séparées par ":" dans l'exemple précédent) qui apparaissent au début du message.
  3. Les messages transportent des charges utiles textuelles.

Que peut-on faire pour réduire la taille du message précédent, qui commence à 200 caractères ?

  1. Le commentaire est intéressant, mais il n'affecte pas le sens du message. Éliminez-le lors de la transmission du message.
  2. Il existe de bonnes techniques pour encoder les en-têtes de manière efficace. Par exemple, si vous savez que tous les messages ont un "format" et une "date", vous pouvez les convertir en ID d'entiers courts et les envoyer. Toutefois, cela n'est peut-être pas vrai. Il est donc préférable de ne pas y toucher pour le moment.
  3. La charge utile est du texte uniquement. Bien que nous ne sachions pas ce que contient réellement ce fichier (apparemment, il utilise un "secret-cipher"), le simple fait de regarder le texte montre qu'il contient beaucoup de redondance. Au lieu d'envoyer des lettres répétées, vous pouvez simplement compter le nombre de lettres répétées et les encoder plus efficacement. Par exemple, "AAA" devient "3A", qui représente une séquence de trois A.

La combinaison de ces techniques produit le résultat suivant :

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

Le nouveau message comporte 56 caractères, ce qui signifie que vous avez compressé le message d'origine de 72 %. C'est une réduction significative !

Il s'agit d'un exemple simple de l'efficacité des algorithmes de compression pour réduire la taille de transfert des ressources textuelles. En pratique, les algorithmes de compression sont bien plus sophistiqués que l'exemple précédent ne l'illustre. Sur le Web, les algorithmes de compression peuvent être utilisés pour réduire considérablement les temps de téléchargement des ressources. En appliquant la compression aux éléments textuels, une page Web peut passer moins de temps à charger les ressources. Les utilisateurs peuvent ainsi voir les effets de ces ressources plus rapidement que sans compression.

Minimisation : prétraitement et optimisations spécifiques au contexte

La première technique abordée ici est la minimisation. Bien que la minimisation ne soit pas strictement un algorithme de compression, elle permet de supprimer les caractères inutiles et redondants utilisés dans le code source pour rendre les ressources plus lisibles pour les humains. Toutefois, cette lisibilité n'est pas nécessaire pour maintenir la fonctionnalité de ce code source sur les sites Web de production et peut retarder le chargement des ressources sur le Web.

La minimisation est un type d'optimisation spécifique au contenu qui peut réduire considérablement la taille des ressources diffusées. Les optimisations sont mieux appliquées dans le cadre de votre processus de compilation et de déploiement. Par exemple, les bundlers sont un type de logiciel couramment utilisé qui peut minimiser automatiquement les ressources juste avant le déploiement d'un nouveau code de production sur un site Web.

Le meilleur moyen de compresser des données redondantes ou inutiles est de les éliminer. Cependant, vous ne pouvez pas supprimer des données arbitraires. Cependant, dans certains contextes où nous disposons de connaissances spécifiques au contenu sur le format des données et ses propriétés, il est possible de réduire considérablement la taille de la charge utile sans affecter sa signification ou ses capacités réelles.

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

Prenons l'extrait HTML précédent et les trois types de contenu différents qu'il contient :

  1. Balisage HTML.
  2. CSS pour personnaliser la présentation d'une page.
  3. JavaScript pour optimiser les interactions et d'autres fonctionnalités avancées de la page.

Chacun de ces types de contenu est soumis à des règles différentes concernant ce qui constitue un contenu valide, la spécification des commentaires, etc. La question qui se pose est la suivante : "Comment réduire la taille de cette page ?"

  • Les commentaires de code sont les meilleurs amis des développeurs, mais le navigateur n'en a pas besoin. La suppression des commentaires CSS (/* ... */), HTML (<!-- ... -->) et JavaScript (// ...) réduit la taille totale de transfert de la page et de ses sous-ressources.
  • Un compresseur CSS "intelligent" peut remarquer que nous utilisons une méthode inefficace pour définir des règles pour .awesome-container et réduire les deux déclarations en une seule sans affecter les autres styles, ce qui permet d'économiser plus d'octets. Sur un grand ensemble de règles CSS, la suppression de ce type de redondance peut s'accumuler, mais il n'est pas toujours possible de l'appliquer de manière agressive, car les sélecteurs sont souvent nécessairement dupliqués dans différents contextes, par exemple dans les requêtes média.
  • Les espaces et les tabulations sont des éléments pratiques pour les développeurs en HTML, CSS et JavaScript. Un compresseur supplémentaire pourrait supprimer toutes les tabulations et tous les espaces. Contrairement à d'autres techniques de déduplication, ce type d'optimisation peut être appliqué de manière assez agressive, tant que ces espaces ou tabulations ne sont pas nécessaires à la présentation de la page. Par exemple, vous devez conserver les espaces dans les séquences de texte d'un document HTML, car ils garantissent la lisibilité du contenu que les utilisateurs verront réellement.
<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

Après avoir appliqué les étapes précédentes, la page passe de 516 à 204 caractères, ce qui représente une économie d'environ 60 %. Certes, il n'est pas très lisible, mais il n'a pas besoin de l'être pour être utilisable. Les pratiques de développement modernes vous permettent également de séparer les versions bien formatées et lisibles de votre code source du code bien optimisé que vous déployez en production. Combiné aux cartes sources, qui fournissent une représentation lisible de votre code de production transformé, vous pouvez résoudre plus facilement les bugs en production. Vous pouvez ainsi bénéficier d'une bonne expérience de développement tout en optimisant les performances pour l'expérience utilisateur.

L'exemple précédent illustre un point important : un compresseur à usage général (par exemple, un compresseur conçu pour compresser du texte arbitraire) pourrait compresser la page de l'exemple précédent de manière satisfaisante, mais il ne saurait jamais supprimer les commentaires, réduire les règles CSS ou effectuer des dizaines d'autres optimisations spécifiques au contenu. C'est pourquoi le prétraitement, la minimisation et d'autres optimisations contextuelles sont importants.

De même, les techniques décrites ci-dessus peuvent être étendues au-delà des composants textuels. Les images, les vidéos et les autres types de contenu contiennent tous leurs propres formes de métadonnées et diverses charges utiles. Par exemple, chaque fois que vous prenez une photo avec un appareil photo, son fichier intègre généralement de nombreuses informations supplémentaires : paramètres de l'appareil photo, position, etc. Selon votre application, ces données peuvent être essentielles (par exemple, un site de partage de photos) ou complètement inutiles. Vous devriez envisager de le supprimer. En pratique, ces métadonnées peuvent ajouter jusqu'à des dizaines de kilo-octets pour chaque image.

En résumé, pour optimiser l'efficacité de vos éléments, commencez par dresser un inventaire des différents types de contenus et réfléchissez aux optimisations spécifiques que vous pouvez appliquer pour réduire leur taille. Ensuite, une fois que vous les avez identifiées, automatisez ces optimisations en les ajoutant à vos étapes de compilation et de publication pour vous assurer qu'elles sont appliquées de manière cohérente pour chaque nouvelle version en production.

Compression de texte avec des algorithmes de compression

L'étape suivante pour réduire la taille des éléments textuels consiste à leur appliquer un algorithme de compression. Cette méthode va encore plus loin en recherchant de manière agressive des modèles répétables dans les charges utiles textuelles avant de les envoyer à l'utilisateur, puis en les décompressant une fois qu'elles arrivent dans le navigateur de l'utilisateur. Cela permet de réduire encore davantage et de manière significative ces ressources, et donc d'accélérer les temps de téléchargement.

  • gzip et Brotli sont des algorithmes de compression couramment utilisés qui fonctionnent mieux sur les éléments textuels : CSS, JavaScript, HTML.
  • Tous les navigateurs récents sont compatibles avec la compression gzip et Brotli, et annoncent cette compatibilité dans l'en-tête de requête HTTP Accept-Encoding.
  • Votre serveur doit être configuré pour activer la compression. Le logiciel serveur Web active souvent des modules pour compresser les ressources textuelles par défaut.
  • Gzip et Brotli peuvent être ajustés pour améliorer les taux de compression en modifiant le niveau de compression. Pour gzip, les paramètres de compression vont de 1 à 9, 9 étant le meilleur. Pour Brotli, cette plage est comprise entre 0 et 11, 11 étant la meilleure valeur. Toutefois, des paramètres de compression plus élevés nécessitent plus de temps. Pour les ressources compressées de manière dynamique (c'est-à-dire au moment de la requête), les paramètres situés au milieu de la plage ont tendance à offrir le meilleur compromis entre taux de compression et vitesse. Toutefois, la compression statique est possible. Dans ce cas, la réponse est compressée à l'avance et peut donc utiliser les paramètres de compression les plus agressifs disponibles pour chaque algorithme de compression.
  • Les réseaux de diffusion de contenu (CDN) proposent généralement une compression automatique des ressources éligibles. Les CDN peuvent également gérer la compression dynamique et statique pour vous, ce qui vous évite d'avoir à vous en soucier.

gzip et Brotli sont des compresseurs courants qui peuvent être appliqués à n'importe quel flux d'octets. En arrière-plan, ils mémorisent une partie du contenu d'un fichier précédemment examiné, puis tentent de trouver et de remplacer les fragments de données en double de manière efficace.

En pratique, gzip et Brotli sont plus performants sur les contenus textuels, atteignant souvent des taux de compression de 70 à 90 % pour les fichiers plus volumineux. Toutefois, l'exécution de ces algorithmes sur des éléments déjà compressés à l'aide d'autres algorithmes (comme la plupart des formats d'image qui utilisent des techniques de compression avec ou sans perte) n'apporte que peu ou pas d'amélioration.

Tous les navigateurs récents annoncent la compatibilité avec gzip et Brotli dans l'en-tête de requête HTTP Accept-Encoding. Toutefois, il incombe au fournisseur d'hébergement de s'assurer que le serveur Web est correctement configuré pour diffuser la ressource compressée lorsque le client la demande.

Fichier Algorithme Taille non compressée Taille compressée Taux de compression
angular-1.8.3.js Brotli 1 346 Kio 256 Kio 81 %
angular-1.8.3.js gzip 1 346 Kio 329 Kio 76 %
angular-1.8.3.min.js Brotli 173 Kio 53 Kio 69 %
angular-1.8.3.min.js gzip 173 Kio 60 Kio 65 %
jquery-3.7.1.js Brotli 302 Kio 69 Kio 77 %
jquery-3.7.1.js gzip 302 Kio 83 Kio 73 %
jquery-3.7.1.min.js Brotli 85 Kio 27 Kio 68 %
jquery-3.7.1.min.js gzip 85 Kio 30 Kio 65 %
lodash-4.17.21.js Brotli 531 Kio 73 Kio 86 %
lodash-4.17.21.js gzip 531 Kio 94 Kio 82 %
lodash-4.17.21.min.js Brotli 71 Kio 23 Kio 68 %
lodash-4.17.21.min.js gzip 71 Kio 25 Kio 65 %

Le tableau précédent montre les économies que les compressions Brotli et gzip peuvent apporter pour quelques bibliothèques JavaScript bien connues. Les économies varient de 65 % à 86 % selon le fichier et l'algorithme. Pour référence, le niveau de compression maximal a été appliqué à chaque fichier pour Brotli et gzip. Dans la mesure du possible, privilégiez Brotli par rapport à gzip.

L'activation de la compression est l'une des optimisations les plus simples et les plus efficaces à mettre en œuvre. Si votre site Web n'en profite pas, vous passez à côté d'une excellente occasion d'améliorer les performances pour vos utilisateurs. Heureusement, de nombreux serveurs Web fournissent des configurations par défaut qui permettent cette optimisation importante, et les CDN en particulier sont très efficaces pour l'implémenter de manière à équilibrer la vitesse et le taux de compression.

Pour voir rapidement la compression en action, ouvrez les outils pour les développeurs Chrome, ouvrez le panneau Réseau, chargez la page de votre choix et observez le bas du panneau "Réseau".

Lecture de la taille réelle par rapport à la taille de transfert dans les outils de développement.
Représentation de la taille de transfert (c'est-à-dire compressée) de toutes les ressources de la page par rapport à leur taille réelle, telle qu'elle est affichée dans le panneau "Réseau" des outils pour les développeurs Chrome.

Comme dans l'image précédente, vous devriez voir une répartition des éléments suivants :

  • Le nombre de requêtes, qui correspond au nombre de ressources chargées pour la page.
  • Taille de transfert de toutes les requêtes. Cela reflète l'efficacité de la compression appliquée à l'une des ressources d'une page.
  • La taille de ressource de toutes les requêtes. Cela reflète la taille des ressources de la page après leur décompression.

Effets sur les Core Web Vitals

Les améliorations des performances ne peuvent pas être mesurées, sauf s'il existe des métriques qui reflètent ces améliorations. L'initiative Core Web Vitals vise à créer et à faire connaître des métriques qui reflètent l'expérience utilisateur réelle. Cela contraste avec les métriques (comme le temps de chargement d'une page simple, par exemple) qui ne se traduisent pas clairement par la qualité de l'expérience utilisateur.

Lorsque vous appliquez les optimisations décrites dans ce guide aux ressources de votre site Web, les effets sur les métriques Core Web Vitals peuvent varier en fonction des ressources optimisées et des métriques concernées. Toutefois, voici quelques cas dans lesquels l'application de ces optimisations peut améliorer les métriques Core Web Vitals de votre site Web :

  • Les ressources HTML minimisées et compressées peuvent améliorer le chargement de ce code HTML, la visibilité de ses sous-ressources et, par conséquent, leur chargement. Cela peut être bénéfique pour le Largest Contentful Paint (LCP) d'une page. Bien que les indications de ressources telles que rel="preload" puissent être utilisées pour affecter la visibilité des ressources, l'utilisation d'un trop grand nombre d'entre elles peut entraîner des problèmes de conflit de bande passante. En vous assurant que la réponse HTML d'une requête de navigation est compressée, les ressources qu'elle contient peuvent être découvertes dès que possible par le scanner de préchargement.
  • Certains éléments candidats au LCP peuvent également être chargés plus rapidement grâce à la compression. Par exemple, les images SVG qui sont des candidats LCP peuvent voir leur durée de chargement des ressources réduite grâce à la compression textuelle. Cela diffère des optimisations que vous apporteriez à d'autres types d'images, qui sont intrinsèquement compressées par d'autres méthodes de compression, comme les images JPEG qui utilisent une compression avec pertes.
  • De plus, les nœuds de texte peuvent également être des candidats LCP. La façon dont les techniques décrites dans ce guide dépendent de l'utilisation d'une police Web pour le texte de vos pages Web. Si vous utilisez une police Web, les bonnes pratiques d'optimisation des polices Web s'appliquent. Toutefois, si vous n'utilisez pas de polices Web, mais plutôt des polices système qui s'affichent sans entraîner de temps de chargement des ressources, la minimisation et la compression de votre CSS réduisent ce temps de chargement, ce qui signifie que l'affichage des nœuds de texte LCP potentiels peut se produire plus tôt.

Conclusion

L'optimisation de l'encodage et du transfert des éléments textuels est un concept de base des performances, mais elle a un impact important. Assurez-vous de faire tout votre possible pour que les ressources éligibles à la minimisation et à la compression bénéficient de ces optimisations.

Plus important encore, assurez-vous que ces processus sont automatisés. Pour la minimisation, utilisez un bundler pour appliquer la minimisation aux ressources éligibles. Assurez-vous que la configuration de votre serveur Web est compatible avec la compression, mais surtout, utilisez la compression la plus efficace disponible. Pour simplifier au maximum cette opération, utilisez des CDN pour automatiser la compression, car ils peuvent non seulement compresser les ressources pour vous, mais aussi le faire très rapidement.

En intégrant ces concepts de performances de base dans l'architecture de votre site Web, vous pouvez vous assurer que vos efforts d'optimisation des performances sont sur la bonne voie et que les optimisations ultérieures peuvent reposer sur une base solide de bonnes pratiques de base.