Quand un site est lent, la première réaction de beaucoup de gens est presque un réflexe : « mettons Cloudflare ». On change les serveurs de noms, on active le proxy, et l’on s’attend à ce que les pages deviennent instantanées. Parfois quelque chose s’améliore, souvent bien moins que prévu, et le TTFB des pages reste exactement ce qu’il était. La raison, dans la plupart des cas, est une confusion de base entre deux fonctions différentes : le CDN, qui distribue les fichiers statiques, et le Full Page Cache, qui conserve des pages HTML toutes prêtes.
Cloudflare est un excellent outil et nous l’utilisons souvent. Mais ce n’est pas un remède miracle, et pour qu’il agisse vraiment sur la performance, il faut savoir ce qu’il fait par défaut, ce qu’il ne fait pas et ce qui doit être configuré. Reprenons dans l’ordre.
Ce qu’est vraiment Cloudflare
Cloudflare est un réseau mondial qui s’interpose entre les visiteurs et le serveur du site, l’origine. Quand le proxy est actif, chaque requête atteint d’abord l’un de ses nœuds, répartis dans des centaines de villes, et ne continue vers l’origine que si nécessaire. Sur cette position privilégiée, Cloudflare construit de nombreux services : DNS, certificats TLS, protection contre les attaques DDoS, pare-feu d’applications web, gestion des bots, prise en charge de HTTP/3 et, bien sûr, un CDN pour les contenus statiques.
Beaucoup de ces services fonctionnent bien dès le premier jour et justifient à eux seuls l’adoption de Cloudflare, surtout côté sécurité. Le problème apparaît quand on tient pour acquis que, étant « un CDN », Cloudflare accélère automatiquement tout le site, pages comprises.
CDN et Full Page Cache : la confusion la plus répandue
Un CDN conserve des copies des fichiers statiques, comme les feuilles de style, les scripts, les images et les polices, sur des nœuds proches des utilisateurs. Ce sont des fichiers identiques pour tout le monde et qui changent rarement : les servir depuis un nœud situé à quelques kilomètres plutôt que depuis le serveur d’origine réduit la latence et allège l’infrastructure.
Le Full Page Cache conserve en revanche le document HTML de la page, c’est-à-dire le résultat du travail de PHP et de la base de données. C’est lui qui détermine le TTFB, le temps que le navigateur attend avant de pouvoir commencer à construire la page, et c’est donc le fondement du LCP. Sans cache HTML, chaque visite oblige l’origine à générer à nouveau la page, même si toutes les images arrivent très vite depuis le CDN.
Les deux fonctions peuvent se trouver au même endroit, sur le nœud Cloudflare, ou à des endroits différents, avec le CDN en périphérie et le Full Page Cache à l’origine, par exemple avec Varnish. Mais ce sont deux choses distinctes, et activer l’une ne signifie pas avoir l’autre.
Par défaut, le HTML n’est pas mis en cache
Avec la configuration par défaut, Cloudflare met en cache les fichiers selon leur extension : images, feuilles de style, JavaScript, polices, documents comme les PDF et quelques autres formats. Les pages HTML ne figurent pas dans la liste. Chaque requête de page traverse donc le nœud sans s’arrêter et atteint l’origine, exactement comme si Cloudflare n’était pas là, avec un saut intermédiaire en plus.
C’est un choix prudent et correct : le HTML peut contenir des informations personnelles, comme le nom d’un utilisateur connecté ou le contenu d’un panier, et le mettre en cache sans précaution serait dangereux. Mais cela signifie que, si le problème du site est une origine lente, activer Cloudflare ne le résout pas.
Comment le vérifier en une minute
Cloudflare ajoute l’en-tête cf-cache-status à chaque réponse, qui indique si la ressource a été servie depuis le cache. Une seule requête en ligne de commande suffit :
curl -sI https://www.votresite.fr/ | grep -i cf-cache-status
cf-cache-status: DYNAMIC
curl -sI https://www.votresite.fr/wp-content/themes/theme/style.css | grep -i cf-cache-status
cf-cache-status: HIT| Valeur | Signification |
|---|---|
| HIT | Servi depuis le cache du nœud |
| MISS | Éligible à la mise en cache, mais pas encore présent : requête envoyée à l’origine |
| DYNAMIC | Non éligible à la mise en cache : c’est le cas du HTML avec les réglages par défaut |
| BYPASS | Cache ignoré à cause d’une règle ou des en-têtes de l’origine |
| EXPIRED, REVALIDATED | Copie périmée, téléchargée de nouveau ou revalidée auprès de l’origine |
Si les pages répondent avec DYNAMIC, Cloudflare agit comme CDN et comme bouclier, mais pas comme cache de page.
Pourquoi mettre le HTML en cache n’a rien d’anodin
Un cache HTML bien fait demande toujours trois éléments. Le premier est une règle qui établit ce qu’il faut mettre en cache. Le deuxième est un ensemble d’exclusions pour ce qui ne doit jamais finir dans le cache : espace d’administration, connexion, panier, tunnel de commande, espace client, et en général les visites d’utilisateurs reconnus par un cookie. Le troisième, le plus délicat, est un mécanisme d’invalidation : quand un article est mis à jour ou qu’un prix change, la copie en cache doit être purgée, faute de quoi les visiteurs verront un contenu périmé.
Une erreur sur le deuxième point est grave : la page vue par un administrateur, avec la barre d’édition, ou par un client avec son panier, pourrait être servie au visiteur suivant. Une erreur sur le troisième est plus insidieuse : des prix, des disponibilités ou des actualités périmés pendant des heures.
Les règles de cache
Pour mettre le HTML en cache, on utilise les règles de cache (cache rules) de Cloudflare, qui ont remplacé les anciennes Page Rules et leur réglage « Cache Everything ». Une règle peut rendre le HTML éligible à la mise en cache, définir la durée de conservation sur les nœuds et fixer des conditions d’exclusion, par chemin ou par cookie. Certaines fonctions avancées, comme l’exclusion par cookie, ont longtemps été réservées aux offres supérieures : avant de concevoir la configuration, mieux vaut vérifier ce que comprend votre offre.
Un détail important pour qui vient des Page Rules : là, seule la première règle correspondante était appliquée, alors que les règles de cache sont toutes évaluées, dans l’ordre, et que les suivantes peuvent écraser les précédentes. Les exclusions se placent donc en bas. Une configuration minimale pour WordPress et WooCommerce ressemble à ceci :
# Règle 1 : rendre le HTML du site éligible à la mise en cache
(http.host eq "www.votresite.fr")
→ Eligible for cache · Edge TTL: 2 hours
# Règle 2 (après la première) : exclure les zones dynamiques et les utilisateurs reconnus
(starts_with(http.request.uri.path, "/wp-admin")
or http.request.uri.path eq "/wp-login.php"
or starts_with(http.request.uri.path, "/panier")
or starts_with(http.request.uri.path, "/checkout")
or starts_with(http.request.uri.path, "/mon-compte")
or http.cookie contains "wordpress_logged_in"
or http.cookie contains "woocommerce_items_in_cart")
→ Bypass cacheC’est un point de départ, pas une configuration universelle. Chaque site a ses propres chemins dynamiques, ses propres API, des plugins qui posent des cookies et des pages qui changent souvent : il faut les identifier un par un et les vérifier avec l’en-tête cf-cache-status.
APO : la mise en cache du HTML pensée pour WordPress
Pour les sites WordPress, Cloudflare propose une solution toute prête : APO, Automatic Platform Optimization. C’est un module complémentaire payant sur l’offre gratuite et inclus dans les offres supérieures, activé par le plugin WordPress officiel de Cloudflare. APO met en cache les pages HTML sur le réseau de Cloudflare, exclut automatiquement les visites portant les cookies typiques de WordPress et WooCommerce, comme ceux des utilisateurs connectés ou du panier, et surtout gère l’invalidation : quand un contenu est publié ou modifié, le plugin indique à Cloudflare quelles pages purger.
Pour un blog ou un site d’information sous WordPress, APO est souvent le moyen le plus simple d’obtenir un vrai cache HTML sur les nœuds, avec un TTFB bas pour les visiteurs du monde entier. Mais ce n’est pas de la magie non plus : il ne fonctionne qu’avec WordPress, dépend du plugin pour l’invalidation, et doit être contrôlé avec soin quand le site affiche des contenus différents selon la langue, la devise, la zone géographique ou l’appareil, ou quand d’autres plugins de cache travaillent en parallèle.
Les pièges dont personne ne parle
- Les nonces WordPress. De nombreux formulaires et requêtes AJAX incluent dans le HTML un code de sécurité à validité limitée, généralement quelques heures. Si une page reste en cache plus longtemps, ce code expire et les formulaires de contact, les recherches ou les boutons cessent de fonctionner pour celui qui reçoit l’ancienne copie. Le TTL du HTML doit être choisi en tenant compte de cela aussi.
- Les sites à faible trafic. Chaque nœud a son propre cache. Si un site reçoit peu de visites, de nombreuses pages ne sont pas en cache sur le nœud par lequel passe l’utilisateur et la requête continue de toute façon vers l’origine, avec un saut de plus. Le cache à plusieurs niveaux (tiered cache) de Cloudflare réduit le problème, mais ne l’élimine pas.
- Tout purger. Le bouton qui vide tout le cache est pratique, mais il oblige chaque nœud à le reconstruire de zéro, avec un pic de requêtes vers l’origine au pire moment. Mieux vaut purger uniquement les URL concernées, à la main ou via un plugin.
- Le débogage. Avec plusieurs nœuds et plusieurs couches de cache, deux utilisateurs peuvent voir des versions différentes d’une même page. Sans méthode et sans lire les en-têtes de réponse, trouver la cause d’un problème devient long et coûteux.
Cloudflare et cache à l’origine : des couches complémentaires
La bonne question n’est pas « Cloudflare ou Varnish ? » mais quel rôle confier à chaque couche. Le cache du navigateur évite de télécharger de nouveau ce que l’utilisateur a déjà. Le CDN sert les fichiers statiques depuis un point proche et, s’il est configuré, le HTML aussi. Le Full Page Cache à l’origine, avec Varnish comme référence pour les projets les plus exigeants, accélère toutes les requêtes que le nœud ne peut pas servir seul. Le cache d’objets et une application bien optimisée accélèrent même ce qui ne peut pas être mis en cache, comme le panier ou l’espace client.
Dans cette architecture, Cloudflare est précieux, mais c’est une couche parmi d’autres. Une origine lente reste lente pour toutes les requêtes que le cache en périphérie n’intercepte pas : utilisateurs connectés, paniers, pages tout juste mises à jour, nœuds au cache encore vide. Et c’est précisément là que se jouent les conversions d’un site e-commerce.
Les autres fonctions « miracle »
Cloudflare propose aussi des optimisations qui promettent des améliorations en un clic, comme la compression des images ou Rocket Loader, qui diffère le chargement du JavaScript. Elles peuvent être utiles, mais il faut les traiter comme n’importe quelle autre optimisation automatique : les activer une par une et mesurer. Différer le JavaScript, en particulier, peut améliorer les tests de laboratoire et dégrader la réactivité réelle, pour les raisons que nous avons décrites en parlant de retarder le JavaScript jusqu’au premier clic.
Comment déterminer ce dont votre site a besoin
- Mesurez le TTFB des pages principales et vérifiez
cf-cache-status: si le HTML estDYNAMICet que le TTFB est élevé, le problème est l’origine ou l’absence de cache de page. - Évaluez la part du trafic qui est anonyme : plus elle est élevée, plus un cache HTML, sur les nœuds ou à l’origine, aura d’effet.
- Listez les parties dynamiques du site, les cookies qui les identifient et la fréquence de changement des contenus : ce sont les ingrédients des exclusions et des durées d’expiration.
- Choisissez où placer le cache HTML : règles Cloudflare, APO pour WordPress, Varnish à l’origine ou une combinaison, selon l’audience, le trafic et le budget.
- Vérifiez le résultat sur des données d’utilisateurs réels, pas seulement avec un test : le TTFB et le LCP au 75e percentile sont le juge final.
En résumé
Cloudflare n’est pas un remède miracle, mais c’est un excellent outil quand on sait ce qu’on lui demande. Par défaut, c’est un CDN et un bouclier : il sert les fichiers statiques depuis un point proche et protège le site, mais laisse passer le HTML jusqu’à l’origine. Pour accélérer les pages, il faut un cache HTML, qui peut être configuré sur les nœuds avec des règles de cache ou avec APO pour WordPress, ou à l’origine avec un Full Page Cache comme Varnish, idéalement en combinaison.
Confondre le CDN avec le Full Page Cache fait croire que l’on a résolu un problème qui est toujours là. Les distinguer permet de bâtir une architecture où chaque couche joue son rôle, et où même les requêtes qu’aucun cache ne peut servir, comme celles des utilisateurs sur le point d’acheter, restent rapides.
