Qu’est-ce qu’un cache de Content Delivery Network ?

Un cache de Content Delivery Network (Content Delivery Network) est un stockage temporaire du contenu d’un site web ou d’une application, situé sur des serveurs plus proches des utilisateurs finaux. Au lieu de récupérer le même contenu depuis un serveur d’origine chaque fois qu’une personne le requête, un CDN peut conserver une copie en cache à la périphérie du réseau et la diffuser directement.

Le résultat est une distribution de contenu plus rapide, moins de requêtes vers l’infrastructure d’origine, et une plus grande résilience lorsque le trafic connaît des pics ou que les systèmes d’origine rencontrent des problèmes.

Qu’est-ce qu’un cache ?

Un cache CDN stocke des copies du contenu à des emplacements de périphérie, également appelés points of presence (POPs), répartis sur le réseau d’un CDN.

Lorsqu’une personne visite un site web ou utilise une application, le Content Delivery Network peut vérifier si le contenu demandé est déjà disponible dans un cache à proximité. Si c’est le cas, le Content Delivery Network peut renvoyer la copie en cache au lieu d’effectuer une autre requête vers le serveur d’origine de l’application.

Les caches de Content Delivery Network sont généralement associés à des ressources statiques comme :

Images
Fichiers JavaScript et CSS
Polices
Vidéos et autres médias
Téléchargements de logiciels

Les CDN modernes peuvent également mettre en cache le HTML, les réponses d'API, et d’autres contenus fréquemment modifiés ou contenus dynamiques lorsque des politiques de mise en cache appropriées sont appliquées. Les objets mis en cache ont une « période de fraîcheur » définie et peuvent également être évincés par le Content Delivery Network lorsqu’il gère sa capacité de cache disponible.

Comment fonctionne le cache d’un Content Delivery Network ?

La mise en cache du Content Delivery Network suit généralement un processus de requête-réponse :

Un utilisateur demande du contenu. Un navigateur, une application mobile, un client API, ou une autre application envoie une requête pour une ressource (une page web, une image, une vidéo, etc.).
Le Content Delivery Network reçoit la requête. La requête est acheminée vers un emplacement de périphérie du Content Delivery Network approprié.
Le cache recherche l’objet demandé. Si une copie récente est déjà en cache, cela est communément appelé un taux de connexion au cache. Le Content Delivery Network peut renvoyer l’objet sans le récupérer depuis l’origine.
Le Content Delivery Network récupère le contenu manquant. Si un objet admissible n’est pas disponible dans le cache (ce qu’on appelle un échec de cache) le Content Delivery Network le demande à l’origine ou à un autre cache en amont.
La réponse peut être mise en cache. Selon les règles de mise en cache HTTP, et la configuration du Content Delivery Network, la réponse peut être stockée afin que les requêtes suivantes puissent être servies depuis le cache.

Les objets du cache ont généralement une durée de vie (TTL) qui détermine combien de temps ils peuvent être considérés comme valides sans consulter l’origine. Lorsque le contenu du cache expire, un Content Delivery Network peut le revalider auprès de l’origine plutôt que de télécharger à nouveau l’objet entier.

Quelle est la différence entre un cache CDN et un cache de navigateur ?

Tous deux stockent du contenu afin qu’il n’ait pas besoin d’être récupéré de manière répétée, mais ils fonctionnent à des endroits différents.

Un cache du navigateur stocke du contenu sur le dispositif d’un utilisateur individuel. Un cache de Content Delivery Network stocke le contenu dans une infrastructure partagée à la périphérie du réseau, où un objet en cache peut être utilisé pour répondre aux requêtes de nombreux utilisateurs.

Cette distinction est importante, car les opérateurs de sites web ont un contrôle direct nettement plus important sur l’invalidation du cache du Content Delivery Network. Un Content Delivery Network ne peut pas simplement purger un objet déjà stocké dans le cache du navigateur d’un utilisateur final.

Que se passe-t-il lorsque le contenu du cache change ?

Le contenu du cache ne doit pas nécessairement rester en périphérie jusqu’à l’expiration de son Temps de vie (TTL).

Un CDN peut purger ou invalider un objet lorsque la source change. La requête suivante peut alors récupérer la version mise à jour depuis l’origine et alimenter à nouveau le cache.

Cela fait de l’invalidation un élément important d’une stratégie de mise en cache efficace. Au lieu de définir des TTL extrêmement courts simplement parce que le contenu pourrait changer, les organisations peuvent mettre le contenu en cache plus longtemps et l’invalider lorsqu’une mise à jour réelle se produit.

Le contenu dynamique peut-il être mis en cache sur un Content Delivery Network ?

Oui. La cache du contenu dynamique dépend de la manière dont il est générer, de la fréquence à laquelle il change, et du fait que la réponse varie selon l’utilisateur ou la requête.

Le contenu tel que les informations produit, les articles d’actualité, les réponses d’API, ou d’autres données qui changent fréquemment se prête bien à la mise en cache en périphérie lorsqu’il est associé à des TTL, des clés de cache, une revalidation et une invalidation appropriés.

Fastly prend spécifiquement en charge la mise en cache d’une plus large gamme de contenus, y compris les contenus dynamiques, et basés sur les événements, la purge rapide offrant un moyen de mettre à jour les informations en cache lorsque cela est nécessaire.

Pourquoi la mise en cache du Content Delivery Network est-elle nécessaire/importante ?

Sans cache CDN, les requêtes peuvent devoir parcourir tout le chemin jusqu’à l’infrastructure d’origine d’une application, même lorsque des milliers ou des millions d’utilisateurs demandent un contenu identique.

La mise en cache aide à relever plusieurs défis.

Performances : La diffusion de contenu depuis un emplacement en périphérie proche peut réduire la distance réseau et le traitement par l’origine nécessaires pour répondre à une requête, améliorant ainsi les temps de réponse.

Scalabilité : Un cache peut servir le même objet de manière répétée sans générer une requête vers l’origine à chaque fois. Cela aide les applications à s’adapter à des audiences plus larges et à des pics de trafic soudains.

Réduction de la charge sur le serveur d’origine : Moins de requêtes atteignant l’infrastructure d’origine signifie moins de demande en calcul, en réseau, et en bande passante. Distribuer davantage de contenu à partir du cache peut par conséquent réduire les coûts d’infrastructure et les frais de sortie de données du serveur d’origine.

Fiabilité et résilience : Des politiques de mise en cache appropriées peuvent permettre à certains contenus de rester disponibles même lorsqu’une origine devient lente ou indisponible.

Expérience utilisateur : Des réponses plus rapides et plus cohérentes peuvent améliorer l’expérience des utilisateurs qui peuvent être géographiquement éloignés de l’infrastructure d’une application.

Quelles sont les bonnes pratiques de mise en cache CDN ?

Il n’existe pas de politique de mise en cache unique qui fonctionne pour chaque application. Une mise en cache efficace exige d’équilibrer les performances avec la fraîcheur du contenu et le contrôle. Voici quelques pratiques utiles :

Définissez des politiques de mise en cache explicites.
Choisissez les TTL en fonction de la fréquence de modification du contenu. Les ressources à longue durée de vie, comme les images versionnées ou les bundles JavaScript, peuvent souvent utiliser des TTL longs, tandis que les informations qui changent rapidement peuvent nécessiter des périodes de fraîcheur plus courtes ou une invalidation active.
Séparez la mise en cache du navigateur et du Content Delivery Network lorsque nécessaire. Les caches de périphérie peuvent souvent conserver le contenu plus longtemps, tandis que les navigateurs reçoivent des instructions de mise en cache plus courtes, ce qui donne aux opérateurs d’applications davantage de contrôle sur les mises à jour.
Utilisez l’invalidation ciblée. Lorsque le contenu change, invalidez des URL spécifiques ou des groupes d’objets associés plutôt que de vider inutilement l’ensemble du cache.
Utilisez le stale data de manière stratégique.
Fournissez des validateurs. L’utilisation des en-têtes permet aux caches de déterminer si le stale data a réellement changé sans toujours télécharger à nouveau l’objet "full".
Surveillez l’efficacité du cache. Les taux de connexion au cache, le trafic d’origine, la latence, les TTL et les modèles d’invalidation peuvent aider les équipes à identifier le contenu qui pourrait être mis en cache plus efficacement.
Soyez prudent avec le contenu personnalisé ou sensible. L’authentification, les cookies, les en-têtes d’autorisation et les réponses spécifiques à l’utilisateur doivent être intégrés aux règles de mise en cache afin qu’une réponse privée d’un utilisateur ne soit pas servie involontairement à un autre.

L’objectif n’est pas simplement de mettre en cache autant que possible. Il s’agit de mettre en cache le bon contenu pendant la bonne durée, tout en maintenant le contrôle de la fraîcheur.

Qui a besoin de la mise en cache CDN ?

La mise en cache CDN peut bénéficier à presque toutes les organisations qui fournissent du contenu ou des applications numériques aux utilisateurs, mais elle devient particulièrement précieuse à l’échelle.

Les entreprises de e-commerce peuvent mettre en cache les ressources produit, les pages de catégorie, et potentiellement certaines parties d’expériences qui évoluent rapidement, tout en conservant le contrôle des mises à jour de l’inventaire et de la tarification.

Les entreprises des médias et de l’édition peuvent utiliser la mise en cache pour gérer de larges audiences et les pics de trafic autour des actualités de dernière minute ou des contenus populaires.

Les services de streaming et de divertissement peuvent distribuer les médias et les ressources associées au plus près des publics.

Les fournisseurs SaaS et API peuvent réduire la latence et la demande sur le back-end en mettant en cache les réponses d’application et d’API éligibles.

Les entreprises de logiciels et de jeux vidéo peuvent distribuer efficacement des fichiers volumineux, des téléchargements, des correctifs, et d’autres ressources fréquemment demandées.

Les grandes entreprises mondiales peuvent offrir des performances d’application plus cohérentes aux utilisateur répartis dans différentes région.

Même les organisations proposant principalement des applications dynamiques peuvent en tirer avantage. La mise en cache CDN moderne ne se limite pas aux fichiers statiques : avec la bonne architecture et la bonne stratégie d’invalidation, le contenu à évolution rapide et basé sur les événements peut également être mis en cache en périphérie.

Que propose Fastly pour la mise en cache CDN?/ Comment Fastly peut aider

Le Content Delivery Network de Fastly est conçu pour donner aux organisations le contrôle sur ce qui est mis en cache, pendant combien de temps cela est mis en cache, et quand cela est mis à jour.

Le Content Delivery Network de Fastly prend en charge la mise en cache de contenu statique ainsi que de contenu dynamique et basé sur les événements en périphérie. Son architecture réseau utilise des POP à haute capacité conçus pour conserver davantage de contenu en cache au plus près des utilisateurs.

Les principales fonctionnalités de mise en cache incluent :

Instant Purge™ : Fastly permet d’invalider rapidement le contenu du cache lorsqu’il change, permettant aux entreprises de mettre le contenu en cache plus longtemps sans s’appuyer exclusivement sur des TTL courts pour maintenir les informations à jour. Fastly signale un temps moyen régional de purger inférieur à 150 millisecondes au 31 décembre 2025.

Purge granulaire : Le contenu peut être invalidé par URL ou regroupé à l’aide de clé de substitution. La purge douce peut marquer un objet comme stale plutôt que de le supprimer immédiatement, aidant les application à continuer à diffuser du contenu pendant l’actualisation du cache.

Origin Shield : Fastly peut utiliser un POP désigné comme bouclier entre les cache en périphérie et une origine. Cela peut améliorer l’efficacité du cache et réduire le nombre de requêtes atteignant l’infrastructure d’origine.

Contrôle précis du cache : les développeurs peuvent utiliser les contrôles de mise en cache HTTP standard ainsi que les fonctionnalités de Fastly pour gérer la mise en cache du Content Delivery Network indépendamment de celle du navigateur.

Stale data et revalidation : Fastly prend en charge « stale-while-revalidate » et « stale-if-error », permettant aux applications de trouver un équilibre entre fraîcheur, performances et résilience.

Programmabilité et observabilité : le Content Delivery Network de Fastly fournit des API, une logique de distribution configurable, ainsi que la journalisation et l’observabilité en temps réel, offrant aux équipes de développement et d’Opérations une plus grande visibilité et un meilleur contrôle sur la distribution de contenu.

En combinant le cache en périphérie avec une invalidation rapide et un contrôle programmable, Fastly permet aux organisations de mettre en cache davantage de contenu (y compris du contenu qui change fréquemment) tout en gardant le contrôle sur le moment où les utilisateurs reçoivent des versions mises à jour.