« Le cache est activé, mais le site reste lent. » Cette phrase revient régulièrement dans les demandes d’audit, et elle cache presque toujours la même confusion : celle entre le cache de page et l’object cache persistant, deux mécanismes qui protègent des points très différents de l’exécution de WordPress.
Comprendre où s’arrête l’un et où commence l’autre permet de diagnostiquer correctement un site qui reste lent malgré une extension de cache installée et correctement configurée en apparence.
Ce que fait le cache de page
Le cache de page, qu’il soit géré par une extension comme WP Rocket ou W3 Total Cache, ou directement au niveau du serveur web via FastCGI Cache ou Varnish, intercepte la requête HTTP avant même qu’elle n’atteigne PHP. Une page déjà générée est servie telle quelle, sous forme de fichier HTML statique, sans exécuter la moindre ligne de code WordPress ni la moindre requête SQL.
Cette couche ne fonctionne, par nature, que pour des visiteurs anonymes consultant du contenu identique : un article public, une page d’accueil sans personnalisation. Dès qu’un contenu dépend de l’utilisateur connecté, d’un panier d’achat, ou de tout élément dynamique par requête, le cache de page ne peut plus s’appliquer et WordPress doit s’exécuter intégralement.
Ce que fait l’object cache persistant
L’object cache, lui, intervient à l’intérieur même de l’exécution PHP de WordPress. Chaque appel à wp_cache_get() ou wp_cache_set(), utilisé massivement par le cœur pour les options, les métadonnées, les objets de taxonomie et bien d’autres structures internes, passe par cette couche. Sans backend persistant (Redis ou Memcached), ce cache reste limité à la durée d’une seule requête PHP, via le cache d’objets non persistant intégré par défaut.
Avec un backend persistant correctement connecté (via un fichier object-cache.php dans wp-content), ces mêmes données survivent d’une requête à l’autre, évitant de recalculer ou de requêter à nouveau des informations déjà connues, y compris pour des visiteurs connectés ou des pages dynamiques que le cache de page ne peut pas servir.
Le tableau qui clarifie les rôles
| Aspect | Cache de page | Object cache persistant |
|---|---|---|
| Ce qu’il évite | L’exécution complète de PHP et WordPress | Les requêtes SQL et calculs répétés dans PHP |
| Fonctionne pour un visiteur connecté | Non, en général | Oui |
| Fonctionne pour l’API REST / admin-ajax | Non | Oui |
| Technologie typique | FastCGI Cache, Varnish, WP Rocket | Redis, Memcached |
| Ce qu’il ne résout pas | Le contenu dynamique et personnalisé | Les requêtes non couvertes par wp_cache_* |
Le diagnostic type d’un site lent malgré le cache
Un site e-commerce avec un panier, un compte client, ou un espace membre reste largement hors du champ d’action du cache de page pour ses pages les plus utilisées. Si aucun object cache persistant n’est configuré en complément, chaque page de panier, chaque page de compte, chaque appel admin-ajax.php repart de zéro, avec l’intégralité des requêtes SQL nécessaires, à chaque visite.
C’est précisément ce scénario qui explique la plainte initiale : le cache de page, bien réel et bien actif, ne couvre tout simplement pas les pages qui posent problème. La confusion vient du fait que les deux couches portent souvent le nom générique de « cache » dans l’interface d’administration d’une même extension, sans que leur périmètre respectif soit clairement expliqué à l’utilisateur.
Comment vérifier lequel manque
- Consultez les en-têtes de réponse HTTP : un en-tête comme
X-Cache: HITconfirme un cache de page actif pour la page consultée. - Utilisez
wp eval "var_dump( wp_using_ext_object_cache() );"pour vérifier si un object cache externe est effectivement branché. - Activez temporairement Query Monitor sur une page dynamique typique (panier, compte) pour observer le nombre de requêtes SQL réellement exécutées.
Notre verdict
Aucune des deux couches ne remplace l’autre. Un site majoritairement anonyme et éditorial profite surtout du cache de page ; un site avec beaucoup de contenu dynamique par utilisateur a besoin, en plus, d’un object cache persistant pour ne pas repartir de zéro à chaque requête. Diagnostiquer un site « lent malgré le cache » commence toujours par identifier laquelle des deux couches couvre réellement les pages qui posent problème.
