🥇[Ne pas] utiliser CDN

Presque tous les articles ou outils permettant d'optimiser la vitesse du site contiennent une modeste clause « utiliser un CDN ». En général, CDN est un réseau de diffusion de contenu ou un réseau de diffusion de contenu. Chez Method Lab, nous rencontrons souvent des questions de clients sur ce sujet ; certains d'entre eux activent leur propre CDN. Le but de cet article est de comprendre ce qu’un CDN peut apporter en termes de vitesse de chargement du site, quels problèmes peuvent survenir et dans quels cas l’utilisation d’un CDN est justifiée.

Les retards encerclés sur l'image sont causés par l'utilisation d'un CDN.

Un peu d'histoire

Comme de nombreuses technologies, les CDN sont apparus par nécessité. Avec le développement des canaux Internet parmi les internautes, des services de vidéo en ligne sont apparus. Naturellement, le contenu vidéo nécessite beaucoup plus de bande passante que le contenu d’un site Web classique (images, texte et code CSS ou JS).

Lorsque vous essayez de diffuser un flux vidéo en parallèle vers plusieurs clients à partir d'un serveur, le canal Internet du serveur deviendra très probablement le goulot d'étranglement. En règle générale, quelques milliers de threads suffisent à obstruer un canal de serveur typique. Bien sûr, il peut y avoir d’autres limitations en matière de ressources, mais elles ne sont pas importantes pour le moment. Il est également important que l'extension du canal serveur soit trop coûteuse (et parfois impossible) et peu pratique. La charge sur la chaîne lors des diffusions sera cyclique.

Le problème de la limitation du canal d'un serveur individuel est parfaitement résolu par CDN. Les clients ne se connectent pas directement au serveur, mais aux nœuds du réseau CDN. Dans une situation idéale, le serveur envoie un flux au nœud CDN, puis le réseau utilise ses propres ressources pour transmettre ce flux à de nombreux utilisateurs. D'un point de vue économique, nous payons uniquement pour les ressources réellement consommées (il peut s'agir de bande passante ou de trafic) et obtenons une excellente évolutivité de notre service. Utiliser un CDN pour diffuser du contenu lourd est tout à fait justifié et logique. Même s'il convient de noter que les plus grands acteurs de ce domaine (par exemple Netflix) créent leurs propres CDN au lieu d'utiliser de grands CDN commerciaux (Akamai, Cloudflare, Fastly, etc.)

À mesure que le Web a évolué, les applications Web elles-mêmes sont devenues plus complexes et plus lourdes. Le problème de la vitesse de chargement est apparu. Les passionnés de vitesse des sites Web ont rapidement identifié plusieurs problèmes majeurs qui entraînaient un chargement lent des sites Web. L'un d'eux était les retards du réseau (RTT - temps d'aller-retour ou temps de ping). Les retards affectent de nombreux processus de chargement d'un site Web : établissement d'une connexion TCP, démarrage d'une session TLS, chargement de chaque ressource individuelle (image, fichier JS, document HTML, etc.)

Le problème a été aggravé par le fait qu'en utilisant le protocole HTTP/1.1 (avant l'avènement de SPDY, QUIC et HTTP/2, c'était la seule option), les navigateurs n'ouvrent pas plus de 6 connexions TCP vers un hôte. Tout cela a entraîné des temps d’arrêt de la connexion et une utilisation inefficace de la bande passante du canal. Le problème a été partiellement résolu par le partage de domaine - la création d'hôtes supplémentaires pour surmonter la limite du nombre de connexions.

C'est ici qu'apparaît la deuxième capacité du CDN : réduire la latence (RTT) grâce au grand nombre de points et à la proximité des nœuds avec l'utilisateur. La distance joue ici un rôle déterminant : la vitesse de la lumière est limitée (environ 200 000 km/sec dans la fibre optique). Cela signifie que tous les 1000 5 km de trajet ajoutent 10 ms de retard ou XNUMX ms au RTT. Il s'agit du temps minimum requis pour la transmission, car il existe également des retards sur les équipements intermédiaires. Puisqu'un CDN sait généralement comment mettre en cache les objets sur ses serveurs, nous pouvons bénéficier du chargement de ces objets via un CDN. Conditions nécessaires pour cela : la présence de l'objet dans le cache, la proximité du point CDN avec l'utilisateur par rapport au serveur d'application web (serveur d'origine). Il est important de comprendre que la proximité géographique d’un nœud CDN ne garantit pas une faible latence. Le routage entre le client et le CDN peut être construit de telle manière que le client se connecte à un hôte dans un autre pays, et éventuellement sur un autre continent. C’est ici qu’interviennent la relation entre les opérateurs télécoms et le service CDN (peering, connexions, participation à IX, etc.) et la politique d’acheminement du trafic du CDN lui-même. Par exemple, Cloudflare, lors de l'utilisation de deux forfaits initiaux (gratuit et bon marché), ne garantit pas la livraison du contenu depuis l'hébergeur le plus proche - l'hébergeur sera sélectionné pour atteindre le coût minimum.

De nombreuses sociétés Internet de premier plan suscitent l’intérêt du public (développeurs Web et propriétaires de services) sur le thème de la vitesse de chargement et des performances des sites Web. Parmi ces sociétés figurent Yahoo (outil Yslow), AOL (WebPageTest) et Google (service Page Speed Insights), qui développent leurs propres recommandations pour accélérer les sites (elles concernent principalement l'optimisation des clients). Plus tard, de nouveaux outils de test de vitesse de site Web apparaissent, qui fournissent également des conseils pour augmenter la vitesse du site Web. Chacun de ces services ou plugins a une recommandation cohérente : « Utilisez un CDN. » La réduction de la latence du réseau est généralement citée pour expliquer l’effet du CDN. Malheureusement, tout le monde n'est pas prêt à comprendre exactement comment l'effet d'accélération du CDN est obtenu et comment il peut être mesuré, c'est pourquoi la recommandation est prise de bonne foi et utilisée comme postulat. En fait, tous les CDN ne sont pas égaux.

Utiliser un CDN aujourd'hui

Pour évaluer l’utilité de l’utilisation des CDN, il faut les classer. Ce que l'on retrouve aujourd'hui dans la pratique (les exemples entre parenthèses ne sont bien entendu pas exhaustifs) :

CDN gratuit pour la distribution des bibliothèques JS (MaxCDN, Google. Yandex).
CDN de services pour l'optimisation client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
CDN pour l'optimisation statique et des ressources dans CMS (disponible dans Bitrix, WordPress et autres).
CDN à usage général (StackPath, CDNVideo, NGENIX, Megafon).
CDN pour l'accélération de sites Web (Cloudflare, Imperva, Airi).

La principale différence entre ces types réside dans la part du trafic qui transite par le CDN. Les types 1 à 3 correspondent à la livraison d'une partie seulement du contenu : d'une demande à plusieurs dizaines (généralement des images). Les types 4 et 5 sont un proxy complet du trafic via un CDN.

En pratique, cela signifie le nombre de connexions utilisées pour charger le site. Avec HTTP/2, nous utilisons une seule connexion TCP à l'hôte pour traiter un nombre illimité de requêtes. Si nous divisons les ressources entre l'hôte principal (origine) et le CDN, il est alors nécessaire de répartir les requêtes sur plusieurs domaines et de créer plusieurs connexions TCP. Le pire des cas est : DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Cette formule ne prend pas en compte les délais dans les réseaux mobiles pour l'activation du canal radio de l'appareil (s'il n'était pas actif) et les délais sur la tour de téléphonie cellulaire.

Voici à quoi cela ressemble sur la cascade de chargement du site (les latences de connexion au CDN sont mises en évidence à RTT 150 ms) :

Si le CDN couvre tout le trafic du site (à l'exception des services tiers), nous pouvons alors utiliser une seule connexion TCP, économisant ainsi les délais de connexion à des hôtes supplémentaires. Bien entendu, cela s’applique aux connexions HTTP/2.

D'autres différences sont déterminées par la fonctionnalité d'un CDN particulier - pour le premier type, il héberge simplement un fichier statique, pour le cinquième, il modifie plusieurs types de contenu du site à des fins d'optimisation.

Capacités CDN pour l'accélération des sites Web

Décrivons la gamme complète des capacités CDN pour accélérer les sites, sans tenir compte des fonctionnalités des types individuels de CDN, puis voyons ce qui est implémenté dans chacun d'eux.

1. Compression des ressources textuelles

La fonctionnalité la plus basique et la plus compréhensible, mais souvent mal implémentée. Tous les CDN déclarent la présence de la compression comme fonction d'accélération. Mais si l’on y regarde de plus près, les lacunes deviennent évidentes :

de faibles degrés de compression dynamique peuvent être utilisés - 5-6 (par exemple, pour gzip, le maximum est de 9) ;
la compression statique (fichiers en cache) n'utilise pas de fonctionnalités supplémentaires (par exemple, zopfi ou brotli avec le degré 11)
il n'y a pas de support pour une compression brotli efficace (économie d'environ 20 % par rapport à gzip).

Si vous utilisez un CDN, cela vaut la peine de vérifier ces quelques points : prenez le fichier qui provient du CDN, enregistrez sa taille compressée et compressez-le manuellement pour comparaison (vous pouvez utiliser un service en ligne avec le support brotli, par exemple vsszhat.rf).

2. Définition des en-têtes de mise en cache du client

Également une fonctionnalité d'accélération simple : ajoutez des en-têtes pour la mise en cache du contenu par le client (navigateur). L'en-tête le plus récent est cache-control, l'en-tête obsolète expire. De plus, Etag peut être utilisé. L'essentiel est que l'âge maximum du contrôle du cache soit suffisamment grand (d'un mois ou plus). Si vous êtes prêt à mettre en cache la ressource aussi durement que possible, vous pouvez ajouter l'option immuable.

Les CDN peuvent réduire la valeur d'âge maximum, obligeant l'utilisateur à recharger le contenu statique plus souvent. On ne sait pas à quoi cela est lié : le désir d'augmenter le trafic sur le réseau ou d'augmenter la compatibilité avec des sites qui ne savent pas réinitialiser le cache. Par exemple, la durée par défaut du cache d'en-tête Cloudflare est d'une heure, ce qui est très faible pour les données statiques immuables.

3. Optimisation des images

Étant donné que le CDN assume les fonctions de mise en cache et de diffusion des images, il serait logique de les optimiser côté CDN et de les servir aux utilisateurs sous cette forme. Réservons tout de suite que cette fonctionnalité n'est disponible que pour les types CDN 2, 3 et 5.

Vous pouvez optimiser les images de différentes manières : en utilisant des formats de compression avancés (tels que WebP), des encodeurs plus efficaces (MozJPEG) ou simplement en nettoyant les métadonnées inutiles.

En général, il existe deux types de telles optimisations : avec perte de qualité et sans perte de qualité. Les CDN s'efforcent généralement d'utiliser une optimisation sans perte afin d'éviter d'éventuelles plaintes de clients concernant les changements dans la qualité de l'image. Dans de telles conditions, le gain sera minime. En réalité, le niveau de qualité JPEG est souvent bien supérieur à ce qui est nécessaire et vous pouvez recompresser en toute sécurité avec un niveau de qualité inférieur sans compromettre l'expérience utilisateur. En revanche, il est difficile de déterminer le niveau de qualité et les paramètres de manière universelle pour toutes les applications Web possibles, c'est pourquoi les CDN utilisent des paramètres plus conservateurs par rapport à ceux qui peuvent être appliqués en tenant compte du contexte (objectif des images, type d'application Web). , etc.)

4. Optimisation de la connexion TLS

Aujourd’hui, la plupart du trafic transite via des connexions TLS, ce qui signifie que nous consacrons plus de temps à la négociation TLS. Récemment, de nouvelles technologies ont été développées pour accélérer ce processus. Par exemple, il s'agit de la cryptographie EC, de TLS 1.3, du cache de session et des tickets, de l'accélération du chiffrement matériel (AES-NI), etc. Un réglage correct de TLS peut réduire le temps de connexion à 0-1 RTT (sans compter DNS et TCP).

Avec des logiciels modernes, il n’est pas difficile de mettre en œuvre de telles pratiques par vous-même.

Tous les CDN n'implémentent pas les bonnes pratiques TLS ; vous pouvez le vérifier en mesurant le temps de connexion TLS (par exemple, dans Webpagetest). Idéal pour une nouvelle connexion - 1RTT, 2RTT - niveau moyen, 3RTT et plus - mauvais.

Il convient également de noter que même lors de l'utilisation de TLS au niveau CDN, le serveur avec notre application Web doit également traiter TLS, mais du côté CDN, car le trafic entre le serveur et le CDN passe sur le réseau public. Dans le pire des cas, nous obtiendrons des délais de connexion TLS doubles (le premier vers l'hôte CDN, le second entre celui-ci et notre serveur).

Pour certaines applications, il convient de prêter attention aux problèmes de sécurité : le trafic est généralement déchiffré sur les nœuds CDN, ce qui constitue une opportunité potentielle d'interception du trafic. La possibilité de travailler sans divulgation du trafic est généralement proposée dans les meilleurs plans tarifaires moyennant des frais supplémentaires.

5. Réduisez les délais de connexion

Le principal avantage du CDN dont tout le monde parle : une faible latence (moins de distance) entre l’hôte CDN et l’utilisateur. Réalisé en créant une architecture de réseau géographiquement distribuée, dans laquelle les hôtes sont situés dans des points de concentration d'utilisateurs (villes, points d'échange de trafic, etc.)

Dans la pratique, les priorités des différents réseaux peuvent se situer dans des régions spécifiques. Par exemple, les CDN russes auront davantage de points de présence en Russie. Les Américains vont d'abord développer le réseau aux USA. Par exemple, l'un des plus grands CDN Cloudflare ne possède que 2 points en Russie - Moscou et Saint-Pétersbourg. Autrement dit, nous pouvons économiser au maximum environ 10 ms de latence par rapport au placement direct à Moscou.

La plupart des CDN occidentaux n’ont pas de points en Russie. En vous connectant à eux, vous ne pouvez qu’augmenter les délais pour votre public russe.

6. Optimisation du contenu (minification, changements structurels)

Le point le plus complexe et technologiquement avancé. Changer le contenu pendant la livraison peut être très risqué. Même si l'on prend la minification : réduire le code source (en raison d'espaces supplémentaires, de structures sans importance, etc.) peut affecter ses performances. Si l'on parle de changements plus sérieux - déplacer le code JS à la fin du HTML, fusionner des fichiers, etc. - le risque de perturber la fonctionnalité du site est encore plus élevé.

Par conséquent, seuls certains CDN de type 5 le font. Bien entendu, il ne sera pas possible d’automatiser tous les changements nécessaires pour accélérer les choses : une analyse et une optimisation manuelles sont nécessaires. Par exemple, la suppression du code inutilisé ou en double est une tâche manuelle.

En règle générale, toutes ces optimisations sont contrôlées par les paramètres et les plus dangereuses sont désactivées par défaut.

Prise en charge des capacités d'accélération par type de CDN

Jetons donc un coup d'œil aux opportunités d'accélération potentielles offertes par les différents types de CDN.

Pour plus de commodité, nous répétons la classification.

CDN gratuit pour la distribution des bibliothèques JS (MaxCDN, Google. Yandex).
CDN de services pour l'optimisation client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
CDN pour l'optimisation statique et des ressources dans CMS (disponible dans Bitrix, WordPress et autres).
CDN à usage général (StackPath, CDNVideo, NGENIX, Megafon).
CDN pour l'accélération de sites Web (Cloudflare, Imperva, Airi).

Comparons maintenant les fonctionnalités et les types de CDN.

Occasion
Type 1
Type 2
Type 3
Type 4
Type 5

Compression de texte
+–
-
+–
+–
+

En-têtes de cache
+
+
+
+
+

images
-
+–
+–
-
+

TLS
-
-
-
+–
+

Retards
-
-
-
+
+

contenu
-
-
-
-
+

Dans ce tableau, « + » est utilisé pour indiquer une prise en charge totale, « - » n'est pas une prise en charge et « – » est une prise en charge partielle. Bien sûr, il peut y avoir des écarts par rapport à ce tableau dans la réalité (par exemple, certains CDN à usage général implémenteront des fonctionnalités d'optimisation des images), mais pour une idée générale, c'est utile.

Les résultats de

Espérons qu'après avoir lu cet article, vous aurez une idée plus claire de la recommandation « utiliser un CDN » pour accélérer vos sites.

Comme dans toute entreprise, vous ne pouvez pas croire les promesses marketing d’un service. L'effet doit être mesuré et testé dans des conditions réelles. Si vous utilisez déjà un CDN, vérifiez son efficacité en utilisant les critères décrits dans l'article.

Il est possible que l'utilisation actuelle d'un CDN ralentisse le temps de chargement de votre site.

À titre de recommandation générale, nous pouvons nous concentrer sur les éléments suivants : étudier votre audience, déterminer son étendue géographique. Si votre audience principale est concentrée dans un rayon de 1 à 2 XNUMX kilomètres, vous n'avez pas besoin d'un CDN pour son objectif principal : réduire la latence. Au lieu de cela, vous pouvez rapprocher votre serveur de vos utilisateurs et le configurer correctement, obtenant la plupart des optimisations décrites dans l'article (gratuites et permanentes).

Dans le cas où votre audience est réellement répartie géographiquement (rayon de plus de 3000 kilomètres), utiliser un CDN de qualité sera vraiment utile. Cependant, vous devez comprendre à l'avance ce que votre CDN peut exactement accélérer (voir le tableau des capacités et leur description). Cependant, l’accélération d’un site Web reste encore une tâche complexe qui ne peut être résolue par la connexion d’un CDN. En plus des optimisations ci-dessus, les moyens d'accélération les plus efficaces restent derrière le CDN : optimisation de la partie serveur, modifications avancées de la partie client (suppression du code inutilisé, optimisation du processus de rendu, travail avec les contenus, les polices, adaptabilité, etc. )

Source: habr.com

[Ne pas] utiliser un CDN