Le cache objet WordPress évite de recalculer ou relire certaines données au cours d’une requête. Par défaut, ce cache disparaît à la fin de la page ; un backend persistant peut conserver les objets entre requêtes. Le gain dépend du travail répétitif, du code, de l’invalidation et de la mémoire.
Installer une extension sans service compatible, ou activer un cache alors que le cache de page absorbe presque tout, peut apporter peu. Une configuration incorrecte peut aussi servir une donnée périmée ou faire partager des clés entre sites.
Sommaire
La réponse courte
Mesurez d’abord les requêtes et parcours dynamiques : administration, clients connectés, boutique, API et recherche. Installez un backend persistant uniquement si l’environnement le supporte et qu’un test représentatif montre moins de travail ou une meilleure latence.
Isolez les sites, surveillez taux de succès, mémoire, évictions, erreurs et base. Vérifiez l’invalidation après mise à jour de contenu, commande et configuration. Conservez une procédure pour désactiver le drop-in et purger sans publier endpoint, mot de passe ou topologie.
La classe officielle `WP_Object_Cache` est non persistante par défaut ; la persistance nécessite un mécanisme de remplacement adapté.
Principes qui restent valables
WordPress utilise des clés et des groupes via les fonctions wp_cache_*. Les composants peuvent mettre en cache des options, objets de publication, termes ou résultats coûteux. Un cache persistant rend ces données disponibles aux requêtes suivantes.
Les implémentations proposent des fonctions et politiques différentes. Le code doit vérifier les capacités réellement supportées, notamment avant de vider un groupe, car une émulation peut entraîner une purge plus large.
Distinguer cache de page et cache objet
Le cache de page stocke une réponse HTML complète et peut éviter l’exécution de WordPress. Le cache objet intervient pendant l’exécution pour éviter certaines lectures ou calculs. Ils répondent à des problèmes différents.
Un article public anonyme très cacheable bénéficie surtout de la page. L’administration, les comptes et le paiement ne peuvent généralement pas partager la même page, mais peuvent bénéficier d’objets réutilisés.
Mesurez chaque couche séparément et évitez le terme vague « cache activé ».
Comprendre le cache non persistant
Sans drop-in, les objets restent en mémoire pour la durée d’une requête. Ils évitent déjà qu’un même objet soit lu plusieurs fois pendant cette page. La fin de PHP libère ces valeurs.
Cette couche ne nécessite pas de service externe et conserve peu de risque de données périmées entre requêtes. Elle ne réduit pas les premières lectures de la page suivante.
La constante WP_CACHE seule n’active pas un backend objet persistant moderne.
Comprendre le backend persistant
Un fichier object-cache.php remplace l’implémentation et communique avec un stockage adapté. Les objets peuvent alors survivre entre requêtes jusqu’à expiration, suppression, éviction ou purge.
Le service doit être correctement authentifié, isolé et non exposé publiquement. Sa mémoire et sa politique d’éviction doivent correspondre au site. Le réseau ajouté peut lui-même introduire une latence.
N’annoncez pas la technologie réelle de production dans un article.
Identifier les parcours candidats
Mesurez pages non servies par le cache HTML : administration, recherche, panier, compte, API, imports et tâches. Cherchez des lectures répétées d’options, contenus ou termes.
Un site simple avec peu de trafic et une base proche peut ne pas gagner de façon mesurable. Un site dynamique avec beaucoup de requêtes répétées peut mieux répondre.
Le guide WordPress d’optimisation présente la persistance comme un moyen de réduire les allers-retours vers la base.
Établir une référence
Relevez latence, TTFB, nombre et durée de requêtes, cache de page, CPU, mémoire et erreurs sur des scénarios identiques. Exécutez plusieurs répétitions avec cache froid et chaud.
Conservez versions, jeu de données et état de connexion. Une comparaison entre deux jours de trafic différent ne suffit pas.
Mesurez aussi la base pendant un pic représentatif pour voir si elle est réellement le goulot.
Tester sur staging
Le staging doit reproduire volumes, extensions et parcours sans exposer les données personnelles. Installez le service et le drop-in selon une procédure documentée.
Vérifiez la connexion, l’absence d’erreurs et le comportement lorsque le service s’arrête. WordPress doit dégrader de façon connue, et l’équipe doit savoir retirer le drop-in si nécessaire.
Neutralisez les sorties et ne pointez jamais un staging vers le cache de production.
Isoler plusieurs sites
Lorsque plusieurs installations utilisent le même backend, elles doivent posséder un préfixe ou espace de clés distinct. Sinon, des identifiants identiques peuvent entrer en collision et servir des données incohérentes.
Multisite possède aussi des groupes globaux partagés entre sites du réseau. L’implémentation doit respecter cette logique sans fusionner des réseaux indépendants.
Testez l’isolation avec des contenus volontairement différents et ne partagez pas les clés réelles.
Comprendre groupes et clés
Une clé n’est unique qu’avec son groupe et son préfixe. Les extensions doivent utiliser les fonctions WordPress plutôt que parler directement au backend lorsqu’elles veulent bénéficier de l’abstraction.
Des clés trop longues, non bornées ou contenant des données personnelles augmentent coût et risque. Préférez des identifiants stables et une durée adaptée.
Ne supposez pas qu’une valeur restera jusqu’à son expiration : un cache peut l’évincer plus tôt.
Gérer les transients
Avec un cache persistant, les transients peuvent être stockés hors de la base. Le code doit pouvoir les régénérer, car leur expiration constitue un maximum et ils peuvent disparaître avant.
Après activation, les outils qui cherchent uniquement dans wp_options peuvent ne plus voir la valeur. Ne supprimez pas des lignes en pensant gérer toute la couche.
La documentation de l’API Transients décrit ce comportement.
Vérifier l’invalidation
Modifiez un article, menu, produit, prix, stock, rôle et option de test. La nouvelle valeur doit apparaître partout après l’action prévue. Vérifiez site public, administration, API et autre nœud si l’architecture en possède.
Une amélioration de temps avec prix obsolète est un échec. Identifiez le composant qui met en cache et le hook qui invalide.
Rejouez l’invalidation après mise à jour d’extension.
Mesurer hits et misses
Le taux de succès aide à comprendre la réutilisation, mais un pourcentage élevé n’est pas un objectif isolé. Un hit sur un petit objet et un miss sur une requête coûteuse n’ont pas la même valeur.
Corrélez hits, temps évité, mémoire et latence. Un cache vide après déploiement produit temporairement davantage de misses.
Agrégerez les métriques et évitez de stocker des clés sensibles dans le système de suivi.
Surveiller mémoire et évictions
Un backend sans limite peut consommer des ressources ; une limite trop faible évince les objets utiles et crée un cycle de reconstruction. Surveillez mémoire utilisée, évictions, connexions, erreurs et temps de réponse.
Identifiez les groupes dominants sans publier leur détail interne. Fixez une alerte avant saturation.
Une croissance continue peut signaler des clés sans borne ou une absence d’expiration.
Éviter les purges globales
Vider tout le cache force la reconstruction et peut provoquer un pic de base. Préférez l’invalidation ciblée ou par groupe lorsque l’implémentation le supporte réellement.
WordPress recommande de vérifier `wp_cache_supports()` avant certaines opérations de groupe. Un fallback mal conçu peut vider davantage que prévu.
Planifiez les purges de masse et surveillez la base.
Tester la panne du service
Coupez le backend sur staging ou simulez une indisponibilité. Observez délais, erreurs, reprise et santé de PHP. L’application doit éviter une attente longue à chaque requête.
Documentez comment désactiver le drop-in, redémarrer le service et réchauffer progressivement. Testez aussi une donnée corrompue ou sérialisée incompatible selon les capacités.
Le cache doit être reconstructible ; il ne doit pas devenir la seule copie d’une donnée métier.
Évaluer la cohérence WooCommerce
Testez prix, stock, panier, compte, commande et remboursement en mode sûr. Vérifiez deux utilisateurs et deux sessions. La cohérence prime sur le nombre de requêtes économisées.
Certaines extensions gèrent leurs propres caches ou files. Identifiez-les et ne supposez pas que le drop-in invalide tout automatiquement.
Surveillez particulièrement les données qui changent pendant un achat.
Déployer progressivement
Activez pendant une fenêtre surveillée, mesurez cache froid puis chaud et comparez la base. Commencez par un trafic contrôlé si l’architecture le permet.
Conservez l’ancien état et la procédure de retrait. Ne modifiez pas en même temps page cache, base et thème si vous devez attribuer le résultat.
Documentez la version du drop-in et du service.
Ordre recommandé
- Séparer page, objet, navigateur et CDN.
- Mesurer les parcours dynamiques.
- Vérifier le support de l’environnement.
- Tester backend et drop-in sur staging.
- Isoler sites, groupes et environnements.
- Vérifier invalidation et cohérence métier.
- Mesurer hits, latence, mémoire et base.
- Tester la panne et le retrait.
- Déployer progressivement.
- Surveiller et réévaluer le bénéfice.
Les erreurs à éviter
- Croire que
WP_CACHEactive seul la persistance. - Confondre cache de page et cache objet.
- Faire partager les mêmes clés à deux installations.
- Vider tout le backend à chaque mise à jour.
- Utiliser le cache comme stockage primaire.
- Optimiser le hit ratio sans mesurer la latence.
- Relier staging au service de production.
- Publier endpoint, préfixe ou métriques internes.
Checklist cache objet WordPress
- [ ] Le goulot de base est mesuré sur des parcours dynamiques.
- [ ] Le backend et le drop-in sont compatibles.
- [ ] Sites et environnements possèdent des espaces isolés.
- [ ] Les groupes et capacités sont compris.
- [ ] Les transients restent régénérables.
- [ ] Les mises à jour invalident les objets concernés.
- [ ] Hits, mémoire, évictions et erreurs sont surveillés.
- [ ] Les purges sont ciblées autant que possible.
- [ ] Une panne du cache a été testée.
- [ ] Le bénéfice est supérieur au coût d’exploitation.
Conclusion
Le cache objet WordPress aide lorsqu’il évite un travail de base réel sur des parcours qui exécutent WordPress. Sa valeur se prouve par une référence, un test chaud/froid, une invalidation correcte et une exploitation surveillée.
Un cache persistant n’est ni une base ni une promesse de vitesse. Pour relier cette décision à l’ensemble des responsabilités, consultez choisir un hébergement WordPress.
Pour poursuivre cette série éditoriale, consultez également sécuriser wp-config.php sans copier des recettes risquées.