Contrairement à ce que son nom laisse penser, la constante WP_CACHE ne met en cache absolument rien par elle-même. Elle n’est ni un mécanisme de stockage, ni une couche de performance : c’est un simple indicateur, lu très tôt dans le cycle de chargement de WordPress, qui informe le cœur qu’un fichier de cache avancé (advanced-cache.php) doit être chargé depuis le dossier wp-content.
Cette distinction, presque sémantique, a des conséquences très concrètes lors d’un audit de performance mené sur un hébergement mutualisé : si la constante est absente ou mise à false, une extension de cache pourtant installée et configurée peut rester totalement inactive, sans qu’aucun message d’erreur ne le signale à l’administrateur.
Définition et fonctionnement interne
Dans le fichier wp-config.php, la ligne concernée ressemble généralement à ceci :
define( 'WP_CACHE', true );
Cette constante est lue par le fichier wp-settings.php, très tôt dans l’initialisation du cœur, avant même le chargement des extensions. Si elle vaut true, WordPress inclut le fichier wp-content/advanced-cache.php, généralement déposé par l’extension de cache elle-même lors de son activation. Ce fichier contient la logique de mise en cache réelle : lecture d’un fichier HTML déjà généré, court-circuitage du chargement complet de WordPress pour les visiteurs anonymes, gestion des règles d’exclusion.
Sans cette constante à true, ce fichier n’est jamais inclus, quelle que soit la configuration renseignée dans l’interface d’administration de l’extension. L’extension peut afficher un statut « actif » dans son propre tableau de bord tout en étant, en pratique, totalement sans effet sur le temps de réponse réel du serveur.
Comparaison avec les autres mécanismes de cache
| Mécanisme | Rôle | Dépend de WP_CACHE |
|---|---|---|
| WP_CACHE | Indicateur d’activation du cache de page avancé | — |
| Cache objet (object cache) | Mise en cache des requêtes répétées à la base de données | Non, mécanisme indépendant |
| Cache navigateur (en-têtes HTTP) | Mise en cache côté client via Cache-Control | Non, géré au niveau des en-têtes serveur |
| OPcache PHP | Mise en cache du bytecode PHP compilé | Non, configuré au niveau du serveur PHP |
Cette distinction explique pourquoi un audit qui se contente d’observer un temps de réponse serveur correct peut passer à côté du vrai problème : un OPcache correctement configuré au niveau du serveur peut masquer partiellement l’absence de cache de page, en accélérant l’exécution du code PHP sans jamais servir directement une page déjà générée.
Cas d’usage typique en hébergement mutualisé
Sur un hébergement mutualisé, il n’est pas rare que le fichier wp-config.php soit régénéré ou remplacé lors d’une opération de maintenance côté hébergeur, par exemple lors d’un changement de version PHP géré automatiquement. Si cette régénération repart d’un modèle de base ne comportant pas la ligne WP_CACHE, l’extension de cache installée peut se retrouver silencieusement désactivée du jour au lendemain, sans qu’aucune alerte ne soit remontée à l’équipe technique.
Un audit de performance mené dans ces conditions, sans vérifier au préalable la présence de cette ligne, risque de conclure à tort que l’extension de cache elle-même est inefficace, alors que le problème se situe une étape plus tôt, dans un fichier de configuration qui n’a rien à voir avec l’extension.
Vérifier la présence de la constante avant tout diagnostic
- Ouvrir le fichier
wp-config.phpet rechercher la lignedefine( 'WP_CACHE', true );. - Vérifier, via
wp eval "var_dump( defined('WP_CACHE') && WP_CACHE );", que la constante est bien définie et évaluée à vrai au moment de l’exécution. - Confirmer la présence effective du fichier
wp-content/advanced-cache.php, qui doit correspondre à l’extension de cache actuellement active. - Seulement après ces trois vérifications, passer au diagnostic de performance proprement dit.
Pièges fréquents autour de cette constante
- Une extension de cache désinstallée laisse parfois la ligne
WP_CACHEactive danswp-config.phpsans que le fichieradvanced-cache.phpcorrespondant existe encore, ce qui peut provoquer une erreur fatale au chargement. - Deux extensions de cache installées simultanément peuvent entrer en conflit sur ce même fichier
advanced-cache.php, chacune tentant de l’écraser lors de son activation. - Un environnement de développement local qui copie tel quel le
wp-config.phpde production peut activer un cache avancé qui masque des modifications de contenu pendant les tests.
Avant de conclure qu’une extension de cache est mal configurée, on vérifie toujours en premier lieu si elle est seulement, techniquement, autorisée à s’exécuter.
En résumé
WP_CACHE n’est pas un mécanisme de cache, c’est une porte d’entrée que le cœur de WordPress vérifie avant d’en charger un. Sur un hébergement mutualisé où le fichier de configuration peut être régénéré à l’insu de l’équipe technique, cette seule ligne mérite une vérification systématique en tout début d’audit de performance, avant d’aller chercher des explications plus complexes à un cache qui, en réalité, ne s’exécute jamais.
