Performance CDN

L'un des principaux avantages d'un CDN est sa capacité à fournir du contenu rapidement et efficacement. Les optimisations de performances du CDN peuvent être divisées en trois catégories. Explorer le guide CDN.

Share facebook icon linkedin icon twitter icon email icon

Performance CDN

Objectifs d’apprentissage

Après avoir lu cet article, vous pourrez :

  • Comprendre comment un CDN améliore les temps de chargement
  • Comparer l'utilisation d'un CDN avec la non-utilisation d'un CDN
  • Découvrir les principes de base de la mise en cache CDN
  • Apprendre comment un CDN réduit la taille des fichiers

Comment un CDN améliore-t-il les temps de chargement ?

Pratiquement tous les internautes ont bénéficié des avantages d'un réseau de distribution de contenu (CDN). La plupart des sociétés technologiques, notamment des sociétés comme Google, Apple et Microsoft, utilisent des CDN pour réduire la latence lors du chargement de contenu des pages web.


Un CDN placera généralement des serveurs aux points d'échange entre différents réseaux. Ces points d'échange Internet (IXP) sont les principaux emplacements où les différents fournisseurs d'accès à Internet se relient les uns aux autres afin de fournir un accès mutuel aux ressources sur leurs différents réseaux. En plus des IXP, un CDN placera des serveurs dans des datacenters à des endroits du monde situés dans des zones à fort trafic et à des emplacements stratégiques pour pouvoir déplacer le trafic le plus rapidement possible.


L'un des principaux avantages d'un CDN est sa capacité à fournir du contenu rapidement et efficacement. Les optimisations de performances du CDN peuvent être divisées en trois catégories :

  1. Réduction de la distance – elle consiste à réduire la distance physique entre un client et les données demandées
  2. Optimisations matérielles/logicielles – améliorer les performances de l'infrastructure côté serveur , par exemple en utilisant des disques durs SSD et un équilibrage de charge efficace
  3. Réduction du transfert de données - utiliser des techniques pour réduire la taille des fichiers de manière à ce que le chargement de page initial se produise rapidement

Pour comprendre les avantages de l'utilisation d'un CDN, examinons à quoi ressemble un transfert de données client/serveur normal sans CDN en place.

Quelle est la différence de temps de chargement avec et sans CDN ?

Imaginons que quelqu'un à New York ait besoin d'accéder à un site web hébergé sur un serveur à Singapour. La séparation physique entre ces emplacements est importante et représente une distance d'environ 15300 km.

Distance Without CDN

Si un serveur hébergeant du contenu de site web (le serveur d'origine) est situé à Singapour, chaque requête pour chaque élément de page web doit parcourir la distance New York - Singapour et vice-versa. Tout comme dans le cas d'un vol international avec de nombreux changements en cours de route, chaque requête doit passer par une série de routeurs le long de son long trajet d'un point A à un point B.


Pour voir un exemple réel du nombre de connexions (sauts) différentes qu'il faut à votre ordinateur pour atteindre un service web particulier à partir de votre emplacement actuel, découvrez l'utilitaire traceroute sur un ordinateur de bureau.

CDN Transit Time Improvements

Comme la requête de New York à Singapour doit passer par chacun des routeurs en cours de route, le temps (latence) est augmenté à la fois par la distance totale et par le temps que prend chaque routeur pour traiter la requête. Une fois que le serveur d'origine traite la requête et répond au client qui a émis la requête, il renvoie les informations qui transitent par une séquence similaire de routeurs avant de revenir à New York. La mesure de cette boucle totale est appelée dans les télécommunications RTT ou « temps d'aller-retour » (round trip time). En laissant pour l'instant de côté la bande passante disponible et la congestion potentielle du réseau, examinons un exemple de facteurs de latence.


À titre d'illustration, considérons les données suivantes :

  • Il faut 250 ms pour qu'une requête aille de New York à Singapour.
  • L'établissement d'une connexion TCP/IP ajoutera 3 instances de 250 ms de latence.
  • La page web nécessite 5 actifs uniques composés d'images, de fichiers JavaScript et de la page web proprement dite.

Voyons à peu près combien de temps il faudra pour que cette page web se charge :

  • 750 ms : la connexion TCP/IP est établie entre le client à New York et le serveur d'origine à Singapour.
  • 250 ms : la requête HTTP pour la page web va de New York à Singapour.
  • 250 ms : le demandeur à New York reçoit une réponse du serveur d'origine à Singapour avec un code de statut 200 et la page web comprenant tous les actifs supplémentaires nécessaires.
  • 250 ms : chacun des 5 actifs est demandé par le client à New York.
  • 1500 ms : les cinq actifs sont livrés de manière asynchrone au client à partir du serveur d'origine à Singapour.

Dans cet exemple simple, le temps de transit total pour que cette page web se charge est d'environ 3000 ms.


Comme vous pouvez le voir, chaque requête formulée et chaque réponse envoyée parcourent le trajet complet entre le client à New York et le serveur d'origine à Singapour. À mesure que les sites web se développent et nécessitent un plus grand nombre d'actifs, la latence entre le point A et le point B continue d'augmenter.


Revoyons l'exemple du contenu hébergé à Singapour servi à un client web à New York, mais cette fois le site de Singapour utilise un CDN avec un serveur à Atlanta qui contient une copie en cache du site web statique :

  • Il faut 50 ms pour qu'une demande passe de New York à Atlanta.
  • L'établissement d'une connexion TCP/IP ajoutera 3 instances de 50 ms de latence
  • La page web nécessite cinq ressources uniques composées d'images, de fichiers JavaScript et de la page web elle-même.

Voyons le temps approximatif qu'il faudra à cette page web pour se charger à l'aide du CDN :

  • 150 ms : la connexion TCP/IP est établie entre le client à New York et le serveur de périphérie à Atlanta.
  • 50 ms : la requête HTTP GET pour la page web se déplace du client vers le serveur de périphérie.
  • 50 ms : le client reçoit une réponse du cache du serveur de périphérie avec la page web, y compris une liste de tous les actifs supplémentaires nécessaires.
  • 50 ms : chacun des 5 actifs est demandé par le client.
  • 800 ms : les cinq actifs sont livrés de manière asynchrone au client à partir du serveur de périphérie.

Le temps de transit total pour que cette page web se charge est d'environ 1100 ms.

CDN Distance Optimized

Dans cet exemple, la réduction de la distance entre le client et le contenu crée une amélioration de la latence de 1900 ms pour le contenu statique, ce qui représente une amélioration de près de 2 s au niveau du temps de chargement.

CDN Latency Improvement

En réduisant la distance totale que tout le trafic nécessaire doit parcourir, chaque utilisateur du site web économise du temps de chargement. Étant donné que les utilisateurs commencent à quitter le site (rebond) très rapidement lorsque les temps d'attente augmentent, cette amélioration représente à la fois une meilleure expérience utilisateur et un temps utilisateur plus long sur la page.

Comment un CDN charge-t-il le contenu ? Qu'est-ce que la mise en cache ?

Comme indiqué précédemment, lorsqu'un client demande un fichier à un serveur d'origine, la requête doit normalement faire l'aller-retour vers ce serveur et vice-versa. Un CDN améliore la latence en extrayant des fichiers de contenu statique du serveur d'origine dans le réseau CDN distribué selon un processus appelé mise en cache. Certains CDN auront des fonctionnalités avancées qui permettent également la mise en cache sélective du contenu dynamique. Une fois les données mises en cache, le CDN sert le contenu au client à partir du centre de données CDN le plus proche.

Request Without CDN Caching
Request With CDN Caching

Une fois qu'un handshake TCP a eu lieu, la machine cliente effectue une requête HTTP au réseau du CDN. Si le contenu n'a pas encore été mis en cache, le CDN téléchargera d'abord le contenu depuis le serveur d'origine en effectuant une requête supplémentaire entre le serveur d'origine et le serveur de périphérie du CDN.


Voici les 4 étapes lors d'une mise en cache CDN typique :

  1. Lorsque l'utilisateur demande une page web, la requête de l'utilisateur est acheminée vers le serveur de périphérie le plus proche du CDN.
  2. Le serveur de périphérie fait alors une requête au serveur d'origine pour le contenu demandé par l'utilisateur.
  3. Le serveur d'origine répond à la requête du serveur de périphérie.
  4. Enfin, le serveur de périphérie répond au client.
CDN Caching Request

L'intérêt de la proximité d'un CDN par rapport au client intervient après que la requête initiale adressée au serveur d'origine a déjà été effectuée. Une fois que les données ont été mises en cache depuis le serveur d'origine sur le réseau du CDN, chaque requête suivante du client n'a plus qu'à aller jusqu'au serveur de périphérie le plus proche. Par conséquent, si le serveur de périphérie le plus proche est moins loin que le serveur d'origine, la latence peut être réduite et le contenu peut être servi beaucoup plus rapidement.

cached CDN edge response

Il est important de garder à l'esprit que le temps nécessaire pour télécharger les actifs et pour traiter les requêtes et les réponses n'est pas inclus actuellement mais pour l'instant, uniquement le temps de transit nécessaire pour transférer les informations entre ces deux sites. Parmi les autres facteurs de latence importants que nous allons examiner figurent la réduction des données, la vitesse du disque dur et l'encombrement du réseau.1.

Comment un CDN réduit-il la taille des fichiers pour augmenter les vitesses ?

Afin d'améliorer les temps de chargement de page, les CDN réduisent les quantités globales de transfert de données entre les serveurs de cache du CDN et le client. La latence et la bande passante requise sont réduites lorsque la quantité globale de données transférées diminue. Il en résulte des chargements de page plus rapides et des coûts de bande passante plus réduits. Deux éléments clés entrent dans ces réductions :


Minification - la minification est le processus qui consiste à réduire la taille du code en supprimant tous les composants qui aident les humains à comprendre ce qui se passe. Alors qu'un ingénieur doit séparer les idées en noms de variables, espaces et commentaires sensés pour rendre les blocs de code lisibles et gérables, la suppression des caractères n'empêche pas la bonne exécution du code.

Voici le même bloc de code avant et après minification :

Avant minification : huit lignes de code

CDN Without Minification

Après minification : réduit à une seule ligne de code

CDN Minification

Maintenant que le snippet de code a été réduit de huit lignes à une seule ligne, la taille globale du fichier a également été réduite. Il faut donc moins de temps pour transférer le fichier, ce qui réduit la latence et permet de charger le contenu plus rapidement.


Compression de fichiers - la compression de fichiers est essentielle pour réduire la latence et la consommation de bande passante requise lors du transfert de données via Internet. GZip est une méthode courante de compression qui est considérée comme une bonne pratique à utiliser lors du transfert de pages web. De nombreux fournisseurs CDN ont activé GZip par défaut. Quelle est l'importance des économies réalisées grâce à la compression GZip ? Les fichiers généralement compressés seront réduits d'environ 50 % à 70 % par rapport à la taille initiale du fichier.

Quel matériel un CDN peut-il utiliser pour améliorer les vitesses ?

En ce qui concerne les optimisations matérielles du CDN, l'utilisation substantielle des disques durs SSD par rapport aux disques durs mécaniques traditionnels (HDD) présente un avantage substantiel. Les disques SSD peuvent ouvrir des fichiers jusqu'à 30 % plus rapidement que les disques durs mécaniques traditionnels et sont plus résistants et fiables.


Un disque dur traditionnel ressemble à un tourne-disque. Il est constitué d'un disque métallique circulaire tournant avec un revêtement magnétique qui stocke les données. Une tête de lecture/écriture sur un bras accède aux informations sur le disque en rotation. Ce processus est mécanique et dépend de la vitesse à laquelle le disque tourne. Avec l'avènement des disques durs SSD, les anciens modèles de disques durs sont moins utilisés, bien qu'ils soient toujours produits aujourd'hui et largement utilisés dans de nombreux systèmes informatiques.


Un disque dur SSD est également une forme de stockage persistant, mais fonctionne d'une manière assez similaire aux clés USB ou aux cartes mémoire que l'on trouve couramment dans les appareils tels que les appareils photo numériques. Il ne contient pas de pièces mobiles. Si un disque dur traditionnel tourne et que le système est bousculé, le disque dur risque de sauter, en entraînant des erreurs de lecture/écriture et des temps d'arrêt potentiels. L'accès aux fichiers fragmentés est un autre avantage important des disques dures SSD. La fragmentation des fichiers signifie que plusieurs parties d'un fichier se trouvent à différents emplacements du disque, ce qui ralentit l'accès aux disques durs. Étant donné qu'un disque dur SSD peut accéder efficacement aux emplacements de mémoire non contigus, la fragmentation ne diminue pas ses performances.


Dans les premiers CDN, les données étaient stockées sur des disques durs. Désormais, avec certains services CDN, toute la mise en cache côté périphérie peut être faite sur des disques SSD. L'inconvénient des SSD est leur prix. Un disque dur SSD peut être jusqu'à 5 fois plus cher qu'un disque dur traditionnel. Ceci explique pourquoi certains services CDN évitent souvent d'utiliser des SSD et opteront plutôt pour l'ancienne technologie. Cloudflare CDN utilise exclusivement des disques durs SSD.