[Ne] pas utiliser CDN

Pratiquement tous les articles ou outils d'optimisation de la vitesse des sites incluent une mention discrète de « l'utilisation de CDN ». En effet, un CDN est un réseau de distribution de contenu. Dans notre entreprise « Méthode Lab », nous sommes souvent confrontés aux questions des clients à ce sujet, certains activant eux-mêmes un CDN. L'objectif de cet article est de comprendre ce que peut apporter un CDN 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 entourés sur l'image sont causés par l'utilisation d'un CDN.

Un peu d'histoire

Comme beaucoup de technologies, les CDN sont apparus par nécessité. Avec l'évolution des canaux Internet des utilisateurs, des services de vidéo en ligne ont vu le jour. Il est évident que le contenu vidéo nécessite une bande passante bien plus importante par rapport au contenu classique des sites (images, texte, et code CSS ou JS).

Lors d'une tentative de diffusion simultanée d'un flux vidéo à de nombreux clients à partir d'un seul serveur, le goulot d'étranglement sera probablement le canal Internet du serveur. En général, quelques milliers de flux suffisent à saturer un canal serveur typique. Bien sûr, d'autres limitations de ressources peuvent exister, mais elles ne sont pas pertinentes ici. Il est également important de noter que l'augmentation de la capacité du canal serveur est souvent trop coûteuse (et parfois impossible), et qu'elle n'est pas non plus judicieuse. La charge sur le canal durant les diffusions aura un caractère cyclique.

Le problème de limitation de bande passante d'un serveur unique est parfaitement résolu par un CDN. Les clients ne se connectent pas directement au serveur, mais à des nœuds du réseau CDN. Idéalement, le serveur transmet un seul flux à un nœud CDN, tandis que le réseau utilise ses propres ressources pour livrer ce flux à de nombreux utilisateurs. D'un point de vue économique, nous ne payons que pour les ressources effectivement consommées (ce qui peut être la bande passante ou les données) et obtenons une excellente évolutivité de notre service. L'utilisation de CDN pour la livraison de contenu lourd est entièrement justifiée et logique. Cependant, il convient de noter que les plus grands acteurs de ce domaine (comme Netflix) construisent leurs propres CDN plutôt que d'utiliser de grands CDN commerciaux (Akamai, Cloudflare, Fastly, etc.).

Au fur et à mesure que le web évolue, les applications web elles-mêmes deviennent plus complexes et lourdes. Le problème de la vitesse de chargement est devenu central. Les passionnés de vitesse des sites ont rapidement identifié quelques problèmes principaux qui entraînaient un chargement lent des sites. L'un de ces problèmes était les retards réseau (RTT — round trip time ou temps de ping). Les retards influencent de nombreux processus lors du chargement d'un site : l'établissement de la connexion TCP, le démarrage de la session TLS, le chargement de chaque ressource distincte (image, fichier JS, document HTML, etc.)

Le problème était aggravé par le fait qu'avec le protocole HTTP/1.1 (avant l'apparition de SPDY, QUIC et HTTP/2, c'était la seule option), les navigateurs n'ouvraient pas plus de 6 connexions TCP à un même hôte. Tout cela entraînait des temps d'attente pour la connexion et une utilisation inefficace de la bande passante. Le problème était partiellement résolu par le sharding de domaine — la création d'hôtes supplémentaires pour contourner la limite du nombre de connexions.

C'est ici qu'apparaît la deuxième capacité du CDN – la réduction des retards (RTT) grâce à un grand nombre de points et à la proximité des nœuds avec l'utilisateur. La distance joue un rôle décisif : la vitesse de la lumière est limitée (environ 200 000 km/s dans la fibre optique). Cela signifie que chaque 1000 km parcourus ajoute 5 ms de retard ou 10 ms au RTT. Ce sont les coûts de temps minimaux pour le transfert, car il existe encore des retards sur le matériel intermédiaire. Comme le CDN est généralement capable de mettre en cache des objets sur ses serveurs, nous pouvons bénéficier du chargement de ces objets via le CDN. Les conditions nécessaires pour cela sont : la présence de l'objet dans le cache et 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 du nœud CDN ne garantit pas de faibles retards. Le routage entre le client et le CDN peut être configuré de telle manière que le client se connecte à un hôte dans un autre pays, voire sur un autre continent. C'est ici que les relations entre les opérateurs de télécommunications et le service CDN entrent en jeu (peering, existence d'interconnexions, participation aux IX, etc.) et la politique de routage du trafic du CDN lui-même. Par exemple, Cloudflare, lors de l'utilisation de ses deux plans de base (gratuit et peu coûteux), ne garantit pas la livraison de contenu depuis le nœud le plus proche – le choix de l'hôte sera effectué pour atteindre le coût minimum.

De nombreuses entreprises internet de premier plan suscitent l'intérêt du public (développeurs web et propriétaires de services) pour le sujet de la vitesse de chargement et de fonctionnement des sites. Parmi ces entreprises, on trouve Yahoo (outil Yslow), AOL (WebPageTest) et Google (service Page Speed Insights), qui développent leurs propres recommandations pour accélérer les sites (celles-ci concernent principalement l'optimisation côté client). Plus tard, de nouveaux outils de test de vitesse de site font leur apparition, offrant également des conseils pour augmenter la vitesse des sites. Dans chacun de ces services ou plugins, on trouve la recommandation invariable « Utilisez un CDN ». Pour expliquer l'effet du CDN, on indique généralement la réduction des latences réseau. Malheureusement, tous ne sont pas prêts à comprendre comment l'effet d'accélération du CDN est atteint et comment il peut être mesuré, si bien que cette recommandation est prise pour argent comptant et utilisée comme un postulat. En réalité, tous les CDN ne sont pas également utiles.

L'utilisation de CDN aujourd'hui

Pour évaluer l'utilité de l'application des CDN, il convient de les classer. Voici ce que l'on peut rencontrer en pratique (les exemples entre parenthèses ne sont bien sûr pas exhaustifs) :

1. CDN gratuits pour la distribution de bibliothèques JS (MaxCDN, Google, Yandex).
2. CDN pour l'optimisation côté client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
3. CDN pour la gestion des fichiers statiques et l'optimisation des ressources dans les CMS (disponibles dans Bitrix, WordPress et d'autres).
4. CDN généralistes (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pour l'accélération des sites (Cloudflare, Imperva, Airi).

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

En pratique, cela signifie le nombre de connexions nécessaires pour charger le site. En utilisant HTTP/2, nous utilisons une seule connexion TCP à l'hôte pour gérer un nombre illimité de requêtes. Si nous séparons les ressources entre l'hôte principal (origin) et le CDN, nous devons répartir les requêtes sur plusieurs domaines et établir plusieurs connexions TCP. Pire encore, cela donne : DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Dans cette formule, les latences 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 station mobile ne sont pas pris en compte.

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

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

Les différences suivantes sont déterminées par la fonctionnalité spécifique du CDN – pour le premier type, il s'agit simplement . C'est très pratique d'avoir tout au même endroit. Grâce à cela, en cas de problème, nos spécialistes vous aideront à le résoudre dans les plus brefs délais. d'un fichier statique, pour le cinquième, il s'agit de modifier plusieurs types de contenu du site pour optimiser.

Capacités du CDN pour accélérer le site

Décrivons l'éventail complet des capacités du CDN pour accélérer les sites, sans tenir compte de la fonctionnalité des différents types de CDN, puis voyons ce qui est réalisé dans chacun d'eux.

1. Compression des ressources textuelles

La capacité la plus basique et évidente, pourtant souvent mal mise en œuvre. Tous les CDN annoncent la compression comme une de leurs fonctionnalités d'accélération. Mais en regardant de plus près, des lacunes apparaissent :

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

Si vous utilisez un CDN, il vaut la peine de vérifier quelques points : prenez un fichier qui est venu du CDN, notez sa taille en version compressée et décompressez-le manuellement pour comparaison (vous pouvez utiliser un service en ligne prenant en charge brotli, par exemple всёсжать.рф).

2. Configuration des en-têtes de cache client

Une autre fonction simple d'accélération : mettre des en-têtes pour le caching du contenu par le client (navigateur). L'en-tête le plus pertinent est cache-control, l'ancien est expires. En outre, Etag peut être utilisé. L'essentiel est que max-age du cache-control soit suffisamment grand (au moins un mois), si vous êtes prêt à mettre le cache du resource aussi strictement que possible, vous pouvez ajouter l'option immutable.

Les CDN peuvent réduire la valeur max-age, obligeant l'utilisateur à recharger plus fréquemment la statique. Pourquoi cela se produit-il : est-ce un désir d'augmenter le trafic sur Internet ou une meilleure compatibilité avec des sites incapables de vider le cache ? Ce n'est pas clair. Par exemple, la durée de mise en cache dans les en-têtes Cloudflare est par défaut de 1 heure, ce qui est très court pour une statique inchangée.

3. Optimisation des images

Puisque le CDN prend en charge la mise en cache et la livraison des images, il est logique de les optimiser du côté du CDN et de les délivrer aux utilisateurs de cette manière. Notons tout de suite que cette possibilité n'est disponible que pour les types de CDN 2, 3 et 5.

Les images peuvent être optimisées de différentes manières : en utilisant des formats de compression avancés (comme WebP), des encodeurs plus efficaces (MozJPEG) ou simplement en nettoyant les métadonnées superflues.

Il existe en général deux types d'optimisations : avec perte de qualité et sans perte de qualité. Les CDN cherchent généralement à utiliser une optimisation sans perte afin d'éviter de possibles plaintes des clients sur un changement de la qualité des images. Dans ces conditions, le gain sera minime. En réalité, le niveau de qualité JPEG dépasse souvent ce qui est nécessaire, et il est possible d'effectuer une recompression avec un taux de qualité inférieur, sans nuire à la perception par les utilisateurs. D'autre part, déterminer un niveau de qualité et des réglages universels pour toutes les applications web possibles est difficile, donc les CDN utilisent des paramètres plus conservateurs par rapport à ceux qui pourraient être appliqués en tenant compte du contexte (destination des images, type d'application web, etc.)

4. Optimisation de la connexion TLS

Aujourd'hui, la majorité du trafic est transmise par des connexions TLS, ce qui signifie que nous perdons du temps sur l'établissement TLS. Récemment, de nouvelles technologies ont été développées pour accélérer ce processus. Par exemple, la cryptographie EC, TLS 1.3, le cache de session et les tickets de session (session tickets), l'accélération matérielle du chiffrement (AES-NI), etc. Une bonne configuration TLS permet de réduire le temps de connexion à 0-1 RTT (sans compter DNS et TCP).

Avec des logiciels modernes, il n'est pas difficile d'implémenter de telles pratiques sur ses propres ressources.

Loin de tous les CDN appliquent les meilleures pratiques en matière de TLS, ce qui peut être vérifié en mesurant le temps de connexion TLS (par exemple, dans Webpagetest). Idéalement, pour une nouvelle connexion, 1 RTT est parfait, 2 RTT est un niveau moyen, 3 RTT et plus sont mauvais.

Il convient également de noter que même en utilisant TLS au niveau du CDN, le serveur avec notre application web doit également traiter TLS, mais du côté du CDN, car le trafic entre le serveur et le CDN passe par un réseau public. Dans le pire des cas, nous avons des délais TLS doublés (le premier vers l'hôte CDN, le deuxième entre lui et notre serveur).

Pour certaines applications, il convient de prêter attention aux questions de sécurité : généralement, le trafic est déchiffré aux nœuds CDN, ce qui constitue une possibilité potentielle d'interception du trafic. Une option de fonctionnement sans divulguer le trafic est généralement proposée dans les forfaits premium moyennant un supplément.

5. Réduction des délais de connexion

Le principal avantage du CDN, dont tout le monde parle : de faibles délais (moins de distance) entre l'hôte CDN et l'utilisateur. Cela est réalisé grâce à une architecture réseau géographiquement distribuée, dans laquelle les hôtes se trouvent dans des points de concentration des utilisateurs (villes, points d'échange de trafic, etc.).

En pratique, les priorités des différents réseaux peuvent se concentrer dans des régions spécifiques. Par exemple, les CDN russes auront plus de points de présence en Russie. Les américains développeront principalement leur 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. Cela signifie que nous pouvons économiser au maximum environ 10 ms de latence par rapport à un hébergement direct à Moscou.

La plupart des CDN occidentaux n'ont tout simplement pas de points en Russie. En vous connectant à eux, vous pouvez uniquement augmenter la latence pour votre public russe.

6. Optimisation du contenu (minification, modifications structurelles)

Le point le plus complexe et technique. Modifier le contenu lors de la livraison peut être très risqué. Même si l'on considère la minification : la réduction du code source (en éliminant les espaces inutiles, les constructions non pertinentes, etc.) peut affecter son fonctionnement. En ce qui concerne des modifications plus sérieuses – le transfert du code JS à la fin du HTML, la fusion de fichiers et similaires – le risque de rompre la fonctionnalité du site est encore plus élevé.

C'est pourquoi seuls quelques CDN de type 5 s'en occupent. Bien sûr, il n'est pas possible d'automatiser tous les changements nécessaires pour accélérer le processus, une analyse manuelle et une optimisation sont requises. Par exemple, la suppression de code inutilisé ou dupliqué fait partie des tâches manuelles.

En général, toutes ces optimisations sont gérées par les paramètres et les options les plus dangereuses sont désactivées par défaut.

Support des fonctionnalités d'accélération par types de CDN

Alors, examinons quelles opportunités potentielles d'accélération offrent les différents types de CDN.

Pour la commodité, récapitulons la classification.

1. CDN gratuits pour la distribution de bibliothèques JS (MaxCDN, Google, Yandex).
2. CDN pour l'optimisation côté client (par exemple, Google Fonts pour les polices, Cloudinary, Cloudimage pour les images).
3. CDN pour la gestion des fichiers statiques et l'optimisation des ressources dans les CMS (disponibles dans Bitrix, WordPress et d'autres).
4. CDN généralistes (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pour l'accélération des sites (Cloudflare, Imperva, Airi).

Nous allons maintenant faire correspondre les caractéristiques et les types de CDN.

Possibilité
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 un soutien complet, « – » pour l'absence, « +– » pour un soutien partiel. Bien sûr, des déviations par rapport à ce tableau peuvent exister dans la réalité (par exemple, un CDN général pourrait intégrer des fonctionnalités d'optimisation d'images), mais il est utile pour avoir une vision générale.

Résultats

J'espère qu'en lisant cet article, vous aurez une vision plus claire de la recommandation « utilisez un CDN » pour accélérer les sites.

Comme dans n'importe quel domaine, il ne faut pas croire aux promesses marketing d'un service. L'effet doit être mesuré et vérifié dans des conditions réelles. Si vous utilisez déjà un CDN, vérifiez son efficacité selon les critères décrits dans l'article.

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

En guise de recommandation générale, vous pouvez considérer ce qui suit : étudiez votre audience, définissez ses limites géographiques. Si votre audience principale est concentrée dans un rayon de 1 à 2 mille kilomètres, vous n'avez pas besoin d'un CDN pour sa fonction principale – la réduction des latences. Au lieu de cela, vous pouvez placer votre serveur plus près des utilisateurs et le configurer correctement, en obtenant la plupart des optimisations décrites dans l'article (gratuitement et en permanence).

Si votre audience est véritablement géographiquement dispersée (rayon supérieur à 3000 kilomètres), l'utilisation d'un CDN de qualité sera effectivement bénéfique. Cependant, il est important de comprendre à l'avance ce que votre CDN peut réellement accélérer (voir le tableau des capacités et leur description). L'accélération de votre site reste néanmoins une tâche complexe qui ne se résout pas simplement par la connexion d'un CDN. En plus des optimisations mentionnées, les moyens les plus efficaces pour accélérer le site sont : l'optimisation côté serveur, les modifications avancées côté client (suppression de code inutilisé, optimisation du processus de rendu, gestion du contenu, des polices, de l'adaptabilité, etc.)

Source : habr.com