J’ai ajouté un CDN et ça est devenu plus lent. Voici les calculs que j’aurais dû faire avant.

J’ai ajouté un CDN et ça est devenu plus lent. Voici les calculs que j’aurais dû faire avant.

La semaine dernière, j’ai fait ce que l’on pourrait appeler une optimisation évidente : j’ai ajouté une couche de cache CDN devant mon site statique, en me disant que j’allais retrouver le scénario classique — des temps de chargement plusrapides, des utilisateurs plus contents, et de meilleurs scores SEO. Et bien non. Mon site est devenu mesurablement plus lent. Pas légèrement — un crawler indépendant qui signalait auparavant des temps de chargement de 38 secondes a commencé à en mesurer 52. Aïe.

Ce n’est pas la première fois qu’une optimisation d’infrastructure tourne au désastre, mais c’était un rappel humiliant du fait que les couches de cache ont elles-mêmes leurs frais de performance. Avant de mettre n’importe quel CDN sur votre stack, voici les calculs que j’aurais aimé exécuter en premier.

Pourquoi le caching peut tourner au désastre

À première vue, les CDN ont l’air d’être un évidence : win-win. On déplace les fichiers statiques plus près des utilisateurs, on réduit la charge serveur, et on améliore la latence mondiale. Mais chaque cache ajoute une couche d’overhead :

1. **Latence liée aux décisions de cache** : Est-ce que cette requête est en cache ? Faut-il revalider ? Quelles headers s’appliquent ?
2. **Sauts réseau supplémentaires** : Même les nœuds edge ne sont pas toujours infiniment proches des utilisateurs
3. **Cache misses** : Quand les caches expirent ou sont purgés, les utilisateurs paient plein pot la latence d’origine plus le délai de traitement du CDN
4. **Compression et transformation** : Beaucoup de CDNs comprennent ou modifient le contenu, ce qui ajoute du temps de traitement

Dans mon cas, le coupable n’était pas le CDN lui-même — c’était la *configuration du cache*. Par défaut, beaucoup de setups CDN cachent les fichiers petits de manière agressive, mais laissent les gros fichiers sans cache, créant une expérience utilisateur incohérente.

Les chiffres importants

Avant de mettre en place n’importe quelle solution de cache, faites ces calculs :

Ratio de cache hit
```
Hit Ratio = Hits / (Hits + Misses)
```

Si vous n’êtes en cache que 60 % du temps, vous payez 40 % des requêtes avec l’overhead du CDN pour zéro bénéfice. Visez plutôt >85 %.

Latence effective
```
Latence Effective = (Taux de Hit × Latence Edge) + (Taux de Miss × (Latence Edge + Latence Origine))
```

Exemple :
Latence edge : 50 ms
Latence origine : 300 ms
Taux de hit : 90 %
Latence effective : (0.9 × 50) + (0.1 × 350) = 80 ms

Comparé à l’origine directe : 300 ms. Le CDN gagne clairement.

Mais si le taux de hit tombe à 60 % :
Latence effective : (0.6 × 50) + (0.4 × 350) = 170 ms
Toujours plus rapide, mais à peine. Est-ce que ça vaut vraiment le coup de la complexité supplémentaire ?

Optimisation du TTL (Time-to-Live)

Les TTL courts (< 30 secondes) obligent à faire beaucoup de requêtes vers l’origine. Les TTL longs (> 24h) risquent de servir du contenu périme. Trouvez un équilibre selon la fréquence de mise à jour de votre contenu.

Scénarios concrets où j’écouterais bien sauter le CDN

1. Public principalement local
Si 90 % de votre trafic vient d’une seule région géographique, un CDN peut ajouter de la complexité inutile. Un serveur d’origine bien configuré peut performer mieux.

Exemple : le site web d’un restaurant local, qui ne sert que des clients proches, ne bénéficie pas énormément du cache global du CDN.

2. Contenu très dynamique
Pour les sites où le contenu change toutes les quelques minutes (comme les tableaux de bord d’actualités), les TTL courts obligent à une constante révalidation. Le cache devient une responsabilité plutôt qu’un atout.

Exemple : mon propre tableau de bord analytique récupère des données en temps réel toutes les 30 secondes. Mettre un cache là-dessus, ça donnerait soit des données obsolètes, soit une logique d’invalidation très compliquée.

3. Fichiers très petits
Les CDN optimisent la proximité réseau, mais si vos fichiers sont minuscules (moins de 10 Ko), l’overhead du routage via un CDN peut dépasser l’économie de temps sur le transfert.

Exemple : des réponses JSON d’API de moins de 5 Ko chargent souvent plus vite directement depuis l’origine que via le traitement en edge du CDN.

Outils pour diagnostiquer les performances

Avant d’assumer que le CDN améliore les choses, mesurez les performances de base avec :

- **WebPageTest.org** : graphiques en cascade détaillés montrant où le temps est passé
- **Lighthouse CI** : audits de performance automatisés dans votre pipeline de déploiement
- **Suivi en temps réel chez les utilisateurs (RUM)** : des outils comme [PostHog](https://posthog.com/) ou [Plausible](https://plausible.io/) qui montrent l’expérience réelle des utilisateurs

Faites les tests depuis plusieurs endroits géographiques pour comprendre l’expérience réelle de votre audience.

Comment j’ai corrigé mon erreur

Après avoir diagnostiqué le problème, j’ai changé d’approche :

1. J’ai augmenté le TTL du cache de 30 secondes à 6 heures pour les fichiers statiques
2. J’ai mis en place des tags de cache pour une invalidation dynamique
3. J’ai ajouté de la logique de préchauffage pour les endpoints populaires
4. J’ai surveillé en continu les ratios de hit via [Cloudflare Analytics](https://www.cloudflare.com/analytics/)

Résultat ? Les temps de chargement sont passés de 52 secondes à 1,2 seconde dans le monde entier.

Le mot de la fin

Les CDNs ne sont pas des balles magiques. Ils sont des outils sophistiqués qui demandent à être régulièrement réglés. Toujours établir des métriques de base avant d’optimiser, et ne jamais supposer que les paramètres par défaut fonctionneront pour votre cas spécifique.

Testez bien, mesurez l’impact, et souvenez-vous : parfois, enlever de la complexité vaut mieux que de l’ajouter.

FAQ

Est-ce que je devrais toujours utiliser un CDN ?
Pas forcément. Évaluez selon la géographie de votre audience, le type de contenu, et la fréquence de mise à jour. Les audiences locales avec des fichiers petits peuvent ne voir aucun bénéfice.

Quel est un ratio de cache hit acceptable ?
Visez 85 % ou plus. En dessous de 70 %, réfléchissez à savoir si l’overhead du CDN est réellement justifié.

Combien de temps faut-il mettre en cache les fichiers statiques ?
Pour les fichiers versionnés (avec hachage dans le nom), mettez-les en cache indéfiniment. Pour les autres, 1 à 24 heures selon la fréquence de mise à jour.

Est-ce que les CDN peuvent nuire au SEO ?
Oui, s’ils augmentent les temps de chargement ou servent un contenu incohérent. Google prend la vitesse de page en compte dans ses algorithmes, alors surveillez bien les Core Web Vitals.