# « Installer un CDN suffit à accélérer un site » : ce que ça laisse de côté

> Un CDN accélère réellement la livraison des fichiers statiques, mais il ne réduit en rien le temps que WordPress met à générer une page dynamique.

- Auteur : Clément Hadrot
- Publié le : 2024-07-10
- Mis à jour le : 2024-07-10
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/cdn-suffit-accelerer-site-mythe/

## L’essentiel

- Un CDN sert efficacement les images, CSS et JS déjà générés
- Il ne touche pas au temps de génération PHP d'une page dynamique
- Un TTFB élevé reste un TTFB élevé, CDN ou pas

Un CDN promet des visiteurs plus proches du contenu, des temps de chargement réduits, une infrastructure plus résiliente. Toutes ces promesses sont réelles, mais elles concernent un périmètre précis : les fichiers statiques déjà générés. Un CDN ne change strictement rien au temps que WordPress met à construire une page dynamique côté serveur.

Cette distinction, souvent perdue de vue dans les discussions commerciales autour des CDN, explique pourquoi certains sites installent un CDN et constatent une déception : le temps de chargement perçu ne s'améliore que marginalement, alors que l'investissement semblait pourtant logique.

## Ce qu'un CDN accélère réellement

Un réseau de diffusion de contenu fonctionne en répliquant des copies de fichiers statiques (images, feuilles de style, scripts JavaScript, parfois des pages HTML entièrement mises en cache) sur des serveurs répartis géographiquement, plus proches des visiteurs que le serveur d'origine. Pour ces types de contenu, le gain est réel et mesurable : un visiteur situé loin du serveur d'hébergement principal récupère ces fichiers depuis un point de présence beaucoup plus proche, réduisant la latence réseau de façon significative.

## Ce qu'un CDN ne touche pas

Une page dynamique WordPress — une page de résultats de recherche, une page de panier, un tableau de bord de compte client — nécessite l'exécution complète du code PHP, des requêtes à la base de données, et la construction du HTML final avant de pouvoir être envoyée où que ce soit. Un CDN ne peut mettre en cache et servir directement que ce qui a déjà été généré : il ne peut pas accélérer un processus qui n'a pas encore eu lieu.

```
# Ce que mesure un TTFB élevé, avant même l'intervention du CDN
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://exemple.test/mon-compte/
# Le CDN, pour cette page dynamique non mise en cache, ne change rien à ce chiffre
```

Si ce temps de génération est élevé en raison de requêtes SQL non optimisées ou d'un serveur PHP sous-dimensionné, le CDN placé devant ce serveur ne fera que transmettre plus rapidement une réponse qui a mis tout aussi longtemps à être produite.

> L'essentiel à retenir : Un CDN sert efficacement les images, CSS et JS déjà générés ; Il ne touche pas au temps de génération PHP d'une page dynamique ; Un TTFB élevé reste un TTFB élevé, CDN ou pas

## Le cas où la confusion se cristallise

Un site qui combine du contenu majoritairement dynamique (une plateforme de mise en relation avec des résultats personnalisés à chaque visite, par exemple) avec un CDN installé pour « accélérer le site » verra un gain limité aux quelques ressources statiques réellement mises en cache : logo, feuilles de style, polices. La page principale, celle qui concentre l'attention du visiteur, continuera de transiter par le serveur d'origine avec son temps de génération inchangé.

> Un CDN raccourcit la distance entre le visiteur et un contenu déjà prêt. Il ne raccourcit jamais le temps nécessaire pour préparer ce contenu.

## Comment diagnostiquer correctement avant d'investir

- Mesurer la part de trafic qui consomme réellement du contenu statique par rapport à du contenu généré dynamiquement à chaque visite.
- Vérifier le temps de génération serveur (TTFB) sur les pages dynamiques les plus consultées, indépendamment de tout CDN.
- Identifier si un cache de page complémentaire pourrait transformer une partie du contenu dynamique en contenu statique servi une fois puis réutilisé, ce qui élargirait alors réellement le périmètre d'action utile d'un CDN.

## Ce qu'il faut retenir avant de choisir un fournisseur

Le choix d'un fournisseur de CDN reste une question secondaire tant que le diagnostic de départ n'a pas clarifié quelle proportion du site profitera réellement de son installation. Un site à dominante dynamique doit d'abord investir dans l'optimisation de son temps de génération serveur (requêtes SQL, object cache, configuration PHP-FPM) avant d'espérer un gain perceptible d'un CDN placé en frontal.

## En résumé

Un CDN n'est ni inutile ni magique : il résout un problème précis, celui de la distance réseau pour du contenu déjà généré. Attendre de lui qu'il compense un temps de génération PHP élevé revient à confondre deux couches de l'architecture qui n'agissent pas sur les mêmes leviers, et qui doivent être diagnostiquées et traitées séparément.