CDN contre Cache
Un réseau de distribution de contenu (CDN) est un système de serveurs distribués qui diffusent des contenus et des pages web aux utilisateurs en fonction de leur emplacement géographique afin d’améliorer les performances et réduire la latence. Un CDN effectue la mise en cache, qui est une fonctionnalité essentielle d'un CDN. Il met en cache et stocke les fichiers essentiels de votre site web, tels que les pages HTML, les fichiers JavaScript, les fichiers CSS, les images et les vidéos sur des serveurs en périphérie, accélérant les temps de chargement.
Qu’est-ce qu’un cache CDN ?
Dans le contexte des CDN, la mise en cache CDN réduit la latence en vous permettant de diffuser votre contenu depuis un emplacement plus proche de l'utilisateur, ce qui améliore considérablement les temps de chargement. Elle fonctionne en stockant des copies du contenu sur des serveurs périphériques répartis dans le monde entier. Dès qu’un utilisateur demande un contenu, le CDN le lui diffuse depuis le serveur périphérique le plus proche au lieu d’attendre la réponse de votre serveur d’origine. La charge de travail sur le serveur d’origine s’en trouve réduite et cela permet de prendre en charge un volume de trafic plus important en répartissant les requêtes sur plusieurs serveurs.
Étant donné qu'un CDN est essentiellement un cache, il pourrait être tentant de simplifier les choses en n'utilisant pas le cache du navigateur. Cependant, chaque cache présente des avantages que l'autre ne propose pas. Dans cet article, je vais vous expliquer les avantages de chacun et comment les combiner pour optimiser les performances de votre site web et offrir la meilleure expérience possible à vos utilisateurs finaux.
Qu’est-ce que le cache busting ?
Le cache busting est le processus consistant à télécharger un nouveau fichier pour remplacer un fichier existant et mis en cache. Il est utile car il empêche le navigateur de récupérer l'ancien fichier que vous remplacez.
Pourquoi utiliser la navigation en cache CDN ?
Bien que les CDN soient efficaces pour fournir des ressources très rapidement, ils ne peuvent pas grand-chose pour les utilisateurs qui se trouvent dans des zones isolées et qui n'ont pratiquement aucun réseau sur leur téléphone. En effet, aux États-Unis, le 95e centile du temps aller-retour (RTT) vers tous les CDN dépasse largement les 200 millisecondes, selon les rapports de Cedexis. Cela signifie qu'au moins 5 % de vos utilisateurs, sinon plus, sont susceptibles de rencontrer des ralentissements lors de l'utilisation de votre site web ou de votre application. À titre de référence, le 50e percentile, ou médiane, du RTT est d’environ 45 millisecondes.
Alors pourquoi utiliser un CDN ? Pourquoi ne pas simplement utiliser le cache du navigateur ?
Le contrôle. Avec la plupart des CDN, vous avez la possibilité de purger vos ressources de leur cache, ce qui est particulièrement utile lorsque vous apportez des modifications à vos ressources. Vous n'avez pas cette option avec le cache du navigateur.
Les premières impressions comptent. Le cache du navigateur n'est d'aucune utilité lors de la première visite d'un utilisateur sur votre site, car il est vide (il ne contient aucun objet utile). Les CDN optimisent l'expérience utilisateur malgré un cache de navigateur vide, et un cache de navigateur plein accélère encore davantage le chargement des pages suivantes.
Les CDN conservent un avantage géographique. Même si un utilisateur se situe dans le 95e centile, un temps de réponse aller-retour (RTT) de 250 millisecondes reste préférable à un RTT de 350 millisecondes. Cela est particulièrement vrai si l'on considère que chaque ressource nécessite au moins un aller-retour sur une connexion ouverte, mais qu'un aller-retour supplémentaire est nécessaire pour ouvrir ladite connexion. La sécurité de la couche de transport (TLS, anciennement appelé SSL) ajoute au moins un aller-retour supplémentaire par connexion, parfois deux. Tous ces allers-retours supplémentaires se cumulent rapidement.
Les CDN sont beaucoup plus efficaces, car leur cache est partagé entre tous vos utilisateurs. Cela signifie une charge moindre sur vos serveurs d’origine, sans nécessiter une couche de mise en cache propre à votre plateforme.
Comment utiliser à la fois le CDN et le cache du navigateur
Maintenant que nous avons déterminé qu’un CDN est toujours important et que le cache du navigateur est également très précieux, voici deux approches pour combiner les deux :
Un court temps de vie (TTL) pour le cache du navigateur, associée à des TTL longs et à une purge côté CDN.
Un TTL long pour le CDN et le cache du navigateur, mais avec des cache busters basés sur la version.
Ci-dessous, vous trouverez une description détaillée de chaque approche, ainsi que des explications sur la manière dont vous pouvez combiner les deux.
TTL courts et longs
Idéalement, il serait préférable d'utiliser un TTL pour le cache du navigateur qui couvre l'ensemble d'une visite, mais pas beaucoup plus. De cette façon, vos utilisateurs bénéficient de chargements de page rapides tout au long de leur visite, mais ne se retrouvent pas avec des ressources obsolètes lorsqu'ils reviennent plus tard. Vos outils analytiques devraient être en mesure de vous indiquer le temps de visite de votre site, mais une durée de 5 à 10 minutes est généralement une bonne approximation.
Du côté de Fastly, je recommanderais d'utiliser une durée de vie (TTL) d'un mois ou d'un an, par exemple, et de configurer la purge dans le cadre de votre pipeline de déploiement afin que Fastly puisse fournir les nouvelles versions dès que possible. Pour plus d’informations sur la purge, consulter https://docs.fastly.com/guides/purging/.
Remarque : n'envoyez pas la commande de purge tant que vous n'avez pas la garantie que les nouvelles versions des ressources que vous mettez à jour sont fournies par l'origine. J'ai observé des cas où une personne a envoyé une purge à Fastly, et Fastly a immédiatement récupéré le fichier avant que celui-ci ne soit synchronisé avec les serveurs d'origine, ce qui a entraîné une certaine confusion.
Pour définir le Temps de vie (TTL) du cache du navigateur, utilisez un en-tête Cache-Control dans votre réponse d'origine. Utilisez ensuite l'en-tête Surrogate-Control ou un substitut dans votre configuration Fastly pour définir le temps de vie (TTL).
Voici un exemple du premier cas :
Cache-Control : max-age=600
Surrogate-Control : : max-age=31536000Dans l'exemple ci-dessus, l'en-tête Cache-Control indique au navigateur de mettre en cache pendant 10 minutes, et à Fastly de mettre en cache pendant un an. L'en-tête Surrogate-Control est supprimé avant que la réponse ne soit envoyée au client, ce qui occulte ce détail d'implémentation aux utilisateurs. Consultez notre documentation pour plus d'informations sur les en-têtes que vous pouvez utiliser pour contrôler les TTL avec Fastly.
Cache Busters basés sur les versions
Malgré leur nom, les cache busters peuvent en réalité améliorer la mise en cache lorsqu'ils sont utilisés judicieusement. Un cache buster est essentiellement un nouveau paramètre de chaîne de requête ajouté à l'URL. Alors que les serveurs web et la plupart des serveurs d'applications ignorent simplement les paramètres de chaîne de requête qui ne les intéressent pas, les caches doivent supposer que toute différence dans la chaîne de requête aura une influence sur le résultat. Cela inclut le cache du navigateur. Les navigateurs doivent traiter chacun des éléments suivants comme trois objets uniques, même si le serveur renvoie exactement la même réponse pour chacun d'entre eux :
https://www.example.com/css/main.css, https://www.example.com/css/main.css?cb=foo, et https://www.example.com/css/main.css?foo=bar
Supposons que votre application soit sur la version 133. Au lieu de renvoyer vers https://www.example.com/css/main.css votre application renverrait vers https://www.example.com/css/main.css?v=133. Lorsque vous créez la version 134, vous renvoyez plutôt vers https://www.example.com/css/main.css?v=134. Le navigateur doit alors récupérer cette nouvelle version de main.css, même s'il dispose encore d'une copie non expirée.
Les pratiques courantes consistent à utiliser soit un hachage (court) du contenu du fichier, soit un numéro de build, soit un hachage de commit.
Ma préférence personnelle est d'utiliser un hachage du contenu du fichier. De cette façon, le cache buster ne change que lorsque le contenu change. Avec les numéros de build ou les hachage de commit, le cache buster change à chaque fois que quelque chose change. Cependant, étant donné que toutes les URL des ressources de votre site doivent contenir le cache buster, il peut être plus facile d'utiliser le numéro de build ou le hachage de commit.
L'inconvénient de cette approche est de devoir mettre à jour toutes les URL des ressources à chaque changement. L'avantage est que vous pouvez mettre vos ressources en cache dans le navigateur avec des TTL (temps de vie) suffisamment longs, tout en permettant au navigateur de récupérer les ressources actualisées lorsque son cache est obsolète.
Combinez et assortissez
Étant donné que le CDN de Fastly vous permet de purger le contenu obsolète en moins de 150 ms, il est recommandé d'envisager la mise en cache de toutes vos pages HTML également. Cependant, même si vous pouvez réorganiser votre site afin d'utiliser des cache busters pour les ressources telles que les images, les feuilles de style et JavaScript, il est déconseillé d'utiliser des cache busters sur les URL des pages elles-mêmes. Les moteurs de recherche comme Google vous pénaliseront pour la présence de chaînes de requête dans les URL des pages.
Par conséquent, lorsque vous mettez des pages en cache, envisagez d'utiliser la technique TTL court et long pour vos pages, et des cache busters pour les ressources utilisées par ces pages.
Bits avancés : revalidation
Un avantage appréciable de l'utilisation du cache du navigateur est que les navigateurs conservent les objets même après leur expiration et envoient des en-têtes de revalidation supplémentaires avec leurs requêtes. Si l'objet demandé n'a pas changé, votre CDN peut simplement répondre avec un statut 304 Not Modified, qui n'a pas de corps, indiquant au navigateur qu'il peut utiliser l'objet expiré et, éventuellement, fournir un nouveau TTL.
Bien que chaque requête recevant une réponse 304 nécessite toujours un aller-retour pour être traitée, l'absence de corps de réponse permet de réaliser des économies de bande passante considérables. Cela constitue non seulement un avantage pour les utilisateurs disposant de connexions lentes, mais peut également réduire vos paiements mensuels liés au CDN.
Pour que la revalidation fonctionne, tout ce que vous avez à faire est de vous assurer que votre origine inclut un en-tête Last-Modifiedou ETag dans ses réponses. La bonne nouvelle, c’est que la plupart des serveurs web incluent déjà les en-têtes Last-Modified et ETag pour tout fichier statique qu’ils hébergent sur le disque. La valeur de l'en-tête Last-Modified est basée sur l'heure de modification du fichier. La valeur de l'en-tête ETag est basée (dans Apache) sur l'heure de modification, le numéro d'inode et la taille.
Lorsqu'un navigateur remarque l'un de ces deux en-têtes, ou les deux, sur des objets expirés dans son cache, il ajoutera un en-tête If-Modified-Since avec la valeur de Last-Modified et ajoutera un en-tête If-None-Match avec la valeur de ETag. Un objet est considéré comme inchangé si les valeurs de If-None-Match et ETag sont identiques, et si la valeur de If-Modified-Since correspond ou est postérieure à la valeur de Last-Modified.
Si vous disposez d'un seul serveur web pour vos ressources statiques, la revalidation fonctionne probablement déjà parfaitement grâce aux paramètres par défaut courants.
Toutefois, si vous utilisez plusieurs serveurs Web à des fins de redondance et que ces serveurs disposent chacun d'un stockage local plutôt que d'un stockage partagé, cela pourrait entraîner l'échec aléatoire de la revalidation. Étant donné qu'il n'est pas possible de garantir qu'un fichier spécifique se verra attribuer le même numéro d'inode sur chaque serveur Web, l'en-tête ETag généré pour ce fichier sera différent d'un serveur à l'autre. De plus, la plupart des scripts de déploiement ne conservent pas l'heure de modification lors de la copie des fichiers, ce qui signifie que l'en-tête Last-Modified sera également différent.
Cela est problématique pour deux raisons. Tout d'abord, lorsque Fastly communique avec votre origine, il est possible qu'une grande partie de la bande passante soit gaspillée inutilement pour des réponses complètes au lieu de réponses 304. Deuxièmement, Fastly pourrait finir par avoir différentes valeurs de ETag et Last-Modified sur différents serveurs. Étant donné que les navigateurs ne sont pas assurés de communiquer avec le même serveur pour chaque requête, ils pourraient également recevoir des réponses complètes inutiles en raison d'une incohérence dans les valeurs.
Pour optimiser l'utilisation de la revalidation si vous disposez de plusieurs serveurs web avec stockage local, je recommande de désactiver ETag et d'utiliser exclusivement Last-Modified, en veillant à ce que votre script de déploiement conserve la date de modification lors de la copie des fichiers.
Si vous utilisez un fournisseur de stockage cloud, comme Google Cloud Storage ou Amazon S3, l’en-tête ETag devrait déjà être automatiquement défini sur un hachage du contenu. Cela fait du stockage dans le cloud l'une des origines les plus optimales pour Fastly, car le rechargement du même fichier ne modifie pas son ETag.