Qu’est-ce qu’un CDN et votre site en a-t-il besoin ?

Un CDN (content delivery network, ou réseau de diffusion de contenu) est un ensemble de serveurs répartis dans de nombreux lieux, qui conservent des copies des fichiers de votre site et les servent à chaque visiteur depuis un serveur proche de lui, au lieu d’envoyer chaque requête à votre hébergement. La plupart des sites publics dont les visiteurs viennent de plusieurs régions, ou qui connaissent des pics de trafic, y gagnent. Un CDN ne corrige pas pour autant à lui seul un code lent ou des pages trop lourdes : mieux vaut donc savoir ce qu’il fait réellement avant d’en ajouter un.

Comment fonctionne un CDN

Sans CDN, chaque visiteur s’adresse directement à votre serveur d’origine, la machine chez votre hébergeur où votre site est installé. Si ce serveur se trouve à Francfort et le visiteur à Sydney, chaque requête fait le tour du monde, aller et retour. Si mille personnes arrivent en même temps, l’origine doit répondre à toutes.

Avec un CDN, les visiteurs sont dirigés vers un serveur edge. Celui-ci se place entre le visiteur et votre origine et fonctionne à peu près ainsi :

1. Un visiteur demande une page ou un fichier.
2. Le DNS l’envoie vers un serveur edge proche.
3. Si l’edge possède déjà une copie à jour, il répond immédiatement. C’est un cache hit.
4. Sinon, l’edge récupère le fichier auprès de votre origine, le livre et en garde une copie pour le visiteur suivant. C’est un cache miss.

La première requête pour un fichier n’est pas plus rapide qu’avant. Toutes les requêtes suivantes pour ce même fichier, de n’importe quel visiteur proche de cet edge, peuvent en revanche être servies sans solliciter votre origine. C’est de là que viennent à la fois le gain de vitesse et le soulagement de votre serveur.

Ce qu’un CDN met en cache (et ce qu’il ne doit pas mettre en cache)

Un CDN décide de ce qu’il stocke en fonction des en-têtes de réponse de votre origine, principalement Cache-Control, ainsi que des règles que vous configurez. La référence MDN sur Cache-Control est le meilleur endroit pour vérifier des directives comme max-age, s-maxage, private et no-store.

Sans risque à mettre en cache

• Images, CSS, JavaScript et polices web
• Pages HTML publiques identiques pour tous les visiteurs : articles de blog, landing pages, pages catégorie et fiches produit dans la plupart des boutiques
• Téléchargements comme les PDF

Doit contourner le cache

• Paniers, pages de commande et de paiement
• Espaces client et tout ce qui s’affiche pour des utilisateurs connectés
• Pages contenant des données personnelles, des jetons de formulaire ou des prix propres à chaque utilisateur
• Zones d’administration comme /wp-admin

Bien faire ce tri compte davantage que n’importe quel autre réglage du CDN. Un CDN qui met en cache une page connectée peut afficher les données d’un client à un autre. Les CMS et systèmes e-commerce bien conçus marquent ces réponses comme privées ou posent des cookies que le CDN interprète comme un signal de contournement. Si vous gérez une boutique, le guide pour accélérer WooCommerce détaille quelles pages relèvent de quel groupe.

Ce qu’un CDN améliore

Le temps jusqu’au premier octet

Quand une page est servie depuis le cache edge, le visiteur reçoit le premier octet sans attendre PHP, une requête en base de données ou un hébergement lent. Cela se voit dans le TTFB (en anglais), pour lequel web.dev recommande, à titre indicatif, 0,8 seconde ou moins. Notre guide pour réduire le TTFB couvre les corrections côté serveur qui complètent un CDN.

La distance et la latence

Chaque aller-retour entre le navigateur et le serveur prend du temps, et la distance physique l’allonge. Servir depuis un edge proche raccourcit chacun de ces allers-retours, ce qui s’additionne sur la résolution DNS, la négociation TLS et les nombreuses requêtes d’une page.

La charge sur votre origine

Les cache hits n’atteignent jamais votre serveur. Lors de l’envoi d’une newsletter, de soldes ou d’une mention sur les réseaux sociaux, votre hébergement ne doit répondre qu’aux cache miss et aux requêtes dynamiques. Il risque donc beaucoup moins de ralentir aux heures de pointe.

Sécurité et disponibilité

Comme tout le trafic passe par l’edge, de nombreux CDN y filtrent aussi les attaques, prennent en charge le TLS et continuent de servir les pages en cache quand l’origine est brièvement injoignable. Ce que vous obtenez exactement dépend du fournisseur et de l’offre.

Ce qu’un CDN ne peut pas corriger

Un CDN est une couche de diffusion. Il fait arriver plus vite les bonnes pages, mais il ne peut pas alléger une page lourde.

• Les pages dynamiques lentes. La commande, la recherche et les pages connectées sont générées à chaque fois. Si elles sont lentes, la cause se trouve dans votre application, votre base de données ou votre hébergement.
• Les front-ends lourds. Une image hero de 4 Mo ou une pile de scripts tiers pèse toujours 4 Mo et doit toujours s’exécuter dans le navigateur. Cela se voit dans le LCP et l’INP, pas dans le TTFB.
• Les décalages de mise en page. Le CLS vient de la construction de la page, par exemple des images sans dimensions ou des bannières chargées tardivement.
• Un cache mal configuré. Si votre origine envoie no-store partout, ou si chaque page pose un cookie de session, le CDN contournera le cache et vous gagnerez peu.

Si votre problème fait partie de ceux-là, la correction doit se faire dans la page ou dans l’application. Un CDN reste utile en complément, mais il ne la remplace pas. Le guide sur les Core Web Vitals explique quelle métrique pointe vers quelle cause.

Votre site a-t-il besoin d’un CDN ?

Un CDN vaut généralement la peine si au moins un de ces points s’applique :

• Vos visiteurs viennent de plusieurs pays ou continents.
• Votre TTFB est élevé sur les pages publiques, surtout loin de votre hébergeur.
• Votre serveur peine ou ralentit lors des pics de trafic.
• Vous utilisez un CMS ou une boutique où la plupart des visites arrivent sur des pages identiques pour tous.
• Vous voulez que la protection DDoS et le HTTPS soient gérés en amont de votre hébergement.

Il compte moins si votre site est purement local, très petit, déjà servi par un hébergeur statique rapide proche de votre audience, ou presque entièrement personnalisé (un outil interne derrière une connexion, par exemple). Dans ces cas, un meilleur hébergement ou une optimisation de l’application peut apporter davantage qu’un CDN.

Comment vérifier que cela fonctionne

Avant d’activer quoi que ce soit, mesurez. Passez quelques pages publiques dans corewebvitals.page et notez le LCP et les autres métriques, ainsi que vos données d’utilisateurs réels si Google en dispose en quantité suffisante. Le guide pour mesurer la vitesse d’un site explique comment mettre en place une comparaison avant/après équitable.

Une fois le CDN en service, vérifiez les en-têtes de réponse d’une page qui devrait être en cache. Demandez-la deux fois :

curl -sI https://www.example.com/ | grep -i -E 'cache|age'

La première requête est souvent un miss. La deuxième devrait afficher un hit dans l’en-tête de cache du fournisseur, ainsi qu’un âge qui augmente. Si chaque requête reste en miss ou en bypass, examinez Cache-Control et Set-Cookie dans la réponse de l’origine. Refaites ensuite vos mesures depuis plusieurs lieux et comparez.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant : vous gardez votre hébergeur et votre CMS. Vous ajoutez votre domaine dans le tableau de bord, faites pointer vos serveurs de noms vers fast.site et validez. La propagation est vérifiée automatiquement, puis fast.site prend en charge le DNS du domaine.

La mise en cache est assurée par Fast Edge Cache™. En cas de miss, l’edge récupère la page auprès de votre origine et en stocke une copie ; en cas de hit, il répond sans contacter votre serveur. L’expiration suit les en-têtes Cache-Control de votre origine ou vos propres règles, et les paniers, la commande et les sessions connectées contournent le cache. L’en-tête de réponse fs-cache indique HIT, MISS ou BYPASS, ce qui vous permet de vérifier chaque page vous-même. Vous pouvez purger par URL dans le tableau de bord ou via l’API, et un cache warmer garde les pages importantes à jour dans le cache.

Les visiteurs sont dirigés par GeoDNS vers l’edge disponible le plus proche en Amérique du Nord, en Europe, en Asie-Pacifique ou en Amérique du Sud, selon votre offre. Chaque domaine bénéficie aussi de la détection automatique des attaques DDoS de couche 7 et de certificats SSL gratuits renouvelés automatiquement. Les détails se trouvent dans la documentation sur le cache et sur la page des fonctionnalités.

Mesurez votre propre site avant et après. Vous pouvez commencer par un essai gratuit de 7 jours, sans carte bancaire. Comparez les offres sur la page des tarifs.

Questions fréquentes

Un CDN remplace-t-il mon hébergement web ?

Non. Votre site reste sur votre hébergement, qui demeure l’origine. Le CDN se place devant et sert des copies en cache, mais tout ce qui est dynamique, comme la commande, est toujours généré par votre serveur.

Un CDN est-il bon pour le SEO ?

Indirectement, il peut l’être. Google utilise des signaux d’expérience de page comme les Core Web Vitals, et un CDN peut améliorer les temps de chargement, notamment le TTFB et, par ricochet, souvent le LCP. Il ne garantit pas un meilleur classement, car le contenu et la pertinence comptent bien davantage.

Un CDN peut-il ralentir mon site ?

Oui, s’il est mal configuré. Si le CDN contourne presque toutes les requêtes, chacune fait un détour supplémentaire par l’edge jusqu’à votre origine. Vérifiez les en-têtes de cache après la mise en place et assurez-vous que les pages publiques produisent bien des hits.

Ai-je besoin d’un CDN si tous mes visiteurs sont dans le même pays ?

Pas forcément pour la distance, mais souvent quand même pour la charge et la protection. Si votre hébergeur est proche de votre audience et encaisse bien les pics, le gain est plus faible. Si les pics de trafic ralentissent votre serveur, le cache edge aide toujours.

Un CDN risque-t-il de casser ma boutique ou mes pages de connexion ?

Non, si les pages dynamiques contournent le cache. Les paniers, la commande et les comptes client ne doivent jamais être mis en cache pour tout le monde. Testez ces parcours après la mise en place, connecté et déconnecté, et vérifiez que l’en-tête de cache y indique un bypass.