CDN détecté - Docs MetricSpot

Ce que vérifie ce contrôle

Examine les en-têtes de réponse HTTP sur l’URL auditée et identifie le CDN (Content Delivery Network) qui la sert. C’est un contrôle informatif — il n’y a pas de pass/fail. Le résultat vous dit s’il y a une couche edge entre les utilisateurs et votre serveur d’origine, et chez quel fournisseur vous êtes routé.

Pourquoi c’est important

Un CDN met en cache vos ressources dans des dizaines ou des centaines de points de présence à travers le monde. Les utilisateurs à São Paulo touchent un nœud edge à São Paulo, pas votre origine à Francfort. Cette seule couche change le plancher de chaque métrique de performance que l’audit mesure :

Temps de réponse serveur — premier octet depuis un PoP proche, pas un aller-retour transatlantique.
Largest Contentful Paint — les images héros et le CSS arrivent sur le même budget RTT.
Score de performance Lighthouse — chaque métrique Lab s’améliore avec le cache edge.

Un CDN absorbe aussi le trafic DDoS, termine TLS à l’edge et vous permet d’exécuter de la logique (auth, redirections, splits A/B) près de l’utilisateur via des edge workers. Si MetricSpot remonte « Aucun CDN détecté » et que votre audience est globale, c’est le changement d’infrastructure à plus fort levier que vous pouvez faire.

Comment corriger

Ce contrôle est informatif, donc l’action dépend de ce qui a été détecté.

Aucun CDN détecté. Mettez-en un devant votre origine. Des défauts qui marchent pour la plupart des sites :

Cloudflare — le palier gratuit couvre la plupart des sites marketing et landing pages SaaS. Meilleure protection DDoS. Détecté via Server: cloudflare et l’en-tête CF-Ray.
Bunny — le moins cher en sortie pour les sites lourds en images et vidéos. Pay-as-you-go, sans minimum. Détecté via Server: BunnyCDN et CDN-PullZone.
Fastly — logique edge à granularité fine via VCL. Fort pour les éditeurs et l’ecommerce qui ont besoin d’invalidation de cache à la milliseconde. Détecté via X-Served-By et X-Cache.
AWS CloudFront — adéquation naturelle si votre origine est sur AWS. Détecté via X-Amz-Cf-Id et Via: ... cloudfront.net.
Vercel / Netlify Edge — automatique si vous déployez sur l’une de ces plateformes. Détecté via X-Vercel-Id / X-Vercel-Cache et Server: Netlify.

CDN détecté, mais la performance reste mauvaise. Le CDN forwarde vers votre origine sans cacher. Causes courantes :

Cache-Control: no-store ou private sur les réponses HTML depuis votre origine.
Set-Cookie sur chaque réponse (certains CDN refusent de cacher les réponses avec cookie).
En-têtes Cache-Control totalement manquants — Cloudflare ne cache pas le HTML par défaut ; vous avez besoin d’une Page Rule ou d’un en-tête Cache-Control: public, max-age=....

Vérifiez l’en-tête de cache pour le ratio de hit :

curl -I https://votredomaine.com/ | grep -iE 'cache|cf-cache|x-cache|x-vercel'

HIT signifie caché à l’edge. MISS ou DYNAMIC signifie que chaque requête touche votre origine — vous payez pour un CDN que vous n’utilisez pas.

Choisir entre fournisseurs. Si vous êtes déjà sur Vercel ou Netlify, utilisez leur edge — changer coûte plus que ça n’économise. Si vous avez besoin de protection DDoS ou faites tourner un site WordPress / hébergement partagé, Cloudflare. Si les coûts de sortie dominent (vidéo, grandes images, téléchargements logiciels), Bunny. Si vos ingénieurs veulent écrire du code edge comme préoccupation de premier ordre, Fastly ou Cloudflare Workers.

Questions fréquentes

Un CDN vaut-il le coup pour un site B2B mono-région ?

Si 95 % de votre trafic est dans un pays et que vous y êtes hébergé, le bénéfice de cache du CDN est petit — la plupart des utilisateurs sont déjà proches de votre origine. Vous obtenez quand même la terminaison TLS, la protection DDoS et le filtrage de bots, ce qui vaut le palier gratuit sur Cloudflare. Passez les plans payants jusqu’à ce que la forme du trafic change.

MetricSpot détecte-t-il les CDN devant les CDN ?

Seulement la couche extérieure — c’est ce que le navigateur du visiteur voit. Si vous avez Cloudflare → Fastly → origine, nous remonterons Cloudflare. Le setup en chaîne est inhabituel hors des gros éditeurs et signifie généralement qu’une migration est en cours ; l’un des deux doit partir.

Un CDN cassera-t-il mes analytics ou tests A/B ?

Non, mais il peut masquer l’IP client dans vos logs d’origine. Les CDN forwardent l’IP originale dans X-Forwarded-For ou CF-Connecting-IP ; le code de votre application ou votre outil analytics doit lire cet en-tête au lieu de l’IP source TCP. La plupart des frameworks serveur ont un réglage trusted-proxy pour cela — configurez-le une fois et les fonctionnalités IP (géolocalisation, limites de débit) marchent comme attendu.