« Ajoutez define('WP_CACHE', true); dans votre wp-config.php pour accélérer votre site. » Ce conseil circule depuis des années dans des tutoriels d’optimisation, souvent sans expliquer ce que cette ligne déclenche réellement. Beaucoup de développeurs l’ajoutent par habitude, la retirent parfois par précaution, sans mesurer d’effet perceptible dans un sens comme dans l’autre. Et pour cause : seule, cette constante ne fait presque rien.
Comprendre son rôle exact évite deux erreurs symétriques, celle de croire qu’elle active un cache invisible et magique, et celle de la considérer comme inutile parce qu’on ne voit rien changer après l’avoir ajoutée. Cet article se concentre sur le mécanisme interne déclenché par cette constante, sans entrer dans la configuration d’un cache d’objets externe comme Redis ou Memcached, qui mérite un traitement séparé.
Ce que fait réellement WP_CACHE
Le cœur de WordPress teste très tôt dans son cycle de chargement, dans le fichier wp-settings.php, si la constante WP_CACHE est définie et vaut true. Si c’est le cas, WordPress recherche un fichier nommé advanced-cache.php dans le dossier wp-content et l’inclut immédiatement, avant même le chargement des extensions classiques via le mécanisme habituel des hooks. C’est tout. La constante ne construit rien, ne stocke rien, ne met rien en cache par elle-même : elle ouvre simplement une porte que quelque chose d’autre doit franchir.
Un fichier qui n’existe pas par défaut
Sur une installation neuve de WordPress, le fichier advanced-cache.php n’existe pas. Activer WP_CACHE sans qu’un plugin l’ait déposé revient donc à ouvrir une porte sur un couloir vide. WordPress vérifie l’existence du fichier avant de l’inclure ; en son absence, l’exécution continue normalement, sans erreur visible, mais aussi sans aucun gain de performance.
Qui dépose ce fichier, et pourquoi c’est un plugin de cache de page
Les extensions de cache de page complète, celles qui génèrent des fichiers HTML statiques pour éviter de réexécuter PHP à chaque visite, sont les principales à exploiter ce mécanisme. Lors de leur activation, elles copient un fichier advanced-cache.php dans wp-content et s’assurent que WP_CACHE est défini à true dans wp-config.php, parfois automatiquement, parfois en demandant à l’utilisateur de le faire à la main. Ce fichier, exécuté avant même le chargement complet du cœur, peut alors intercepter la requête entrante, vérifier si une version en cache existe pour cette URL, et la servir directement sans jamais initialiser la boucle WordPress habituelle.
C’est cette possibilité d’intervenir aussi tôt dans le cycle de requête qui rend le mécanisme intéressant : un plugin de cache classique, activé via l’API standard des extensions, ne peut agir qu’une fois le cœur déjà chargé, ce qui limite les gains possibles. advanced-cache.php contourne cette limite en s’exécutant en amont.
Un ordre de chargement à connaître
Voici la séquence simplifiée telle qu’elle se déroule au démarrage d’une requête, dans l’ordre :
- WordPress charge
wp-config.phpet lit la constanteWP_CACHE. - Si elle vaut
true, WordPress cherchewp-content/advanced-cache.php. - Si le fichier existe, il est inclus immédiatement, avant le chargement des extensions ordinaires.
- Le fichier peut alors décider de servir une réponse en cache et d’arrêter l’exécution, ou de laisser WordPress poursuivre son chargement normal.
- Si aucune réponse en cache n’a été servie, le cœur continue son initialisation habituelle, charge les extensions actives via
plugins_loaded, et construit la page normalement.
Le piège du plugin désactivé mais du fichier resté en place
Un scénario fréquent en maintenance : un plugin de cache de page est désactivé ou désinstallé, mais son fichier advanced-cache.php reste physiquement présent dans wp-content, et la constante WP_CACHE reste à true dans wp-config.php. WordPress continue alors d’inclure ce fichier orphelin à chaque requête. Selon son contenu, cela peut provoquer des erreurs silencieuses, des pages qui semblent figées sur un ancien contenu, ou simplement du code mort exécuté à chaque visite. Le diagnostic passe systématiquement par la vérification de ce fichier avant toute autre piste.
| Situation | Effet observé |
|---|---|
| WP_CACHE à true, pas de fichier advanced-cache.php | Aucun effet, comportement standard |
| WP_CACHE à true, fichier présent et actif | Cache de page fonctionnel |
| WP_CACHE à true, fichier orphelin après désinstallation | Comportement imprévisible, à nettoyer |
| WP_CACHE à false, fichier présent | Fichier ignoré, aucun effet |
Sur un projet en maintenance, le réflexe qui évite bien des heures perdues : avant de suspecter une extension de cache, ouvrir
advanced-cache.phpet vérifier qu’il correspond bien au plugin réellement actif.
En résumé
WP_CACHE n’est ni un interrupteur de performance ni une case à cocher inoffensive : c’est un signal qui autorise le cœur de WordPress à déléguer, très tôt dans son cycle, l’exécution d’un fichier externe. Sans ce fichier, la constante reste muette. Avec lui, elle devient le point d’entrée d’un mécanisme de cache de page capable de court-circuiter l’exécution complète de WordPress. Comprendre cette mécanique évite d’ajouter la ligne par réflexe, et surtout d’oublier de la retirer proprement quand le plugin qui l’exploitait disparaît.
