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 serveur, ils réduisent les coûts de serveur et sont parfaitement adaptés à la gestion des pics de trafic. Cet article explique le fonctionnement des CDN et fournit des conseils adaptés à chaque plate-forme pour choisir, configurer et optimiser leur configuration.

Présentation

Un réseau de diffusion de contenu est un réseau de serveurs optimisés pour fournir rapidement du contenu aux utilisateurs. Bien que les CDN soient sans doute plus connus pour diffuser du contenu mis en cache, ils peuvent également améliorer la diffusion de contenu ne pouvant pas être mis en cache. De manière générale, plus 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 d'un certain nombre de principes: les serveurs CDN sont situés plus près des utilisateurs que les serveurs d'origine et ont donc une latence de délai aller-retour (DAR) plus courte. Les optimisations réseau permettent aux CDN de diffuser du contenu plus rapidement que si le contenu était chargé "directement" depuis le serveur d'origine. Enfin, les caches CDN éliminent la nécessité d'envoyer une requête vers le serveur d'origine.

Livraison 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) plutôt que de demander à l'utilisateur de les charger "directement" depuis vos serveurs.

Lorsqu'un CDN est utilisé pour diffuser des ressources depuis l'origine, une nouvelle connexion est établie entre le client et un serveur CDN situé à proximité. Le reste du parcours (en d'autres termes, le transfert de données entre le serveur CDN et l'origine) a lieu sur le réseau du CDN, qui comprend souvent des connexions existantes et persistantes avec l'origine. Cette approche présente un double avantage: la fermeture de la nouvelle connexion le plus près possible de l'utilisateur élimine les coûts de configuration de connexion inutiles (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 améliorent encore ce processus 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 itinéraires déterminés 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 finement ajustées entre les serveurs CDN.

Mise en cache

La mise en cache des ressources sur les serveurs d'un CDN élimine la nécessité pour une requête de voyager jusqu'à l'origine pour ê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 les ressources CDN "pull" soient utilisées selon les besoins. C'est ce que l'on appelle l'extraction de l'origine. La première fois qu'une ressource particulière est demandée depuis le cache, le CDN la demande au serveur d'origine et met en cache la réponse. De cette manière, le contenu du cache s'accumule au fil du temps, à 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 les ressources inutiles du cache. De plus, les propriétaires de sites peuvent utiliser la fonction de suppression définitive pour supprimer explicitement des ressources.

• Éviction du cache

  Les caches ont une capacité de stockage limitée. Lorsqu'un cache approche de sa capacité maximale, il libère de l'espace 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 appelé "é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.

• Suppression définitive

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

  Si un CDN est compatible avec la suppression définitive quasi instantanée, la suppression définitive 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, même si vous ne savez pas à l'avance quand la ressource sera modifiée. Cette technique est parfois appelée "mise en cache de type "hold-till-told".

  Lors de la suppression définitive à grande échelle, elle est généralement utilisée conjointement avec un concept appelé "balise 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 "tags") à une ressource mise en cache. Ces tags peuvent ensuite être utilisés pour effectuer une suppression définitive de manière très précise. Par exemple, vous pouvez ajouter une balise "footer" à toutes les ressources (/about, /blog, par exemple) qui contiennent le pied de page de votre site. Lorsque le pied de page est mis à jour, demandez à votre CDN de supprimer définitivement toutes les ressources associées au tag "pied de page".

Ressources pouvant être mises en cache

L'état de mise en cache d'une ressource et la manière dont elle doit être mise en cache varient selon qu'elle est publique ou privée (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 une page d'accueil de la boutique sont des exemples de ce type de contenu. Cependant, le fait que ce contenu change fréquemment n'empêche pas nécessairement sa mise en cache. Lors des pics de trafic, la mise en cache de ces réponses pendant des périodes très courtes (par exemple, cinq 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 gestion des versions 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 valeur TTL (Time To Live) longue, par exemple, 6 mois ou 1 an.

Choisir un CDN

Les performances constituent généralement un critère important à prendre en compte lorsque vous choisissez un CDN. Toutefois, les autres fonctionnalités proposées par un CDN (par exemple, les fonctionnalités de sécurité et d'analyse), ainsi que son prix, son assistance et son intégration 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 considérée comme le compromis entre une réduction de la latence et la maximisation du taux d'accès au cache. Les CDN avec de nombreux points de présence (PoP) peuvent offrir une latence plus faible, mais ils 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 ayant moins de PoP peuvent se trouver géographiquement plus loin des utilisateurs, mais ils peuvent atteindre des taux de succès de cache plus élevés.

En raison de ce compromis, certains CDN utilisent une approche de mise en cache à plusieurs niveaux: les PoP situés à proximité des utilisateurs (également appelés "caches périphériques") sont complétés par des PoP centraux présentant des taux d'accès au cache plus élevés. Lorsqu'un cache périphérique ne parvient pas à trouver une ressource, il recherche cette ressource vers un PoP central. Cette approche réduit légèrement la latence au détriment de la probabilité que la ressource soit diffusée à partir d'un cache CDN, même si ce n'est pas nécessairement un cache périphérique.

Le compromis entre réduire la latence et maximiser le taux d'accès au cache est un spectre. Aucune approche particulière n'est universellement meilleure. Toutefois, selon la nature de votre site et sa base d'utilisateurs, vous constaterez peut-être qu'une de ces approches offre des performances nettement supérieures à l'autre.

Il convient de noter que les performances d'un 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 en cours. Bien qu'il soit toujours judicieux d'effectuer vos propres recherches sur les performances d'un CDN, il peut être difficile de prévoir les performances exactes que vous obtiendrez avec un CDN.

Effets sur le LCP (Largest Contentful Paint)

Comme indiqué précédemment dans cet article, l'objectif principal d'un CDN est de réduire la latence en distribuant les ressources aux serveurs géographiquement proches des utilisateurs. De ce fait, le principal avantage d'un CDN est qu'il améliore les performances de chargement. En particulier, le temps de latence du 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 TTFB ne soit pas une métrique de performances axée sur l'utilisateur, elle est une métrique importante pour diagnostiquer les problèmes liés au 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 livraison de documents (en réduisant le TTFB lors de la configuration de la connexion et de la mise en cache du document) et la diffusion de toutes les ressources statiques nécessaires pour afficher 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. Les fonctionnalités communément proposées incluent l'équilibrage de charge, l'optimisation d'images, le streaming vidéo, l'edge computing et les produits de sécurité.

Installer et 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 à vous inscrire auprès d'un fournisseur CDN, puis à mettre à jour votre enregistrement DNS CNAME pour qu'il pointe vers le fournisseur CDN. Par exemple, l'enregistrement CNAME de www.example.com peut pointer vers example.my-cdn.com. En conséquence de ce changement 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 configurer un CDN 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 configuré à ce stade, il est probable que votre configuration ne soit pas efficace. 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 les 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. Ce taux est généralement mesuré par le taux d'accès au cache. Le taux d'accès au cache correspond au nombre d'accès au cache divisé par le nombre total de requêtes au cours d'un intervalle de temps donné.

Un cache fraîchement initialisé a une CHR de 0, mais cette valeur augmente à mesure que le cache est rempli de ressources. Une fréquence cardiaque au repos de 90% est un bon objectif pour la plupart des sites. Votre fournisseur de CDN doit vous fournir des analyses et des rapports sur votre CHR.

Lorsque vous optimisez le CHR, la première chose à vérifier est que toutes les ressources pouvant être mises en cache sont mises en cache pour la durée appropriée. Il s'agit d'une évaluation simple que tous les sites doivent effectuer.

De manière générale, le niveau suivant de l'optimisation du CHR consiste à affiner vos paramètres CDN pour vous assurer que des réponses de serveur équivalentes d'un point de vue logique ne sont pas mises en cache séparément. Cette inefficacité est souvent due à 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 une analyse du 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 ce faire, vérifiez 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 des récupérations d'origine inutiles à l'avenir et donc d'augmenter la fréquence cardiaque au repos.

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 de vie d'actualisation". Par conséquent, le navigateur ne revalidera pas la ressource lorsqu'il la traitera à partir de la mémoire cache du navigateur, ce qui éliminera une demande inutile du serveur. Malheureusement, cette directive n'est compatible qu'avec Firefox et Safari. Elle n'est pas compatible avec les navigateurs basés sur Chromium. Ce problème permet de suivre la compatibilité de Chromium avec Cache-Control: immutable. En activant le suivi de ce problème, vous encouragez la prise en charge 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.

Réglage

Une explication légèrement simplifiée du fonctionnement des caches CDN est la suivante : l'URL d'une ressource est utilisée comme clé pour la mise en cache et la récupération de la ressource dans le cache. Dans la pratique, ce constat est toujours extrêmement vrai, mais l'impact d'éléments tels que les en-têtes et les paramètres de requête est un peu compliqué. Par conséquent, la réécriture des URL de demande est une technique importante à la fois pour optimiser le CHR et s'assurer que le contenu approprié est diffusé auprès des utilisateurs. Une instance CDN correctement configurée permet de trouver le bon équilibre entre une mise en cache trop précise (qui nuit au CHR) et une mise en cache insuffisamment précise (ce qui entraîne la diffusion de réponses incorrectes auprès des utilisateurs).

Paramètres de requête

Par défaut, les CDN prennent en compte les paramètres de requête lors de la mise en cache d'une ressource. Toutefois, de légers ajustements apportés au traitement des paramètres de requête peuvent avoir un impact significatif sur la fréquence cardiaque au repos. 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 pour qu'il ignore 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 indique aux caches que la réponse du serveur correspondant à une URL particulière peut varier en fonction des en-têtes définis dans 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 pris en charge par les CDN et peut empêcher la diffusion d'une ressource pouvant être mise en cache à partir d'un cache.

Bien que l'en-tête "Vary" puisse constituer un outil utile, une utilisation inappropriée nuit au CHR. De plus, si vous utilisez Vary, la normalisation des en-têtes de requêtes contribuera à 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 serait probablement identique.

Cookies

Les cookies sont définis sur les requêtes via l'en-tête Cookie ; ils sont définis sur les réponses via l'en-tête Set-Cookie. Évitez toute utilisation inutile de l'en-tête Set-Cookie, car les caches ne mettent généralement pas en cache les réponses du serveur contenant cet en-tête.

Fonctionnalités liées aux performances

Cette section traite des fonctionnalités de performances communément proposées par les CDN dans le cadre de leur offre de produits principale. De nombreux sites oublient d'activer ces fonctionnalités et passent à côté d'améliorations simples en termes de performances.

Compression

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

Deux types de CDN sont disponibles pour la compression Brotli: "Brotli from origin" et "Automatic Brotli compression".

Brotli d'origine

Brotli à partir de l'origine : un CDN diffuse des ressources compressées par Brotli par l'origine. Bien que cette fonctionnalité puisse sembler être une fonctionnalité que tous les CDN devraient être en mesure de prendre en charge directement, un CDN doit pouvoir mettre en cache plusieurs versions (en d'autres termes, compressées avec gzip et compressées avec Brotli) de la ressource correspondant à une URL donnée.

Compression Brotli automatique

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 et celles qui ne peuvent pas être mises en cache.

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

En revanche, 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 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 une compression Brotli à la fois au serveur d'origine et au CDN. La compression Brotli à l'origine minimise la taille de transfert des ressources qui ne peuvent pas être diffusées à partir du cache. Pour éviter les retards de diffusion des requêtes, l'origine doit compresser les ressources dynamiques à l'aide d'un niveau de compression assez prudent (Brotli-4, par exemple). 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 HTTPS. TLS 1.3 offre de meilleures performances et une meilleure confidentialité que TLS 1.2.

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

HTTP/2 et HTTP/3

HTTP/2 et HTTP/3 offrent tous deux des avantages en termes de performances par rapport à HTTP/1. Des deux, HTTP/3 offre des avantages potentiels en termes de performances. Le protocole HTTP/3 n'est pas encore complètement standardisé, mais il deviendra largement accepté une fois que cela se produira.

HTTP/2

Si votre CDN n'a pas encore activé HTTP/2 par défaut, nous vous conseillons de le faire. Le protocole HTTP/2 offre de nombreux avantages en termes de performances par rapport à HTTP/1 et est compatible avec les principaux navigateurs. HTTP/2 présente les caractéristiques de performances suivantes: multiplexage, hiérarchisation des flux et compression d'en-tête.

• 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 les frais liés aux configurations de connexion inutiles. Étant donné que le nombre de connexions qu'un navigateur peut ouvrir à un moment donné est limité, cela signifie également que le navigateur est maintenant en mesure de demander davantage de ressources d'une page en parallèle. En théorie, le multiplexage évite d'avoir à 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 diffusions

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

La hiérarchisation des flux est exprimée par le navigateur via une arborescence de dépendances. Il s'agit simplement d'une déclaration de préférence: en d'autres termes, le serveur n'est pas tenu d'atteindre (ou même de prendre en compte) les 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 considérablement. Pour déterminer si votre CDN est entièrement et correctement compatible avec la hiérarchisation des ressources HTTP/2, consultez Is HTTP/2 Fast Yet?.

Bien que le passage de votre instance CDN au protocole HTTP/2 nécessite en grande partie l'enclenchement d'un commutateur, il est important de tester minutieusement cette modification avant de l'activer en production. 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 indulgent lorsque ces conventions ne sont pas respectées. Par conséquent, des pratiques non conformes (telles que l'inclusion de caractères non ASCII ou majuscules dans les en-têtes) peuvent entraîner des erreurs une fois le protocole HTTP/2 activé. Dans ce cas, les tentatives de téléchargement de la ressource par un navigateur échoueront. L'échec de la tentative de téléchargement s'affiche dans l'onglet "Réseau" des outils de développement. De plus, 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 offrent une compatibilité expérimentale avec HTTP/3 et certains CDN le sont. Les performances sont 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 multiplexage HTTP/2 a été introduit, une fonctionnalité qui permet d'utiliser une seule connexion pour transmettre simultanément plusieurs flux de données. Cependant, avec HTTP/2, un seul paquet supprimé bloque tous les flux d'une connexion (un phénomène appelé "blocage en tête de ligne"). Avec HTTP/3, un paquet supprimé ne bloque qu'un seul flux. Cette amélioration est en grande partie le résultat de l'utilisation d'UDP pour HTTP/3 (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

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

HTTP/3 aura l'impact le plus important sur les utilisateurs en cas de connexion réseau de mauvaise qualité: non seulement parce qu'il gère la perte de paquets mieux que ses prédécesseurs, mais aussi parce que le gain de temps absolu résultant d'une configuration de 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'images qui peuvent être appliquées automatiquement afin de réduire la taille du transfert d'image. Par exemple: suppression des données EXIF, application de la compression sans perte et conversion des images dans des formats de fichiers plus récents (WebP, par exemple). Les images représentent environ 50% des octets de transfert sur la page Web médiane. L'optimisation des images peut donc réduire considérablement la taille de la page.

Réduction

La minification supprime les caractères inutiles dans 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 plus 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, s'il n'est pas possible de réduire la taille du code à l'origine, la minimisation par le CDN constitue une bonne alternative.

Conclusion

• Utilisez un CDN:les CDN fournissent rapidement des ressources, réduisent la charge sur le serveur d'origine et sont utiles pour faire face aux pics de trafic.
• Mise en cache du contenu aussi agressive que possible:le contenu statique et dynamique peut et doit être mis en cache, bien que 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 de performances CDN:des fonctionnalités telles que Brotli, TLS 1.3, HTTP/2 et HTTP/3 améliorent encore les performances.