CDN pour WordPress : comment bien le choisir

Il existe deux types de CDN pour WordPress : le CDN de ressources, qu’une extension branche en réécrivant les URL de vos images, CSS et JavaScript, et le proxy de site complet, qui se place devant tout votre domaine et peut aussi mettre en cache les pages HTML elles-mêmes. Le bon choix dépend de l’endroit où votre site perd du temps, de l’origine de vos visiteurs et de l’ampleur des changements DNS que vous êtes prêt à faire. Ce guide compare les deux types et vous donne une checklist pour choisir un fournisseur.

Pour les bases, voyez qu’est-ce qu’un CDN. Si vous ne savez pas encore pourquoi votre site est lent, trouvez d’abord la cause avec le guide pourquoi un site WordPress est lent.

Les deux types de CDN pour WordPress

CDN de ressources (fichiers statiques via une extension)

Un CDN de ressources ne sert que des fichiers statiques. Vous créez une pull zone chez le fournisseur et obtenez un nom d’hôte comme cdn.example.com. Une extension WordPress réécrit ensuite les URL dans votre HTML pour que les fichiers de wp-content et wp-includes se chargent depuis ce nom d’hôte. À la première requête, le CDN récupère chaque fichier sur votre serveur et en garde une copie.

Votre domaine, votre DNS et votre HTML restent où ils sont. Chaque page vue passe toujours par votre hébergement, qui génère le HTML comme avant. Seuls les fichiers référencés par la page viennent du CDN.

Proxy de site complet (tout le domaine via les serveurs de noms ou le DNS)

Un proxy de site complet prend en charge le trafic de tout votre domaine. Selon le fournisseur, vous lui déléguez vos serveurs de noms ou vous faites pointer le DNS de votre domaine vers lui. Dès lors, chaque requête, HTML compris, passe d’abord par les serveurs edge du fournisseur. L’edge sert ce qu’il a le droit de mettre en cache et transmet le reste à votre hébergement.

Comme tout le trafic passe par lui, un proxy de site complet peut mettre en cache le HTML des pages publiques, gérer le HTTPS et filtrer les attaques avant qu’elles n’atteignent votre serveur. C’est aussi le changement le plus important, puisque tout votre site dépend de la bonne configuration du proxy.

Ce que chaque type met en cache

La différence décisive, c’est le HTML. Sur un site WordPress typique, la partie lente d’une page vue est la génération de la page par le serveur avec PHP et la base de données. Un CDN de ressources ne touche pas à cette étape, votre temps jusqu’au premier octet reste donc le même.

Un proxy de site complet peut servir ce HTML depuis l’edge aux visiteurs anonymes, sans aucune intervention de PHP ni de la base de données. C’est pourquoi ce type aide le plus quand le TTFB est élevé ou que votre serveur peine aux heures de pointe.

Les ressources sont mises en cache par les deux types. Si vos pages sont déjà générées rapidement (par exemple grâce à un bon cache de pages sur le serveur) et que les visiteurs attendent surtout de gros fichiers, un CDN de ressources peut couvrir une grande partie de vos besoins.

Avantages et inconvénients en pratique

Quand un CDN de ressources suffit

• La réponse de votre serveur est déjà rapide, et ce sont les images ou scripts lourds qui freinent.
• Vous ne pouvez pas ou ne voulez pas modifier les serveurs de noms ou le DNS de votre domaine.
• Vous voulez un changement réversible en désactivant simplement une extension.

Attention aux effets de bord typiques. Les fichiers codés en dur dans le thème, dans le CSS d’un constructeur de pages ou dans des styles en ligne ne sont souvent pas réécrits et continuent de se charger depuis votre origine. Les polices web chargées depuis un autre nom d’hôte ont besoin d’un en-tête Access-Control-Allow-Origin adapté, sinon le navigateur refuse de les utiliser. Enfin, WordPress ajoute un paramètre ?ver= aux scripts et styles enregistrés : le CDN doit inclure les paramètres de requête dans sa clé de cache, sinon les visiteurs continuent de recevoir l’ancien fichier après une mise à jour.

Quand un proxy de site complet est rentable

• Votre TTFB est élevé sur les pages publiques, ou le serveur ralentit pendant l’envoi d’une newsletter ou des soldes.
• Vos visiteurs sont répartis sur plusieurs pays ou continents.
• Vous voulez que le filtrage DDoS et le HTTPS soient gérés en amont de votre hébergement.

Les compromis sont réels aussi. Vous devez configurer correctement les règles de contournement pour qu’aucune page personnelle ne soit jamais mise en cache pour tout le monde. Après la publication ou la modification d’un article, le HTML en cache doit être rafraîchi. Votre serveur voit désormais le proxy comme client, vos extensions de sécurité ou de statistiques doivent donc lire la vraie IP du visiteur dans l’en-tête transmis par le fournisseur. Et un attaquant qui connaît l’adresse IP de votre serveur peut toujours contourner l’edge, sauf si votre hébergeur n’accepte que le trafic venant du proxy.

La checklist de sélection

Posez-vous ces questions en comparant les fournisseurs. Elles s’appliquent à n’importe quel CDN, quel que soit son nom.

Cache HTML et règles de contournement

Le CDN peut-il mettre le HTML en cache, et comment décide-t-il de ce qu’il ignore ? Pour WordPress, ces éléments doivent toujours atteindre votre serveur sans cache :

• /wp-admin/, wp-login.php et admin-ajax.php
• les visiteurs avec un cookie wordpress_logged_in_ (la référence des cookies WordPress, en anglais, liste tous les cookies posés par le cœur)
• les commentateurs avec un cookie comment_author_, pour qu’ils voient leur propre commentaire en attente de modération
• les articles protégés par mot de passe, qui utilisent un cookie wp-postpass_
• les aperçus d’articles et tout ce qui est personnalisé, comme le panier et les pages de compte d’une boutique

WordPress vous facilite la tâche : pour les utilisateurs connectés, les articles protégés par mot de passe et les pages 404, il envoie Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. Un proxy qui respecte les en-têtes Cache-Control contourne donc ces réponses. Le risque vient des extensions qui personnalisent les pages sans envoyer de tels en-têtes, alors testez-les.

Purge après publication

Quand vous mettez à jour un article, l’article lui-même change, mais aussi la page d’accueil, les archives de catégories et d’étiquettes, et le flux. Demandez comment vider le cache : par URL, pour tout le domaine, depuis un tableau de bord, via API ? La purge automatique à la publication dépend du fournisseur et de votre configuration. Sans elle, il vous faut une durée de cache assez courte ou une routine de purge après les modifications.

Optimisation des images

Le CDN convertit-il les images en WebP ou AVIF, et sert-il toujours l’original aux navigateurs qui ne prennent pas en charge le nouveau format ? Cela peut vous épargner une extension d’images qui fait ce travail sur votre serveur.

SSL entre visiteur, edge et serveur

Avec un CDN de ressources, le nom d’hôte du CDN a besoin de son propre certificat. Avec un proxy de site complet, l’edge détient le certificat de votre domaine. Assurez-vous que la connexion entre l’edge et votre serveur utilise aussi HTTPS. Si le proxy parle en HTTP simple à un site WordPress qui force HTTPS, vous pouvez vous retrouver dans une boucle de redirections infinie, comme l’explique la documentation WordPress sur HTTPS (en anglais).

Sécurité et protection DDoS

Un CDN de ressources ne protège que les fichiers qu’il sert. Les attaques contre vos pages, votre page de connexion ou XML-RPC frappent toujours directement votre serveur. Un proxy de site complet peut filtrer les inondations de requêtes, bloquer des pays ou des plages d’IP et limiter le débit des clients abusifs en edge. Vérifiez ce qui est inclus dans l’offre envisagée et ce qui coûte en plus.

Emplacements edge proches de votre audience

Un CDN n’aide face à la distance que s’il dispose de serveurs edge proches de vos visiteurs. Regardez d’où viennent réellement vos visiteurs, puis quelles régions le fournisseur couvre avec votre offre.

Effort de mise en place, DNS et e-mails

Pour un CDN de ressources, vous saisissez un nom d’hôte dans une extension et ajoutez peut-être un enregistrement CNAME. Pour un proxy de site complet, votre DNS migre généralement chez le fournisseur. Chaque enregistrement doit donc y être présent avant la bascule, y compris les enregistrements MX pour la messagerie et les enregistrements TXT pour SPF, DKIM et la vérification du domaine. La checklist pour changer de serveurs de noms sans interruption détaille cette étape pas à pas.

Visibilité

Cherchez un en-tête de réponse qui indique hit, miss ou bypass pour chaque requête, ainsi que des statistiques sur le taux de hits, le trafic servi par l’edge ou par l’origine et les taux d’erreur. Sans cela, impossible de savoir si le CDN sert vraiment à quelque chose.

Mesurer avant et après

Ne jugez pas un CDN à l’impression. Avant la bascule, établissez une référence :

1. Passez votre page d’accueil, un article et une page d’archive dans corewebvitals.page. Notez les données d’utilisateurs réels (si votre site a assez de trafic) et les résultats Lighthouse pour mobile et ordinateur.
2. Mesurez la réponse serveur du HTML depuis votre propre machine :

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Après la bascule, demandez deux fois la même page et regardez les en-têtes. La deuxième requête doit afficher un hit.

curl -sI https://example.com/ | grep -i -E "cache|age"

4. Connectez-vous et vérifiez que wp-admin et votre front-end affichent un bypass, pas un hit.
5. Comparez à nouveau les données d’utilisateurs réels une fois qu’elles ont rattrapé le changement, puisqu’elles couvrent les 28 derniers jours.

Le guide pour mesurer la vitesse d’un site explique comment garder une telle comparaison équitable.

Comment fast.site vous aide

fast.site est un proxy de site complet. Il se place devant votre hébergement WordPress existant, vous gardez donc votre hébergeur et votre site. Vous ajoutez votre domaine dans le tableau de bord, faites pointer vos serveurs de noms vers fast.site et vérifiez. fast.site gère ensuite votre DNS, donc tous les enregistrements existants, y compris les MX pour la messagerie, doivent figurer dans la zone DNS de fast.site.

Fast Edge Cache™ sert les pages publiques et les ressources depuis des serveurs edge situés dans les régions disponibles avec votre offre. fast.site respecte les en-têtes Cache-Control envoyés par votre site WordPress, et l’en-tête de réponse fs-cache indique HIT, MISS ou BYPASS, ce qui vous permet de contrôler vous-même wp-admin et les sessions connectées. Après une publication, vous pouvez purger des URL individuelles ou tout le domaine dans le tableau de bord, avec un journal des purges, ou via l’API depuis vos propres scripts.

Les images JPEG et PNG sont converties à la volée en WebP pour les navigateurs compatibles, avec AVIF selon votre offre. Chaque domaine bénéficie d’une détection DDoS automatique de couche 7 et de certificats SSL gratuits renouvelés automatiquement. Les détails se trouvent sur la page WordPress et dans la documentation sur le cache.

Mesurez votre site avant et après, avec les mêmes pages et les mêmes outils. Vous pouvez le tester avec un essai gratuit de 7 jours.

Questions fréquentes

Faut-il une extension CDN pour WordPress ?

Seulement pour un CDN de ressources, car l’extension réécrit les URL de vos fichiers vers le nom d’hôte du CDN. Un proxy de site complet fonctionne au niveau du DNS et n’a pas besoin de réécrire les URL, puisque votre domaine reste le même. Certains fournisseurs proposent tout de même une extension pour des tâches comme la purge.

Un CDN remplace-t-il mon extension de cache ?

Pas forcément. Un cache de pages sur votre serveur accélère chaque requête qui n’est pas servie par le CDN ainsi que tout le trafic connecté, comme le décrit la documentation WordPress sur le cache (en anglais). Avec un proxy de site complet, il compte moins pour les visiteurs anonymes, mais le garder fait rarement de mal.

Un CDN va-t-il casser wp-admin ou les connexions ?

Il ne devrait pas, tant que wp-admin, la page de connexion et les visiteurs connectés contournent le cache. WordPress envoie des en-têtes no-cache pour les utilisateurs connectés. Testez après la mise en place : connectez-vous, modifiez un article et vérifiez l’en-tête de cache sur les pages d’administration.

Pourquoi mes modifications n’apparaissent-elles pas après la mise à jour d’un article ?

Le CDN sert encore la copie en cache. Purgez l’URL de l’article et les pages qui le listent, comme la page d’accueil et les archives de catégories. Pour le CSS et le JavaScript, vérifiez que le CDN conserve le paramètre ?ver= dans sa clé de cache.