# Object cache persistant contre cache de page : deux couches confondues

> Un site « lent malgré le cache activé » cache souvent une confusion entre deux mécanismes qui ne protègent pas du tout la même chose.

- Auteur : WordPress Développement
- Publié le : 2023-10-04
- Mis à jour le : 2023-10-04
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/object-cache-persistant-vs-cache-page/

## L’essentiel

- Le cache de page sert du HTML tout fait aux visiteurs anonymes
- L'object cache accélère les requêtes internes de WordPress
- Les deux sont complémentaires, jamais interchangeables

« 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.

> L'essentiel à retenir : Le cache de page sert du HTML tout fait aux visiteurs anonymes ; L'object cache accélère les requêtes internes de WordPress ; Les deux sont complémentaires, jamais interchangeables

## 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: HIT` confirme 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.