# CDN devant WordPress : pourquoi et comment le mettre en place efficacement

> Réduire le TTFB, soulager le serveur, purger le cache au bon moment : voici comment choisir et configurer un CDN pour un site WordPress sans se tromper.

- Auteur : Clément Hadrot
- Publié le : 2022-05-12
- Mis à jour le : 2022-05-12
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/cdn-wordpress-pourquoi-comment/

## L’essentiel

- CDN d'assets vs CDN full page : deux logiques, deux usages
- La purge de cache doit suivre chaque publication
- Un CDN mal réglé peut servir du contenu périmé

Un site WordPress hébergé sur un serveur unique, aussi rapide soit-il, reste soumis à une contrainte physique incontournable : la distance entre le visiteur et le serveur. Un internaute à Tokyo qui charge un site hébergé à Paris subit une latence réseau que rien, côté PHP ou MySQL, ne peut corriger. C'est précisément le problème que résout un CDN (Content Delivery Network) : il rapproche le contenu de l'utilisateur en le distribuant depuis des points de présence répartis dans le monde.

Mais un CDN n'est pas une solution magique qu'on active en un clic sans y réfléchir. Mal configuré, il peut servir des pages obsolètes après une mise à jour, casser des formulaires dynamiques ou compliquer le débogage. Cet article explique pourquoi mettre un CDN devant WordPress, quelle différence faire entre CDN d'assets et CDN « full page », et comment gérer proprement la purge de cache.

## Pourquoi un CDN change la donne pour WordPress

WordPress génère des pages dynamiquement, mais la majorité du poids d'une page reste statique : images, feuilles de style, scripts JavaScript, polices. Ce sont ces ressources qui bénéficient le plus directement d'un CDN, car elles ne changent pas à chaque requête et peuvent être mises en cache pendant des jours, voire des mois.

Un CDN apporte trois bénéfices concrets :

- Une latence réduite, puisque le fichier est servi depuis un point de présence proche du visiteur plutôt que depuis le serveur d'origine.
- Une charge serveur allégée, car le CDN absorbe l'essentiel du trafic sur les assets statiques, laissant le serveur PHP se concentrer sur les requêtes dynamiques.
- Une meilleure résistance aux pics de trafic, le réseau du CDN étant dimensionné pour absorber des volumes que peu d'hébergements mutualisés peuvent encaisser seuls.

## CDN d'assets vs CDN « full page »

Il existe deux philosophies bien différentes, et confondre les deux mène à des choix de configuration inadaptés.

Le **CDN d'assets** (comme les offres classiques de type *pull zone*) se contente de distribuer les fichiers statiques : images, CSS, JS, polices. Le HTML de la page reste généré par le serveur WordPress à chaque requête. C'est l'approche la plus simple à mettre en place, généralement via un plugin qui réécrit les URL des médias et des fichiers du thème vers un sous-domaine CDN.

Le **CDN full page** va plus loin : il met en cache la page HTML entière, générée par WordPress, et la sert directement depuis le nœud CDN le plus proche sans même solliciter le serveur d'origine. C'est le principe utilisé par des solutions comme Cloudflare (avec le cache de page) ou certains proxys inversés placés devant l'hébergement. Le gain de TTFB est spectaculaire, puisque PHP et MySQL ne sont même plus sollicités pour une page déjà en cache.

> L'essentiel à retenir : CDN d'assets vs CDN full page : deux logiques, deux usages ; La purge de cache doit suivre chaque publication ; Un CDN mal réglé peut servir du contenu périmé

Le revers de la médaille du CDN full page, c'est la gestion du contenu dynamique : panier e-commerce, formulaires avec nonce WordPress, contenu personnalisé selon l'utilisateur connecté. Il faut alors exclure certaines routes du cache (`/wp-admin`, `/checkout`, les pages avec cookies de session) ou utiliser des mécanismes d'edge-side includes pour mélanger contenu statique et dynamique.

| Critère | CDN d'assets | CDN full page |
| --- | --- | --- |
| Ce qui est mis en cache | Images, CSS, JS, polices | Page HTML complète |
| Gain sur le TTFB | Faible à modéré | Très élevé |
| Complexité de mise en place | Faible | Moyenne à élevée |
| Risque de contenu périmé | Limité aux médias | Élevé sans purge rigoureuse |
| Compatible contenu dynamique | Oui, sans contrainte | Nécessite des exclusions |

## La purge de cache : le point qui casse tout si on l'oublie

C'est là que beaucoup d'installations CDN échouent. Un article modifié, un prix changé sur une fiche produit WooCommerce, une image remplacée : si le CDN continue à servir l'ancienne version, le visiteur voit une page périmée sans que rien ne l'alerte.

Pour un CDN d'assets, le problème se résout simplement grâce au *cache busting* : WordPress ajoute automatiquement un paramètre de version aux fichiers du thème et des plugins via `wp_enqueue_script()` et `wp_enqueue_style()`, ce qui force le rechargement dès que le numéro de version change.

```
wp_enqueue_style(
    'mon-theme-style',
    get_stylesheet_uri(),
    array(),
    '1.4.2'
);
```

Pour un CDN full page, la purge doit être déclenchée à chaque publication ou modification de contenu. La plupart des solutions proposent un hook côté WordPress qui appelle leur API de purge lors des événements `save_post` ou `transition_post_status` :

```
add_action( 'save_post', function ( $post_id ) {
    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }
    wp_remote_post( 'https://api.mon-cdn.example/purge', array(
        'body' => array( 'url' => get_permalink( $post_id ) ),
    ) );
} );
```

> Maison : testez toujours la purge sur un environnement de préproduction avant de la brancher en production. Une purge trop agressive (toute la zone à chaque sauvegarde) peut annuler une bonne partie du bénéfice du CDN en générant un pic de requêtes vers l'origine.

## Mettre en place un CDN d'assets pas à pas

Pour une première mise en place, mieux vaut commencer simple avec un CDN d'assets :

1. Créez une zone CDN pointant vers votre domaine d'origine (méthode *pull* : le CDN récupère le fichier au premier accès puis le met en cache).
2. Configurez un sous-domaine dédié, par exemple `cdn.mon-site.fr`, en enregistrement CNAME vers l'URL fournie par le CDN.
3. Installez un plugin de réécriture d'URL (beaucoup d'extensions de cache incluent cette fonctionnalité) pour que les balises `<img>`, `<link>` et `<script>` pointent vers le sous-domaine CDN plutôt que vers le domaine principal.
4. Vérifiez les en-têtes de cache renvoyés par votre serveur d'origine : sans en-tête `Cache-Control` correct, le CDN peut appliquer une durée de cache par défaut trop courte.

## Impact réel sur le TTFB et l'expérience utilisateur

Le TTFB (Time To First Byte) mesure le temps entre la requête du navigateur et la réception du premier octet de réponse. Avec un CDN d'assets seul, le TTFB du document HTML principal ne change pas puisqu'il continue d'être généré par le serveur d'origine. En revanche, le temps de chargement perçu global s'améliore nettement, car les images et scripts, souvent les ressources les plus lourdes, arrivent plus vite.

Avec un CDN full page, le TTFB du document HTML lui-même chute drastiquement pour les pages en cache, puisque la requête n'atteint jamais le serveur d'origine. C'est la configuration qui a le plus d'impact sur les métriques Core Web Vitals liées au chargement, en particulier le First Contentful Paint.

## En résumé

Un CDN d'assets est un excellent premier pas, simple à mettre en œuvre et sans risque majeur : il allège le poids des pages sans toucher à la logique de génération HTML. Un CDN full page va plus loin et transforme radicalement le TTFB, mais exige une gestion rigoureuse de la purge de cache et des exclusions pour le contenu dynamique.

Le bon choix dépend du profil du site : un blog éditorial à fort trafic tirera un bénéfice maximal d'un CDN full page bien réglé, tandis qu'un site e-commerce avec beaucoup de contenu personnalisé commencera prudemment par un CDN d'assets avant d'envisager, plus tard, une stratégie de cache de page plus fine.