Réseaux de diffusion de contenu (CDN)

Améliorez les performances en utilisant un réseau de diffusion de contenu.

Les réseaux de diffusion de contenu (CDN) améliorent les performances des sites en utilisant un réseau distribué de serveurs pour fournir des ressources aux utilisateurs. Étant donné que les CDN réduisent la charge du serveur, ils réduisent les coûts liés aux serveurs et sont adaptés à la gestion des pics de trafic. Cet article explique le fonctionnement des CDN et fournit des conseils pour choisir, configurer et optimiser une configuration CDN indépendamment de la plate-forme.

Présentation

Un réseau de diffusion de contenu est constitué d'un réseau de serveurs optimisés pour fournir rapidement du contenu aux utilisateurs. Même si les CDN sont sans doute surtout connus pour diffuser du contenu mis en cache, ils peuvent également améliorer la diffusion du contenu ne pouvant pas être mis en cache. En règle générale, plus le contenu de votre site est diffusé par votre CDN, mieux c'est.

De manière générale, les avantages des CDN en termes de performances découlent de quelques principes: les serveurs CDN sont situés plus près des utilisateurs que les serveurs d'origine et présentent donc une latence de délai aller-retour (DAR) plus court. Les optimisations de mise en réseau permettent aux CDN de diffuser le contenu plus rapidement que si celui-ci était chargé "directement" à partir du serveur d'origine. Enfin, les caches CDN éliminent la nécessité de transmettre une requête au serveur d'origine.

Diffusion des ressources

Bien que cela puisse sembler peu intuitif, il est généralement plus rapide d'utiliser un CDN pour fournir des ressources (même celles qui ne peuvent pas être mises en cache) que de demander à l'utilisateur de charger les ressources "directement" depuis vos serveurs.

Lorsqu'un CDN est utilisé pour fournir des ressources depuis l'origine, une nouvelle connexion est établie entre le client et un serveur CDN à proximité. Le reste du parcours (en d'autres termes, le transfert de données entre le serveur CDN et l'origine) s'effectue sur le réseau du CDN, qui inclut souvent des connexions persistantes existantes avec l'origine. Les avantages sont doubles: l'arrêt de la nouvelle connexion au plus près de l'utilisateur élimine les coûts inutiles de configuration de la connexion (l'établissement d'une nouvelle connexion est coûteux et nécessite plusieurs allers-retours) ; l'utilisation d'une connexion préchauffée permet de transférer immédiatement les données au débit maximal possible.

Certains CDN vont encore plus loin en acheminant le trafic vers l'origine via plusieurs serveurs CDN répartis sur Internet. Les connexions entre les serveurs CDN s'effectuent via des routes fiables et hautement optimisées, et non via des routes déterminées par le protocole BGP (Border Gateway Protocol). Bien que BGP soit le protocole de routage de facto d'Internet, ses décisions de routage ne sont pas toujours axées sur les performances. Par conséquent, les routes déterminées par BGP sont susceptibles d'être moins performantes que les routes correctement ajustées entre les serveurs CDN.

Mise en cache

Avec la mise en cache des ressources sur les serveurs d'un CDN, il n'est pas nécessaire qu'une requête soit acheminée jusqu'à l'origine pour pouvoir être diffusée. Par conséquent, la ressource est diffusée plus rapidement, ce qui réduit également la charge sur le serveur d'origine.

Ajouter des ressources au cache

La méthode la plus couramment utilisée pour remplir les caches CDN consiste à faire en sorte que le CDN récupère les ressources selon les besoins. C'est ce qu'on appelle l'extraction de l'origine. La première fois qu'une ressource particulière est demandée au cache, le CDN la demande au serveur d'origine et met en cache la réponse. De cette manière, le contenu du cache est constitué au fur et à mesure que des ressources supplémentaires non mises en cache sont demandées.

Supprimer des ressources du cache

Les CDN utilisent l'éviction du cache pour supprimer régulièrement du cache les ressources inutiles. En outre, les propriétaires de sites peuvent utiliser la suppression définitive pour supprimer explicitement des ressources.

• Éviction du cache

  La capacité de stockage des caches est limitée. Lorsqu'un cache approche de sa capacité maximale, il libère de la place pour de nouvelles ressources en supprimant celles qui n'ont pas été consultées récemment ou qui occupent beaucoup d'espace. Ce processus est connu sous le nom d'éviction du cache. Une ressource évincée d'un cache ne signifie pas nécessairement qu'elle a été évincée de tous les caches d'un réseau CDN.

• Purge

  La suppression définitive (également appelée "invalidation du cache") est un mécanisme qui permet de supprimer une ressource des caches d'un CDN sans avoir à attendre qu'elle expire ou qu'elle soit évincée. Il est généralement exécuté via une API. La suppression définitive est essentielle dans les cas où un contenu doit être retiré (par exemple, pour corriger des fautes de frappe, des erreurs de prix ou des articles d'actualité incorrects). En plus de cela, il peut également jouer un rôle crucial dans la stratégie de mise en cache d'un site.

  Si un CDN accepte la suppression définitive quasi instantanée, la suppression peut être utilisée comme mécanisme de gestion de la mise en cache du contenu dynamique: mettez en cache le contenu dynamique à l'aide d'une longue valeur TTL, puis supprimez définitivement la ressource chaque fois qu'elle est mise à jour. De cette manière, il est possible de maximiser la durée de mise en cache d'une ressource dynamique, sans savoir à l'avance à quel moment elle sera modifiée. Cette technique est parfois appelée "mise en cache persistante".

  La suppression définitive est généralement utilisée conjointement avec un concept appelé "tags de cache" ou "clés de cache de substitution". Ce mécanisme permet aux propriétaires de sites d'associer un ou plusieurs identifiants supplémentaires (parfois appelés "balises") à une ressource mise en cache. Ces balises peuvent ensuite être utilisées pour effectuer une suppression définitive très précise. Par exemple, vous pouvez ajouter une balise "footer" à toutes les ressources (par exemple, /about, /blog) qui contiennent le pied de page de votre site. Une fois le pied de page mis à jour, demandez à votre CDN de supprimer définitivement toutes les ressources associées au tag de pied de page.

Ressources pouvant être mises en cache

Le mode de mise en cache d'une ressource dépend de son caractère public ou privé (statique ou dynamique).

Ressources privées et publiques

• Ressources privées

  Les ressources privées contiennent des données destinées à un seul utilisateur et ne doivent donc pas être mises en cache par un CDN. Les ressources privées sont indiquées par l'en-tête Cache-Control: private.

• Ressources publiques

  Les ressources publiques ne contiennent pas d'informations spécifiques à l'utilisateur et peuvent donc être mises en cache par un CDN. Une ressource peut être considérée comme pouvant être mise en cache par un CDN si elle ne comporte pas d'en-tête Cache-Control: no-store ou Cache-Control: private. La durée de mise en cache d'une ressource publique dépend de la fréquence de modification de l'élément.

Contenu dynamique et statique

• Contenu dynamique

  Le contenu dynamique est un contenu qui change fréquemment. Une réponse de l'API et la page d'accueil d'un magasin sont des exemples de ce type de contenu. Cependant, le fait que ce contenu change fréquemment n'empêche pas sa mise en cache. Pendant les périodes de trafic dense, la mise en cache de ces réponses pendant de très courtes périodes (par exemple, 5 secondes) peut réduire considérablement la charge sur le serveur d'origine, tout en ayant un impact minimal sur la fraîcheur des données.

• Contenu statique

  Le contenu statique change rarement, voire jamais. Les images, les vidéos et les bibliothèques avec versions gérées sont généralement des exemples de ce type de contenu. Comme le contenu statique ne change pas, il doit être mis en cache avec une longue durée de vie (TTL), par exemple six mois ou un an.

Choisir un CDN

Les performances sont généralement l'un des principaux critères à prendre en compte lorsque vous choisissez un CDN. Toutefois, les autres fonctionnalités offertes par un CDN (par exemple, les fonctionnalités de sécurité et d'analyse), ainsi que la tarification, l'assistance et l'intégration d'un CDN sont tous importants à prendre en compte lors du choix d'un CDN.

Performances

De manière générale, la stratégie de performances d'un CDN peut être envisagée en termes de compromis entre la réduction de la latence et l'optimisation du taux d'accès au cache. Les CDN comportant de nombreux points de présence (PoP) peuvent offrir une latence plus faible, mais peuvent enregistrer des taux d'accès au cache inférieurs en raison de la répartition du trafic entre davantage de caches. À l'inverse, les CDN comportant moins de PoP peuvent être géographiquement éloignés des utilisateurs, mais ils peuvent atteindre des taux d'accès au cache plus élevés.

En conséquence, certains CDN utilisent une approche à plusieurs niveaux pour la mise en cache: les PoP situés à proximité des utilisateurs (également appelés "caches périphériques") sont complétés par des PoP centraux dont le taux d'accès au cache est plus élevé. Lorsqu'un cache périphérique ne parvient pas à trouver une ressource, il la recherche sur un PoP central. Avec cette approche, la latence est légèrement plus élevée, ce qui augmente la probabilité que la ressource puisse être diffusée à partir d'un cache CDN, même s'il ne s'agit pas nécessairement d'un cache périphérique.

Le compromis entre la réduction de la latence et l'optimisation du taux d'accès au cache est tout un éventail de possibilités. Aucune approche n'est universellement meilleure. Cependant, en fonction de la nature de votre site et de sa base d'utilisateurs, vous constaterez peut-être que l'une d'elles offre des performances nettement supérieures à l'autre.

Il convient également de noter que les performances CDN peuvent varier considérablement en fonction de la zone géographique, de l'heure de la journée et même des événements d'actualité. Bien qu'il soit toujours judicieux de faire ses propres recherches sur les performances d'un CDN, il peut être difficile de prédire les performances exactes que vous obtiendrez avec un CDN.

Effets sur le Largest Contentful Paint (LCP)

Comme indiqué précédemment dans cet article, l'objectif principal d'un CDN est de réduire la latence en répartissant les ressources sur des serveurs géographiquement plus proches des utilisateurs. De ce fait, le principal avantage d'un CDN est qu'il améliore les performances de chargement. En particulier, le délai avant le premier octet (TTFB) d'une ressource peut être considérablement amélioré lorsque vous introduisez un CDN dans l'architecture côté serveur de votre site Web.

Bien que le TTFB ne soit pas une métrique de performances centrée sur l'utilisateur, il est important pour diagnostiquer les problèmes liés à la Largest Contentful Paint (LCP), qui est une métrique centrée sur l'utilisateur.

Les CDN sont particulièrement efficaces pour améliorer le LCP, car ils peuvent améliorer à la fois la livraison des documents (en réduisant le TTFB lors de la configuration de la connexion et de la mise en cache du document) et d'améliorer la livraison de toutes les ressources statiques nécessaires à l'affichage de l'élément LCP.

Autres fonctionnalités

Les CDN offrent généralement une grande variété de fonctionnalités en plus de leur offre CDN principale. Parmi les fonctionnalités communément proposées, citons l'équilibrage de charge, l'optimisation d'images, le streaming vidéo, l'edge computing et les produits de sécurité.

Configurer un CDN

Idéalement, vous devriez utiliser un CDN pour diffuser l'intégralité de votre site. Dans les grandes lignes, le processus de configuration consiste à s'inscrire auprès d'un fournisseur de CDN, puis à mettre à jour votre enregistrement DNS CNAME pour qu'il pointe vers le fournisseur de CDN. Par exemple, l'enregistrement CNAME pour www.example.com peut pointer vers example.my-cdn.com. En raison de cette modification DNS, le trafic vers votre site sera acheminé via le CDN.

S'il n'est pas possible d'utiliser un CDN pour diffuser toutes les ressources, vous pouvez le configurer pour qu'il ne diffuse qu'un sous-ensemble de ressources, par exemple des ressources statiques. Pour ce faire, créez un enregistrement CNAME distinct qui ne sera utilisé que pour les ressources devant être diffusées par le CDN. Par exemple, vous pouvez créer un enregistrement CNAME static.example.com qui pointe vers example.my-cdn.com. Vous devez également réécrire les URL des ressources diffusées par le CDN pour qu'elles pointent vers le sous-domaine static.example.com que vous avez créé.

Bien que votre CDN soit mis en place à ce stade, votre configuration présentera probablement des problèmes d'efficacité. Les deux sections suivantes de cet article expliquent comment exploiter au mieux votre CDN en augmentant le taux d'accès au cache et en activant des fonctionnalités de performances.

Améliorer le taux d'accès au cache

Une configuration CDN efficace diffusera autant de ressources que possible à partir du cache. Cette métrique est généralement mesurée par le taux d'accès au cache (CHR, cache hit ratio). Le taux d'accès au cache correspond au nombre de succès de cache divisé par le nombre total de requêtes pendant un intervalle de temps donné.

La valeur CHR d'un cache fraîchement initialisé est de 0, mais celle-ci augmente à mesure que le cache est rempli de ressources. Un taux de fréquence cardiaque de 90% est un bon objectif pour la plupart des sites. Votre fournisseur de CDN doit vous fournir des analyses et des rapports sur vos CHR.

Lorsque vous optimisez la CHR, la première chose à vérifier est que toutes les ressources pouvant être mises en cache sont mises en cache et mises en cache pendant la durée appropriée. Cette évaluation simple doit être effectuée par tous les sites.

De manière générale, le niveau suivant d'optimisation de la CHR consiste à affiner vos paramètres CDN pour vous assurer que les réponses serveur équivalentes logiquement ne sont pas mises en cache séparément. Il s'agit d'une inefficacité courante du fait de l'impact de facteurs tels que les paramètres de requête, les cookies et les en-têtes de requête sur la mise en cache.

Audit initial

La plupart des CDN fournissent des analyses de cache. Vous pouvez également utiliser des outils tels que WebPageTest et Lighthouse pour vérifier rapidement que toutes les ressources statiques d'une page sont mises en cache pendant la durée appropriée. Pour y parvenir, nous vérifions les en-têtes de cache HTTP de chaque ressource. La mise en cache d'une ressource à l'aide de la valeur TTL (Time To Live) maximale appropriée permet d'éviter les récupérations d'origine inutiles à l'avenir et donc d'augmenter le nombre de CHR.

Au minimum, l'un de ces en-têtes doit généralement être défini pour qu'une ressource soit mise en cache par un CDN:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

En outre, bien que cela n'ait aucune incidence sur la mise en cache d'une ressource par un CDN, il est recommandé de définir également la directive Cache-Control: immutable.Cache-Control: immutable indique qu'une ressource "ne sera pas mise à jour pendant sa durée d'actualisation". Par conséquent, le navigateur ne revalide pas la ressource lors de sa diffusion à partir de son cache, ce qui élimine une requête de serveur inutile. Malheureusement, cette directive n'est compatible qu'avec Firefox et Safari, pas avec les navigateurs basés sur Chromium. Ce problème concerne l'assistance Chromium pour Cache-Control: immutable. Ajouter ce problème aux favoris peut permettre d'encourager l'utilisation de cette fonctionnalité.

Pour une explication plus détaillée de la mise en cache HTTP, consultez Empêcher les requêtes réseau inutiles grâce au cache HTTP.

Affinage

Une explication légèrement simplifiée du fonctionnement des caches CDN est que l'URL d'une ressource est utilisée comme clé pour la mise en cache et la récupération de la ressource à partir du cache. En pratique, c'est encore largement vrai, mais l'impact d'éléments tels que les en-têtes et les paramètres de requête est légèrement compliqué. Par conséquent, la réécriture des URL de requête est une technique importante pour optimiser les taux de conversion et s'assurer que le contenu approprié est présenté aux utilisateurs. Une instance CDN correctement configurée offre le bon équilibre entre une mise en cache trop précise (qui nuit à la fréquence cardiaque au repos) et une mise en cache insuffisamment précise (qui entraîne la diffusion de réponses incorrectes aux utilisateurs).

Paramètres de requête

Par défaut, les CDN tiennent compte des paramètres de requête lors de la mise en cache d'une ressource. Toutefois, de petits ajustements de la gestion des paramètres de requête peuvent avoir un impact significatif sur la CHR. Exemple :

• Paramètres de requête inutiles

  Par défaut, un CDN met en cache example.com/blog et example.com/blog?referral_id=2zjk séparément, même s'il s'agit probablement de la même ressource sous-jacente. Pour résoudre ce problème, ajustez la configuration d'un CDN afin d'ignorer le paramètre de requête referral\_id.

• Ordre des paramètres de requête

  Un CDN mettra en cache example.com/blog?id=123&query=dogs séparément de example.com/blog?query=dogs&id=123. Pour la plupart des sites, l'ordre des paramètres de requête n'a pas d'importance. Par conséquent, configurer le CDN pour trier les paramètres de requête (et ainsi normaliser l'URL utilisée pour mettre en cache la réponse du serveur) augmentera le taux de conversion.

Faire varier

L'en-tête de réponse Vary informe les caches que la réponse du serveur correspondant à une URL particulière peut varier en fonction des en-têtes définis sur la requête (par exemple, les en-têtes de requête Accept-Language ou Accept-Encoding). Par conséquent, il demande à un CDN de mettre en cache ces réponses séparément. L'en-tête "Vary" n'est pas largement accepté par les CDN et peut empêcher la diffusion d'une ressource pouvant être mise en cache à partir d'un cache.

Même si l'en-tête "Vary" peut être un outil utile, toute utilisation inappropriée affecte la fréquence cardiaque au repos. De plus, si vous utilisez Vary, la normalisation des en-têtes de requête permet d'améliorer la CHR. Par exemple, sans normalisation, les en-têtes de requête Accept-Language: en-US et Accept-Language: en-US,en;q=0.9 généreraient deux entrées de cache distinctes, même si leur contenu est probablement identique.

Cookies

Les cookies sont définis pour les requêtes via l'en-tête Cookie ; ils le sont pour les réponses via l'en-tête Set-Cookie. L'utilisation inutile de l'en-tête Set-Cookie doit être évitée, car les caches ne mettent généralement pas en cache les réponses du serveur contenant cet en-tête.

Fonctionnalités de performances

Cette section traite des fonctionnalités de performances généralement proposées par les CDN dans le cadre de leur offre de produits principale. De nombreux sites oublient d'activer ces fonctionnalités, au détriment des gains de performances.

Compression

Toutes les réponses textuelles doivent être compressées avec gzip ou Brotli. Si vous avez le choix, optez pour Brotli plutôt que gzip. Brotli est un algorithme de compression plus récent et, par rapport à gzip, il peut atteindre des taux de compression plus élevés.

Il existe deux types de compatibilité CDN pour la compression Brotli: "Brotli from origin" et la "compression automatique Brotli".

Brotli depuis l'origine

Brotli à partir de l'origine désigne le moment où un CDN diffuse des ressources qui ont été compressées par Brotli par l'origine. Même si cette fonctionnalité peut sembler être une fonctionnalité que tous les CDN devraient être compatibles, elle nécessite qu'un CDN puisse mettre en cache plusieurs versions (en d'autres termes, versions compressées avec gzip et pour Brotli) de la ressource correspondant à une URL donnée.

Compression automatique Brotli

La compression automatique Brotli se produit lorsque les ressources sont compressées par Brotli par le CDN. Les CDN peuvent compresser les ressources pouvant être mises en cache ou non.

La première fois qu'une ressource est demandée, elle est diffusée avec une compression "assez bonne" (Brotli-5, par exemple). Ce type de compression s'applique aux ressources pouvant être mises en cache et qui ne peuvent pas être mises en cache.

Pendant ce temps, si une ressource peut être mise en cache, le CDN utilise le traitement hors connexion pour compresser la ressource à un niveau de compression plus puissant, mais beaucoup plus lent, par exemple, Brotli-11. Une fois cette compression terminée, la version la plus compressée est mise en cache et utilisée pour les requêtes ultérieures.

Bonnes pratiques de compression

Les sites qui souhaitent optimiser les performances doivent appliquer la compression Brotli à leur serveur d'origine et à leur CDN. La compression Brotli à l'origine réduit la taille de transfert des ressources qui ne peuvent pas être diffusées à partir du cache. Pour éviter des retards dans la diffusion des requêtes, l'origine doit compresser les ressources dynamiques en utilisant un niveau de compression assez conservateur, par exemple Brotli-4. Les ressources statiques peuvent être compressées à l'aide de Brotli-11. Si une origine n'est pas compatible avec Brotli, vous pouvez utiliser gzip-6 pour compresser les ressources dynamiques, et gzip-9 pour compresser des ressources statiques.

TLS 1.3

TLS 1.3 est la version la plus récente de TLS (Transport Layer Security), le protocole cryptographique utilisé par le protocole HTTPS. TLS 1.3 offre une confidentialité et des performances supérieures par rapport à TLS 1.2.

TLS 1.3 fait passer le handshake TLS de deux allers-retours à un. Pour les connexions HTTP/1 ou HTTP/2, le fait de raccourcir le handshake TLS à un aller-retour permet de réduire de 33 % le temps de configuration de la connexion.

HTTP/2 et HTTP/3

Les protocoles HTTP/2 et HTTP/3 offrent tous deux des avantages en termes de performances par rapport à HTTP/1. Des deux, le protocole HTTP/3 offre de meilleurs avantages en termes de performances. Le protocole HTTP/3 n'est pas encore entièrement standardisé, mais il sera largement accepté lorsque cela se produira.

HTTP/2

Si votre CDN n'a pas encore activé HTTP/2 par défaut, nous vous conseillons de l'activer. Le protocole HTTP/2 offre de nombreux avantages en termes de performances par rapport au protocole HTTP/1 et est compatible avec les principaux navigateurs. HTTP/2 offre des fonctionnalités de performances telles que le multiplexage, la hiérarchisation des flux et la compression d'en-têtes.

• Multiplexage

  Le multiplexage est sans doute la fonctionnalité la plus importante de HTTP/2. Le multiplexage permet à une seule connexion TCP de diffuser plusieurs paires requête-réponse en même temps. Cela élimine la surcharge des configurations de connexion inutiles : étant donné que le nombre de connexions qu'un navigateur peut avoir à ouvrir à un moment donné est limité, cela signifie également que le navigateur peut désormais demander davantage de ressources d'une page en parallèle. En théorie, le multiplexage élimine la nécessité d'effectuer des optimisations HTTP/1 telles que la concaténation et les feuilles de sprites. Toutefois, dans la pratique, ces techniques restent pertinentes, car les fichiers plus volumineux sont mieux compressés.

• Hiérarchisation des flux

  Le multiplexage permet d'utiliser plusieurs flux simultanés. La hiérarchisation des flux fournit une interface permettant de communiquer la priorité relative de chacun de ces flux. Cela permet au serveur d'envoyer les ressources les plus importantes en premier, même si elles n'ont pas été demandées au préalable.

La priorisation des flux est exprimée par le navigateur via une arborescence de dépendances. Il s'agit simplement d'une instruction de préférences. En d'autres termes, le serveur n'est pas tenu de respecter (ni même de tenir compte) des priorités fournies par le navigateur. La hiérarchisation des flux devient plus efficace lorsqu'une plus grande partie d'un site est diffusée via un CDN.

Les implémentations CDN de la hiérarchisation des ressources HTTP/2 varient énormément. Pour savoir si votre CDN est entièrement et correctement compatible avec la hiérarchisation des ressources HTTP/2, consultez Is HTTP/2 Fast Yet? (Le protocole HTTP/2 est-il encore rapide ?).

Bien que le passage d'une instance CDN à HTTP/2 repose en grande partie sur l'activation d'un bouton bascule, il est important de tester minutieusement cette modification avant de l'activer en production. Les protocoles HTTP/1 et HTTP/2 utilisent les mêmes conventions pour les en-têtes de requête et de réponse, mais HTTP/2 est beaucoup moins incontournable lorsque ces conventions ne sont pas respectées. Une fois le protocole HTTP/2 activé, des pratiques non spécifiques, telles que l'inclusion de caractères non ASCII ou en majuscules dans les en-têtes, peuvent commencer à générer des erreurs. Dans ce cas, les tentatives de téléchargement de la ressource par le navigateur échoueront. La tentative de téléchargement ayant échoué s'affiche dans l'onglet "Réseau" des outils de développement. En outre, le message d'erreur "ERR_HTTP2_PROTOCOL_ERROR" s'affichera dans la console.

HTTP/3

HTTP/3 est le successeur de HTTP/2. Depuis septembre 2020, tous les principaux navigateurs sont compatibles à titre expérimental avec HTTP/3 et certains CDN sont compatibles. Les performances constituent le principal avantage de HTTP/3 par rapport à HTTP/2. Plus précisément, HTTP/3 élimine le blocage en tête de ligne au niveau de la connexion et réduit le temps de configuration de la connexion.

• Élimination du blocage en tête de ligne

  Le protocole HTTP/2 a introduit le multiplexage, une fonctionnalité qui permet d'utiliser une seule connexion pour transmettre plusieurs flux de données simultanément. Cependant, avec HTTP/2, un seul paquet supprimé bloque tous les flux d'une connexion (ce phénomène est appelé "blocage en tête de ligne"). Avec HTTP/3, un paquet supprimé ne bloque qu'un seul flux. Cette amélioration est largement due au fait que HTTP/3 utilise UDP (HTTP/3 utilise UDP via QUIC) plutôt que TCP. Cela rend HTTP/3 particulièrement utile pour le transfert de données sur des réseaux encombrés ou avec pertes.

• Réduction du temps de configuration de la connexion

  HTTP/3 utilise TLS 1.3 et partage donc ses avantages en termes de performances: l'établissement d'une nouvelle connexion ne nécessite qu'un seul aller-retour, et la reprise d'une connexion existante ne nécessite aucun aller-retour.

Le protocole HTTP/3 aura le plus d'impact sur les utilisateurs en cas de mauvaise connexion réseau: non seulement parce que HTTP/3 gère mieux la perte de paquets que ses prédécesseurs, mais aussi parce que le gain de temps absolu résultant de la configuration d'une connexion 0-DAR ou 1-DAR sera plus important sur les réseaux à latence élevée.

Optimisation des images

Les services d'optimisation d'images CDN se concentrent généralement sur les optimisations d'image qui peuvent être appliquées automatiquement afin de réduire la taille du transfert d'image. Par exemple: suppression des données EXIF, compression sans perte et conversion d'images dans des formats de fichiers plus récents (WebP, par exemple). Les images représentent environ 50% des octets transférés sur la page Web médiane. Par conséquent, optimiser les images peut réduire considérablement la taille de la page.

Réduction

La minimisation supprime les caractères inutiles des fichiers JavaScript, CSS et HTML. Il est préférable d'effectuer la minimisation sur le serveur d'origine plutôt que sur le CDN. Les propriétaires de sites disposent de davantage de contexte sur le code à réduire et peuvent donc souvent utiliser des techniques de minimisation plus agressives que celles employées par les CDN. Toutefois, si la réduction de la taille du code à l'origine n'est pas possible, la minimisation par le CDN est une bonne alternative.

Conclusion

• Utiliser un CDN:les CDN fournissent les ressources rapidement, réduisent la charge sur le serveur d'origine et sont utiles pour gérer les pics de trafic.
• Mettez en cache le contenu de manière aussi stricte que possible:les contenus statiques et dynamiques peuvent et doivent être mis en cache, mais pour des durées variables. Contrôlez régulièrement votre site pour vous assurer que la mise en cache du contenu est optimale.
• Activez les fonctionnalités liées aux performances CDN:des fonctionnalités telles que Brotli, TLS 1.3, HTTP/2 et HTTP/3 améliorent encore les performances.