[Ne pas] utiliser CDN

Dans presque tous les articles ou outils pour optimiser la vitesse des sites, il y a un élément modeste «utiliser CDN». En général, un CDN est un réseau de diffusion de contenu. Chez Method Lab, nous répondons souvent aux questions des clients sur ce sujet, dont certaines incluent des CDN par eux-mêmes. Le but de cet article est de comprendre ce que le CDN peut donner en termes de vitesse de chargement du site, quels problèmes peuvent survenir et dans quels cas l'utilisation du CDN est justifiée.



Les retards dans l'image sont causés par l'utilisation de CDN.

Un peu d'histoire

Comme de nombreuses technologies, les CDN ont émergé au besoin. Avec le développement des canaux Internet pour les internautes, des services de vidéo en ligne sont apparus. Naturellement, le contenu vidéo nécessite une bande passante supérieure de plusieurs ordres de grandeur par rapport au contenu classique d'un site Web (images, texte et code CSS ou JS).

Si vous essayez de diffuser un flux vidéo en parallèle sur plusieurs clients à partir d'un même serveur, le canal Internet du serveur deviendra très probablement un goulot d'étranglement. En règle générale, plusieurs milliers de flux sont suffisants pour obstruer un canal de serveur typique. Bien sûr, il peut y avoir d'autres restrictions de ressources, mais maintenant elles ne sont plus importantes. Il est également important que l'extension du canal du serveur soit trop coûteuse (et parfois impossible), voire impossible. La charge sur la chaîne lors des diffusions sera cyclique.

Le problème de limitation de canal d'un serveur séparé 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 donne un flux au CDN, puis le réseau utilise ses propres ressources pour fournir ce flux à de nombreux utilisateurs. D'un point de vue économique, nous ne payons que pour les ressources réellement consommées (cela peut être de la bande passante ou du trafic) et nous obtenons une excellente évolutivité de notre service. L'utilisation de CDN pour fournir du contenu lourd est parfaitement justifiée et logique. Bien qu'il soit intéressant de noter que les plus grands acteurs dans ce domaine (par exemple, Netflix) construisent leurs CDN au lieu d'utiliser de gros CDN commerciaux (Akamai, Cloudflare, Fastly, etc.)

À mesure que le Web évolue, les applications Web elles-mêmes deviennent plus complexes et plus lourdes. Le problème de la vitesse de téléchargement est venu au premier plan. Les amateurs de vitesse du site ont rapidement repéré plusieurs problèmes majeurs qui ont conduit à un chargement lent du site. L'un d'eux était la latence du réseau (RTT - temps aller-retour ou temps ping). Les retards affectent de nombreux processus de chargement d'un site: établissement d'une connexion TCP, démarrage d'une session TLS, chargement de chaque ressource séparément (images, fichier JS, document HTML, etc.)

Le problème était aggravé par le fait que lors de l'utilisation de la perforation HTTP / 1.1 (avant SPDY, QUIC et HTTP / 2 c'était la seule option), les navigateurs n'ouvraient pas plus de 6 connexions TCP à un hôte. Tout cela a conduit à une connexion simple 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.

Voici la deuxième capacité de réduction du délai CDN (RTT) en raison du grand nombre de points et de la proximité des nœuds à l'utilisateur. La distance joue ici un rôle déterminant: la vitesse de la lumière est limitée (environ 200 000 km / s en fibre optique). Cela signifie que chaque 1000 km de trajet ajoute 5 ms de retard ou 10 ms à RTT. Il s'agit du temps de transmission minimum, car il y a encore des retards sur l'équipement intermédiaire. Puisqu'un CDN peut généralement mettre en cache des objets sur ses serveurs, nous pouvons bénéficier du chargement de ces objets via un CDN. Prérequis pour cela: la présence d'un objet dans le cache, la proximité du point CDN à l'utilisateur par rapport au serveur d'applications Web (serveur d'origine). Il est important de comprendre que la proximité géographique du CDN ne garantit pas une faible latence. Le routage entre le client et le CDN peut être conçu de telle sorte que le client se connecte à un hôte dans un autre pays, et éventuellement sur un autre continent. Ici, les relations entre les opérateurs de télécommunications et le service CDN (peering, présence d'interfaces, participation à IX, etc.) et la politique d'acheminement du trafic du CDN lui-même entrent en vigueur. Par exemple, lors de l'utilisation de deux plans initiaux (gratuits et bon marché), Cloudflare ne garantit pas la livraison de contenu à partir du site le plus proche - l'hôte sera sélectionné pour atteindre le coût minimum.

De nombreuses sociétés Internet de premier plan ont suscité l'intérêt du public (développeurs Web et propriétaires de services) en ce qui concerne la vitesse de téléchargement et les performances du site Web. Parmi ces entreprises, on compte Yahoo (outil Yslow), AOL (WebPageTest) et Google (service Page Speed ​​Insights), qui développent leurs recommandations sur l'accélération du site Web (principalement, elles concernent l'optimisation client). Plus récemment, de nouveaux outils de test de vitesse de site arrivent, qui fournissent également des conseils pour augmenter la vitesse du site. Dans chacun de ces services ou plugins, il existe une recommandation inchangée «Utiliser CDN». Pour expliquer l'effet du CDN, une réduction des retards réseau est généralement indiquée. Malheureusement, tout le monde n'est pas prêt à comprendre comment l'effet de l'accélération du CDN est atteint et comment il peut être mesuré.La recommandation est donc prise sur la foi et utilisée comme postulat. En fait, tous les CDN ne sont pas également utiles.

Utiliser CDN aujourd'hui

Pour évaluer l'utilité de l'utilisation des CDN, ils doivent être classés. Ce que l'on peut trouver maintenant dans la pratique (les exemples entre parenthèses ne sont certainement pas exhaustifs):

1. CDN gratuits pour la distribution des bibliothèques JS (MaxCDN, Google. Yandex).
2. Services CDN pour l'optimisation client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
3. CDN pour la statique et l'optimisation des ressources dans CMS (disponible dans Bitrix, Wordpress et autres).
4. CDN à usage général (StackPath, CDNVideo, NGENIX, Megaphone).
5. DNS pour l'accélération de sites Web (Cloudflare, Imperva, Airi).

La principale différence entre ces types est la suivante: quelle partie du trafic passe par le CDN. Les types 1 à 3 sont 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 trafic proxy complet via le CDN.

En pratique, cela signifie le nombre de connexions utilisées pour télécharger le site. Lorsque vous utilisez HTTP / 2, nous utilisons une connexion TCP à l'hôte pour traiter n'importe quel nombre de demandes. Si nous partageons des ressources sur l'hôte principal (origine) et CDN, il est alors nécessaire de répartir les demandes sur plusieurs domaines et de créer plusieurs connexions TCP. Dans le pire des cas, c'est: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Cette formule ne prend pas en compte les retards dans les réseaux mobiles lors de l'activation du canal radio de l'appareil (s'il n'était pas actif) et les retards sur la tour cellulaire.

Voici à quoi cela ressemble sur le chargement en cascade du site (les retards sont mis en évidence pour la connexion à un CDN avec RTT 150 ms):



Si le CDN couvre tout le trafic du site (à l'exception des services tiers), nous pouvons utiliser une seule connexion TCP, ce qui réduit les délais de connexion à des hôtes supplémentaires. Bien sûr, 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 s'agit simplement d'héberger un fichier statique, pour le cinquième, il modifie plusieurs types de contenu de site afin de l'optimiser.

Fonctionnalités d'accélération du site Web CDN

Décrivons la gamme complète des capacités d'accélération du site Web de CDN, sans tenir compte de la fonctionnalité des types individuels de CDN, puis voyons ce qui est mis en œuvre dans chacun d'eux.

1. Compression des ressources textuelles

Cependant, la fonctionnalité la plus élémentaire et la plus compréhensible sont souvent mal implémentées. La présence de compression déclare tous les CDN comme leurs caractéristiques d'accélération. Mais si vous regardez plus en détail, les défauts sont clarifiés:

• de faibles degrés peuvent être utilisés pour la compression dynamique - 5-6 (par exemple, pour gzip maximum - 9);
• en compression statique (fichiers dans le cache) les fonctionnalités supplémentaires ne sont pas utilisées (par exemple, zopfi ou brotli avec une puissance de 11)
• aucun support pour la compression efficace de brotli (économie d'environ 20% par rapport à gzip).

Si vous utilisez CDN, vous devez vérifier ces quelques points: prenez le fichier provenant du CDN, corrigez sa taille compressée et compressez-le manuellement pour comparaison (vous pouvez utiliser un service en ligne avec le support de brotli, par exemple, compress.rf ).

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

Aussi une fonctionnalité simple pour accélérer: mettre des en-têtes pour la mise en cache du contenu par le client (navigateur). L'en-tête de contrôle de cache le plus récent, expiré est expiré. De plus, Etag peut être utilisé. L'essentiel est que l'âge maximum du contrôle du cache soit suffisamment grand (à partir d'un mois ou plus), si vous êtes prêt à mettre en cache la ressource aussi dur que possible, vous pouvez ajouter l'option immuable.

Les CDN peuvent sous-estimer la valeur max-age, forçant l'utilisateur à recharger la statique plus souvent. Quelle est la raison: avec le désir d'augmenter le trafic sur le réseau ou d'augmenter la compatibilité avec les sites qui ne savent pas vider le cache - ce n'est pas clair. Par exemple, le temps de mise en cache par défaut pour les en-têtes Cloudflare est de 1 heure, ce qui est très petit pour les statiques immuables.

3. Optimisation d'image

Étant donné que le CDN prend en charge les fonctions de mise en cache et de téléchargement d'images, il serait logique de les optimiser du côté du CDN et de les donner aux utilisateurs sous cette forme. Faisons une réservation tout de suite, 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 (par exemple, WebP), des encodeurs plus efficaces (MozJPEG) ou simplement en nettoyant les métadonnées inutiles.

En général, il existe deux types d'optimisations de ce type: avec perte de qualité et sans perte de qualité. Les CDN cherchent généralement à utiliser l'optimisation sans perte afin d'éviter les plaintes potentielles des clients concernant les changements de qualité d'image. Dans de telles conditions, le gain sera minime. En réalité, le niveau de qualité du JPEG est souvent bien plus élevé que nécessaire et vous pouvez effectuer une recompression en toute sécurité avec un indicateur de qualité inférieure, sans compromettre la perception des utilisateurs. En revanche, il est difficile de déterminer le niveau de qualité et les paramètres universellement pour toutes les applications Web possibles, de sorte que les CDN utilisent des paramètres plus conservateurs par rapport à ceux qui peuvent être appliqués en tenant compte du contexte (affectation d'image, type d'application Web, etc.)

4. Optimisation de la connexion TLS

Aujourd'hui, la plupart du trafic est transmis 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 (tickets de session), de l'accélération du chiffrement matériel (AES-NI), etc. Une configuration appropriée de TLS peut réduire le temps de connexion à 0-1 RTT (sans DNS ni TCP) )

En présence de logiciels modernes, il n'est pas difficile de mettre en œuvre de telles pratiques dans nos propres installations.

Tous les CDN n'implémentent pas les meilleures pratiques TLS; cela peut être vérifié en mesurant l'heure de la 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 gérer 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 obtenons un double retard de la connexion TLS (le premier vers l'hôte CDN, le second entre lui et notre serveur).

Pour certaines applications, vous devez faire attention aux problèmes de sécurité: généralement, le trafic est déchiffré sur les nœuds CDN, et c'est une opportunité potentielle d'intercepter le trafic. La possibilité de travailler sans divulguer le trafic est généralement offerte dans les plans tarifaires haut de gamme moyennant des frais.

5. Réduction des délais de connexion

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

Dans la pratique, les priorités pour différents réseaux peuvent se situer dans des régions spécifiques. Par exemple, les CDN russes auront plus de points de présence en Russie. American développera principalement un réseau aux États-Unis. Par exemple, l'un des plus grands CDN Cloudflare n'a que 2 points en Russie - Moscou et Saint-Pétersbourg. Autrement dit, nous pouvons économiser environ 10 ms de retard par rapport à l'hébergement direct à Moscou.

La plupart des CDN occidentaux n'ont aucun point en Russie. En vous connectant à eux, vous ne pouvez qu'augmenter les retards pour votre public russe.

6. Optimisation du contenu (minification, changements structurels)

L'élément le plus complexe et technologique. Changer le contenu à la livraison peut être très risqué. Même si nous prenons la minification: réduire le code source (en raison d'espaces supplémentaires, de constructions sans importance, etc.) peut affecter ses performances. Si nous parlons de changements plus sérieux - déplacer le code JS à la fin du HTML, fusionner des fichiers et autres - le risque de perturber la fonctionnalité du site est encore plus élevé.

Par conséquent, seuls certains CDN de type 5 le font. Bien sûr, cela ne fonctionnera pas pour automatiser tous les changements nécessaires pour accélérer - une analyse et une optimisation manuelles sont nécessaires. Par exemple, la suppression du code inutilisé ou en double se réfère spécifiquement aux tâches manuelles.

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

Prise en charge de l'accélération par type CDN

Voyons donc quelles options d'accélération potentielles offrent différents types de CDN.

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

1. CDN gratuits pour la distribution des bibliothèques JS (MaxCDN, Google. Yandex).
2. Services CDN pour l'optimisation client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
3. CDN pour la statique et l'optimisation des ressources dans CMS (disponible dans Bitrix, Wordpress et autres).
4. CDN à usage général (StackPath, CDNVideo, NGENIX, Megaphone).
5. DNS pour l'accélération de sites Web (Cloudflare, Imperva, Airi).

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



Dans ce tableau, «+» est utilisé pour indiquer un support complet, «-» indique un manque, «+ -» indique un support partiel. Bien sûr, des écarts par rapport à ce tableau sont possibles dans la réalité (par exemple, certains CDN à usage général introduiront des fonctionnalités d'optimisation des images), mais il est utile pour une idée générale.

Résumé

J'espère qu'après avoir lu cet article, vous aurez une idée plus claire de la recommandation «utiliser CDN» pour accélérer les sites.

Comme dans toute entreprise, on ne peut pas croire aux promesses marketing d'un service. L'effet doit être mesuré et vérifié en conditions réelles. Si vous utilisez déjà une sorte de CDN, vérifiez son efficacité selon les critères décrits dans l'article.

Peut-être que l'utilisation de CDN ralentit le chargement de votre site en ce moment.

En tant que recommandation générale, vous pouvez vous concentrer sur les points suivants: étudier votre public, déterminer sa portée géographique. Si votre public principal est concentré dans un rayon de 1 à 2 000 kilomètres, vous n'avez pas besoin de CDN dans le but principal - pour réduire les retards. Au lieu de cela, vous pouvez rapprocher votre serveur des utilisateurs et le configurer correctement, en obtenant la plupart des optimisations décrites dans l'article (gratuites et permanentes).

Si votre audience est vraiment géographiquement répartie (rayon de plus de 3 000 kilomètres), l'utilisation d'un CDN de qualité sera vraiment utile. Cependant, vous devez comprendre à l'avance ce que votre CDN peut accélérer (voir le tableau des fonctionnalités et leur description). Dans le même temps, l'accélération du site Web reste une tâche complexe qui ne peut pas être résolue en connectant un CDN. En plus des optimisations indiquées, les outils d'accélération les plus efficaces restent par dessus bord CDN: optimisation de la partie serveur, modifications avancées de la partie client (suppression du code inutilisé, optimisation du processus de rendu, travail avec le contenu, les polices, l'adaptabilité, etc.)