Comment optimiser la vitesse de votre site avec un CDN

Comment optimiser la vitesse de votre site avec un CDN : ce que 300 ms changent vraiment

Mon premier vrai test de CDN, je l'ai fait sur un site e-commerce qui vendait des vélos de ville. Page d'accueil à 2,8 s de LCP depuis Paris, et 4,9 s depuis Marseille. Le même site. Le même code. Le même serveur à Francfort.

J'ai activé un CDN en quinze minutes. Marseille est descendue à 1,9 s. Paris n'a quasiment pas bougé. Et là, j'ai compris un truc que personne ne m'avait expliqué avant : un CDN ne rend pas votre site rapide. Il rend la distance moins coûteuse. Ce n'est pas la même chose, et cette nuance change tout dans la façon dont vous devez le configurer.

Comment un CDN accélère concrètement votre site

Un CDN, c'est un réseau de serveurs répartis sur plusieurs continents qui gardent une copie de vos fichiers. Quand un visiteur demande une image, il ne tape pas sur votre serveur d'origine en Allemagne ou en Virginie. Il tape sur le serveur le plus proche de chez lui.

Le trajet compte plus que la puissance. Une requête qui traverse l'Atlantique, c'est 80 à 120 ms de latence aller-retour dans de bonnes conditions. Sur une page qui charge 60 ressources, ça s'additionne vite. Mais attention au raccourci : le CDN ne supprime pas les allers-retours, il les rapproche.

Ce qui se met en cache, et ce qui ne se met pas

Voici la distinction qui m'a coûté le plus de temps à intégrer :

• Images, CSS, JavaScript, polices — mise en cache longue, plusieurs mois, avec un nom de fichier qui change à chaque déploiement (le fameux fingerprinting).
• Fichiers statiques avec URL stable — attention, c'est là que les ennuis commencent.
• Pages HTML — mises en cache très court, quelques minutes au maximum, parce qu'elles contiennent souvent des données personnalisées.
• API et réponses utilisateur — jamais en cache public, sauf si vous voulez servir le panier de quelqu'un d'autre à votre client. Ce qui est déjà arrivé à un type dont je tairai le nom. C'était moi.

Oui, j'ai servi le panier d'un client à un autre. Deux heures de panique, un correctif déployé en urgence, et un Cache-Control: private ajouté partout sur les routes sensibles. Leçon retenue.

Le TTFB n'est pas toute l'histoire

On parle souvent du TTFB (Time To First Byte) comme indicateur roi. C'est utile, mais trompeur. Un CDN améliore le TTFB pour les ressources statiques, pas forcément pour le document HTML principal si celui-ci est généré dynamiquement côté serveur.

Sur le site de vélos, le TTFB est passé de 340 ms à 90 ms depuis Marseille pour les images, mais le document HTML restait à 280 ms. Parce qu'il est généré par PHP à chaque requête. Le CDN ne peut rien y faire. C'est là qu'il faut du full page cache ou une génération statique.

Quel CDN choisir, et sur quels critères

Le marché a bougé. Les gros acteurs ont absorbé les petits, et les offres gratuites sont devenues réellement utilisables pour un site à trafic modéré. Voici une comparaison basée sur ce que j'ai testé personnellement sur trois de mes projets.

Fournisseur	Offre gratuite	Point fort observé	Limite
Cloudflare	Oui, généreuse	Mise en place en 10 minutes, purge instantanée	Interface dense, on se perd vite
Bunny	Non, mais très bon marché	Prix à la consommation, latence excellente en Europe	Moins de POPs en Afrique et Amérique du Sud
Fastly	Non	Contrôle total sur les règles VCL	Complexité technique élevée, facturation à la requête surprenante
CloudFront	Palier gratuit un an	Intégration naturelle à l'écosystème AWS	Configuration via console austère, coût final difficile à anticiper

Les critères qui comptent vraiment

Ne choisissez pas sur le nombre de points de présence. C'est un chiffre marketing. Ce qui compte :

1. La localisation de vos visiteurs réels, pas mondiale.
2. La vitesse de purge du cache. Si vous attendez 30 minutes pour invalider un fichier, vous allez souffrir.
3. Le support des en-têtes HTTP standards sans bricolage.
4. La transparence de la facturation. Un pic de trafic lié à un article viral peut faire exploser une facture à la requête.
5. L'analytique intégrée, ou au moins la compatibilité avec vos outils.

Pour un site français avec une audience essentiellement hexagonale, honnêtement, la plupart des offres se valent. Le gain se joue à 20-30 ms près. Investissez votre temps ailleurs.

Configuration pas à pas : DNS, cache, purge

Voici la procédure que j'applique systématiquement, dans cet ordre, et qui m'a évité plusieurs catastrophes.

Étape 1 — Créer un sous-domaine dédié

Vous pointez par exemple cdn.votresite.fr vers votre fournisseur via un enregistrement CNAME. Ne faites pas l'erreur de faire passer tout votre domaine principal par le CDN le jour de la mise en route. Gardez la bascule progressive.

Étape 2 — Définir les règles de cache

Les règles de base que j'utilise sur à peu près tous mes projets :

• Images, polices, CSS, JS versionnés : max-age=31536000, immutable
• HTML : max-age=60, s-maxage=300, must-revalidate
• API et pages utilisateur : no-store ou private

Le mot-clé immutable, je l'ai découvert tard. Il indique au navigateur qu'il ne doit même pas vérifier si le fichier a changé. Gain mesuré sur mes propres tests : environ 15 à 25 ms par ressource sur les visites répétées. Sur une page avec 40 ressources, ça finit par compter.

Étape 3 — Mesurer avant et après, sérieusement

Prenez vos mesures depuis les mêmes villes avant et après. Pas depuis votre canapé avec une connexion fibre à 2 Gb/s. J'utilise Lighthouse en local, et un service de test géographique distribué pour la partie réaliste.

Sur le site de vélos, les chiffres après deux semaines :

• LCP depuis Marseille : 4,9 s → 1,9 s
• LCP depuis Lyon : 3,6 s → 1,6 s
• LCP depuis Paris : 2,8 s → 2,5 s
• Taux de rebond mobile : 61 % → 54 %
• Conversions : +12 % sur les sessions mobiles hors Île-de-France

Le gain à Paris était marginal. La raison est simple : mon serveur d'origine était à 400 km. Le CDN ne peut pas faire mieux que supprimer une distance qui n'existait presque pas.

Les pièges à éviter absolument

Personne ne vous les raconte, ces pièges. Ou plutôt, on les survole dans un paragraphe prudent.

L'invalidation du cache : l'ennemie numéro un

Vous déployez une refonte CSS. Le CDN sert encore l'ancienne version. Vos utilisateurs voient un site cassé pendant deux heures. Ce scénario m'est arrivé une fois, et une seule. Depuis, chaque fichier CSS a un hash dans son nom.

La règle : ne comptez jamais sur la purge pour rattraper un déploiement. Comptez sur le nom de fichier. La purge, c'est pour les urgences vraies.

Le contenu dynamique mal mis en cache

Un CDN qui met en cache vos pages HTML sans distinguer les utilisateurs connectés, c'est du sabotage. Vous servez la page de profil de Jean à la place de celle de Marie. Vérifiez vos en-têtes Vary et vos directives de cache privé avant toute mise en production.

Le coût et la dépendance

Un CDN est une dépendance externe. S'il tombe, votre site tombe. S'il facture à la requête et que votre site devient viral, votre facture grimpe. Prévoyez toujours un fallback sur votre domaine principal, ou au moins une alerte budgétaire.

L'impact SEO si c'est mal configuré

Mal configuré, un CDN peut créer du contenu dupliqué si vos ressources sont accessibles à la fois via votre domaine et via celui du CDN. La solution : vos balises canonical pointent toujours vers votre domaine principal, jamais vers le sous-domaine CDN. Et n'indexez pas ce sous-domaine.

Faut-il vraiment un CDN pour votre site ?

Ça dépend de trois choses, et je vais être direct : si votre audience est 100 % locale et que votre hébergeur est dans la même région, l'apport est faible. Le gain sera de l'ordre de 10 à 30 ms. Vous investirez des heures pour quelque chose que vos visiteurs ne sentiront pas.

Si votre audience est dispersée géographiquement, ou si votre hébergement est à l'étranger, alors oui. Le gain devient visible, mesurable, et parfois décisif sur le taux de conversion mobile.

Un cas intermédiaire que je vois souvent : le site hébergé chez un fournisseur américain, avec une audience française. Là, le CDN n'est pas une option, c'est une nécessité. La distance initiale est tellement pénalisante que tout gain devient visible.

Ce qu'il faut retenir de tout ça

Un CDN n'accélère pas votre site. Il rapproche vos fichiers de vos visiteurs. La différence paraît sémantique, elle est pratique : vous ne pouvez pas attendre d'un CDN qu'il répare un site mal optimisé. Un serveur mal configuré, des images de 4 Mo, du JavaScript bloquant — le CDN sert tout ça très rapidement. Ce qui ne règle rien.

Avant d'activer un CDN, assurez-vous que votre site mérite d'être accéléré. Une fois cette étape franchie, le CDN devient une couche parmi d'autres dans votre stratégie de performance. Utile, parfois décisive, souvent surestimée.

Et si demain votre hébergeur ouvre une région de serveurs à 20 km de vos visiteurs principaux ? Le CDN perd la moitié de son intérêt. La vraie question n'est pas « faut-il un CDN », c'est « où sont mes visiteurs, et où sont mes fichiers ». Tant que vous ne savez pas y répondre, aucun outil ne vous sauvera.