Qu'est-ce que la mise en cache dans WordPress ?

La mise en cache stocke une copie du contenu généré afin qu'il puisse être servi plus rapidement lors de requêtes suivantes, sans avoir à le régénérer entièrement. Pour WordPress, cela signifie sauter l'exécution PHP et les requêtes de base de données pour les affichages répétés de pages. Une page WordPress qui prend 800 ms à générer de zéro peut être servie en moins de 50 ms lorsqu'elle est mise en cache. La mise en cache est l'une des optimisations les plus impactantes que vous puissiez faire pour tout site WordPress.

Les cinq types de mise en cache WordPress

La mise en cache dans WordPress n'est pas une chose unique. Il existe cinq couches distinctes, chacune fonctionnant à un point différent du cycle de requête. Comprendre ce que fait chacune vous aide à choisir la bonne stratégie de cache pour votre site.

Cache du navigateur

Le cache du navigateur est la première couche et fonctionne entièrement sur l'appareil du visiteur. Lorsqu'un navigateur télécharge un fichier CSS, une image ou un fichier JavaScript, il en stocke une copie locale. Au prochain chargement de page, le navigateur vérifie si la copie en cache est toujours valide (selon les en-têtes Cache-Control, Expires et ETag) et saute le téléchargement entièrement si c'est le cas. Cela élimine les requêtes réseau et rend les affichages de pages suivants quasi instantanés pour les visiteurs récurrents.

Vous contrôlez le cache du navigateur via les en-têtes de réponse HTTP. Les plus importants sont :

• Cache-Control: max-age=31536000 : Indique au navigateur de mettre le fichier en cache pendant un an (31 536 000 secondes). Utilisé pour les ressources statiques versionnées qui obtiennent un nouveau nom de fichier lorsqu'elles changent.
• Cache-Control: no-cache : Le navigateur doit vérifier auprès du serveur avant d'utiliser la copie en cache. Le serveur peut répondre avec « 304 Not Modified » si le fichier n'a pas changé, ce qui économise de la bande passante.
• Cache-Control: no-store : Le navigateur ne doit jamais mettre cette réponse en cache. Utilisé pour le contenu sensible ou hautement dynamique.

Cache de page

Le cache de page est le plus grand gain de performance pour la plupart des sites WordPress. Voici le problème qu'il résout : à chaque requête de page, WordPress charge son noyau, initialise la connexion à la base de données, exécute des dizaines de requêtes de base de données, traite les hooks d'extensions et rend les modèles de thème. Ce cycle PHP/MySQL prend de 200 ms à plusieurs secondes selon votre serveur et la complexité de votre site. Il produit la même sortie HTML pour chaque visiteur anonyme.

Un cache de page stocke cette sortie HTML après la première requête. Lorsque le visiteur suivant demande la même page, le fichier HTML mis en cache est servi directement par le serveur web (ou même par un proxy inverse devant lui), contournant complètement WordPress, PHP et la base de données. La différence est spectaculaire. Au lieu d'exécuter 50-200 requêtes de base de données et des milliers de lignes de PHP, le serveur lit simplement un fichier et l'envoie.

Cache d'objets

Le cache d'objets se situe entre WordPress et la base de données. WordPress interroge fréquemment les mêmes données de manière répétée au sein d'un seul chargement de page et entre les chargements de pages : options, métadonnées utilisateur, données d'articles, transients. Le cache d'objets stocke ces résultats de requêtes en mémoire (en utilisant Redis ou Memcached) afin qu'ils ne sollicitent pas la base de données à chaque fois.

WordPress dispose d'un cache d'objets intégré, mais par défaut il ne fonctionne qu'au sein d'une seule requête (il ne persiste pas entre les requêtes). Pour obtenir un cache d'objets persistant, vous avez besoin d'une extension drop-in qui connecte WordPress à Redis ou Memcached. Les options populaires incluent Redis Object Cache et Object Cache Pro.

Le cache d'objets est particulièrement précieux pour les sites qui ne peuvent pas utiliser de cache de page complet, comme les boutiques WooCommerce avec du contenu personnalisé, les sites d'adhésion ou les forums où le contenu change fréquemment.

Cache d'opcode (OPcache)

Chaque fois que PHP traite un script, il compile d'abord le code PHP lisible par l'humain en bytecode (instructions lisibles par la machine). Cette étape de compilation est répétée à chaque requête sauf si le cache d'opcode est activé. L'extension OPcache intégrée à PHP stocke le bytecode compilé en mémoire partagée, éliminant l'étape de compilation pour les requêtes suivantes.

OPcache est un paramètre au niveau du serveur, pas quelque chose que vous configurez via WordPress. La plupart des environnements d'hébergement modernes ont OPcache activé par défaut. Vous pouvez le vérifier en consultant votre configuration PHP (phpinfo) ou en demandant à votre hébergeur. OPcache à lui seul peut améliorer la vitesse d'exécution de PHP de 30 à 50 %.

Cache CDN

Un CDN (Content Delivery Network) met en cache vos ressources statiques sur des serveurs périphériques répartis dans le monde entier. Lorsqu'un visiteur à Tokyo demande une image de votre site WordPress hébergé à Amsterdam, le CDN la sert depuis un serveur périphérique proche au lieu d'acheminer la requête jusqu'à Amsterdam. Cela réduit considérablement la latence pour les ressources statiques. Certains fournisseurs de CDN comme Cloudflare proposent également la mise en cache de pages complètes pour WordPress via leur fonctionnalité APO. Pour plus de détails, consultez notre article sur les Content Delivery Networks.

Comment fonctionne le cache de page étape par étape

Puisque le cache de page a le plus grand impact, voici un examen plus détaillé de son fonctionnement en pratique :

1. Un visiteur demande votredomaine.com/about/ pour la première fois.
2. WordPress traite la requête normalement : PHP s'exécute, la base de données est interrogée, le modèle du thème est rendu et le HTML est généré.
3. L'extension de cache enregistre une copie du HTML finalisé sur le système de fichiers (typiquement dans wp-content/cache/) ou en mémoire.
4. Un second visiteur demande votredomaine.com/about/.
5. L'extension de cache intercepte la requête avant le chargement de WordPress. Elle trouve le fichier HTML en cache et le sert directement. PHP s'exécute à peine, et la base de données n'est pas sollicitée.
6. Lorsque le contenu de la page change (un article est mis à jour, un commentaire est approuvé), le cache pour cette page spécifique est invalidé, et la requête suivante génère une nouvelle copie.

Comparaison des extensions de cache WordPress populaires

Il existe de nombreuses extensions de cache disponibles pour WordPress. Voici les plus largement utilisées et comment elles se comparent :

• WP Rocket : Une extension premium (à partir de 59 $/an) largement considérée comme la solution de cache la plus conviviale. Elle active le cache de page, le cache du navigateur, la compression GZIP et le lazy loading dès l'installation avec une configuration minimale. WP Rocket gère également la minification CSS/JS, l'optimisation de la base de données et s'intègre à Cloudflare pour la purge du cache CDN. C'est le meilleur choix pour les propriétaires de sites qui veulent d'excellentes performances sans passer des heures sur la configuration.
• W3 Total Cache : Une extension gratuite avec une énorme gamme de fonctionnalités. Elle prend en charge le cache de page, le cache d'objets (Redis, Memcached, APCu), le cache du navigateur, l'intégration CDN et la minification. L'inconvénient est la complexité. W3 Total Cache a des dizaines de pages de paramètres, et une mauvaise configuration peut casser votre site. Elle est puissante mais mieux adaptée aux développeurs ou utilisateurs avancés.
• WP Super Cache : Une extension gratuite développée par Automattic (l'entreprise derrière WordPress.com). Elle se concentre sur le cache de page et garde les choses simples. WP Super Cache génère des fichiers HTML statiques et peut les servir en utilisant des règles mod_rewrite, ce qui est très rapide. Elle manque des fonctionnalités avancées de WP Rocket et W3 Total Cache mais est fiable et facile à configurer.
• LiteSpeed Cache : Une extension gratuite qui offre des performances exceptionnelles lorsqu'elle est utilisée avec des serveurs web LiteSpeed. Elle prend en charge le cache de page, le cache d'objets, l'optimisation d'images, la minification CSS/JS et l'intégration CDN. Si votre hébergement utilise LiteSpeed (de nombreux hébergements mutualisés le font), cette extension tire parti de la mise en cache au niveau serveur, plus rapide que la mise en cache basée sur PHP. Elle fonctionne aussi sur Apache et Nginx mais avec des fonctionnalités réduites.

Solutions de mise en cache au niveau serveur

Au-delà des extensions WordPress, la mise en cache peut aussi se produire au niveau du serveur, ce qui est souvent plus rapide car elle intercepte les requêtes avant même que PHP ne soit impliqué :

• Varnish : Un cache proxy inverse qui se place devant votre serveur web. Varnish stocke les réponses de pages complètes en mémoire et les sert directement pour les requêtes mises en cache. Il est extrêmement rapide (temps de réponse sous la milliseconde) et utilisé par les sites WordPress à fort trafic. La configuration nécessite VCL (Varnish Configuration Language), qui demande un apprentissage.
• Nginx FastCGI Cache : Si votre serveur utilise Nginx (ce que beaucoup d'hébergeurs WordPress modernes font), la mise en cache FastCGI stocke la sortie PHP complète et la sert directement depuis Nginx pour les requêtes suivantes. C'est plus rapide que toute extension de cache basée sur PHP car Nginx gère la requête entièrement sans invoquer PHP. De nombreux hébergeurs WordPress infogérés (Kinsta, GridPane, SpinupWP) utilisent cette approche.
• Cache de page complète Redis : Certaines configurations utilisent Redis non seulement pour le cache d'objets mais aussi pour le cache de pages complètes. Le HTML mis en cache est stocké dans la mémoire Redis, et un petit script PHP ou un module Nginx le sert directement. Cela combine la vitesse du stockage en mémoire avec la flexibilité de l'invalidation de cache basée sur des clés.

Cache d'objets avec Redis et Memcached

Pour les sites WordPress qui gèrent de lourdes charges de base de données, le cache d'objets persistant peut être transformateur. Voici comment les deux principales options se comparent :

• Redis : Le choix le plus populaire pour WordPress. Redis stocke les données en mémoire et prend en charge des types de données complexes (chaînes, hashes, listes, ensembles). Il peut persister les données sur disque, prend en charge la réplication et peut être utilisé à la fois pour le cache d'objets et le stockage de sessions. L'extension Redis Object Cache est le moyen le plus courant de connecter WordPress à Redis.
• Memcached : Un système de mise en cache en mémoire plus ancien et plus simple. Memcached est rapide et léger mais manque de la persistance des données et des fonctionnalités avancées de Redis. Il est encore utilisé dans certains environnements d'hébergement, en particulier les plus anciens.

Le cache d'objets persistant fait la plus grande différence sur les sites avec des requêtes complexes : boutiques WooCommerce avec des milliers de produits, communautés BuddyPress, réseaux multisite, ou tout site où le tableau de bord d'administration WordPress semble lent.

Quand le cache cause des problèmes

La mise en cache n'est pas toujours simple. Il existe des situations où une mise en cache agressive crée des problèmes :

• Utilisateurs connectés : Le cache de page ne doit pas servir des pages mises en cache aux utilisateurs connectés, car chaque utilisateur voit un contenu différent (son nom dans l'en-tête, la barre d'administration, le tableau de bord personnel). Toutes les principales extensions de cache gèrent cela correctement par défaut, mais les implémentations personnalisées se trompent parfois.
• WooCommerce et e-commerce : Les paniers d'achat, les pages de paiement et les pages « mon compte » sont dynamiques et spécifiques à l'utilisateur. Elles doivent être exclues du cache de page. WP Rocket et LiteSpeed Cache excluent automatiquement les pages WooCommerce. Avec d'autres extensions, vous pourriez devoir configurer les exclusions manuellement.
• Contenu dynamique et AJAX : Si votre site dépend fortement de contenu chargé par AJAX, de données en temps réel ou d'éléments personnalisés (produits récemment vus, recommandations spécifiques à l'utilisateur), le cache de page complète peut servir du contenu obsolète. Les solutions incluent le cache fragmenté (mise en cache de tout sauf des parties dynamiques) ou le chargement de contenu dynamique via JavaScript après le chargement de la page mise en cache.
• Sites d'adhésion : Les sites avec plusieurs niveaux d'adhésion affichent un contenu différent à différents groupes d'utilisateurs. Le cache de page doit tenir compte de ces variations, soit en sautant le cache pour les utilisateurs connectés, soit en maintenant des versions mises en cache séparées par rôle d'utilisateur (ce que la plupart des extensions ne prennent pas en charge).
• Formulaires et nonces : WordPress utilise des nonces (jetons à usage unique) pour la sécurité dans les formulaires. Si une page avec un formulaire est mise en cache, tous les visiteurs obtiennent le même nonce, qui peut expirer et causer des erreurs de soumission de formulaire. Les extensions de cache gèrent généralement cela, mais c'est une source courante de problèmes avec les formulaires personnalisés.

Invalidation du cache : la partie difficile

Il y a un dicton célèbre en informatique : « Il n'y a que deux choses difficiles en informatique : l'invalidation du cache et nommer les choses. » L'invalidation du cache est le processus de suppression ou de mise à jour du contenu en cache lorsque les données sous-jacentes changent. Dans WordPress, cela signifie :

• Lorsque vous publiez ou mettez à jour un article, le cache de cet article, de ses archives de catégorie, de ses archives de tag, de la page d'accueil et de toute page affichant les articles récents devrait être effacé.
• Lorsque vous modifiez les paramètres du thème, l'ensemble du cache de page devrait être effacé car chaque page peut sembler différente.
• Lorsqu'un nouveau commentaire est approuvé, la version mise en cache de cet article devrait être mise à jour pour afficher le nouveau commentaire.

Les bonnes extensions de cache gèrent automatiquement la plupart de ces scénarios via des hooks WordPress. Elles écoutent les événements comme save_post, switch_theme et wp_update_comment_count et effacent les entrées de cache pertinentes. Cependant, si vous avez du code personnalisé qui modifie le contenu sans passer par les fonctions standard de WordPress, le cache peut ne pas être invalidé correctement.

En cas de doute, la plupart des extensions de cache fournissent un bouton « Purger tout le cache » dans la barre d'administration WordPress. Utilisez-le après avoir effectué des changements significatifs si les pages mises en cache ne reflètent pas vos mises à jour.

Ce que vérifie InspectWP

InspectWP détecte si une extension de cache WordPress est active en recherchant des commentaires HTML liés au cache (de nombreuses extensions insèrent un commentaire comme <!-- Cached by WP Rocket --> en bas de la page), des en-têtes de réponse (comme X-Cache, X-Cache-Enabled ou X-LiteSpeed-Cache) et des signatures d'extensions connues dans le code source de la page. Le rapport identifie quelle extension de cache est utilisée, afin que vous puissiez vérifier que votre configuration de cache fonctionne correctement. Si aucun cache n'est détecté, InspectWP signale cela comme une opportunité d'amélioration des performances, puisque la mise en cache est l'un des moyens les plus efficaces d'accélérer tout site WordPress.