Cache de page, cache objet : ce que l'hébergeur fournit déjà
Ou : la meilleure extension de cache est parfois celle qu’on n’installe pas.
La réponse courte : WordPress profite de trois caches côté serveur, et l’hébergeur en fournit souvent deux sans rien demander. OPcache garde en mémoire le code PHP déjà compilé. Le cache objet garde les résultats des requêtes à la base de données d’une page à l’autre, à condition d’être persistant : la documentation de WP_Object_Cache rappelle que, par défaut, le cache objet de WordPress ne l’est pas, et qu’il faut Redis ou Memcached et une extension pour qu’il le devienne. Le cache de page, enfin, sert le HTML complet sans réveiller PHP. Avant d’installer une extension de cache, il faut donc savoir ce que fait déjà l’hébergement de votre WordPress.
La règle pratique tient en une phrase : un seul cache de page, celui que l’hébergeur a prévu quand il en prévoit un, et une extension seulement pour le piloter ou pour combler un manque. Deux caches de page empilés ne vont pas deux fois plus vite ; ils donnent deux endroits à vider après chaque modification, et des visiteurs qui voient l’ancienne version.
Pour qui : un blog ou un site vitrine WordPress qui veut une configuration simple, avec une seule extension de cache côté WordPress.
À partir de : 5,75 € par mois hors TVA, facturés à l’année, pour l’hébergement WordPress Infomaniak, proposé sur son hébergement web (tarif affiché le 12 novembre 2026).
Pour démarrer : commander l’hébergement web Infomaniak, installer WordPress, puis une seule extension de cache de page.
Cache WordPress chez l’hébergeur : qui fournit quoi
| Hébergeur, offre | Cache de page côté serveur | Cache objet | En-tête à lire |
|---|---|---|---|
| o2switch, Cloud. | Varnish et LSCache annoncés, frontaux OpenLiteSpeed | Memcached et Redis | X-LiteSpeed-Cache |
| Hostinger | serveurs LiteSpeed, extension LiteSpeed Cache | LiteSpeed Memcached, offres « Business » et supérieures | X-LiteSpeed-Cache |
| SiteGround | Dynamic Cache, actif par défaut | non relevé | x-proxy-cache |
| Kinsta | cache serveur, puis cache en bordure du CDN | Redis en option, 100 $ par mois et par site | X-Kinsta-Cache |
| Infomaniak, hébergement web | aucun cache serveur sur la fiche de l’offre | Memcache, OPcache, Varnish et Redis listés pour le Serveur Cloud managé | celui de l’extension choisie |
Relevés du 12 novembre 2026 sur les fiches d’offres et documentations officielles.
Le cas LiteSpeed mérite une précision. L’extension LiteSpeed Cache, très répandue, ne met rien en cache n’importe où : sa documentation d’installation prévient que le cache ne fonctionne pas sans serveur LiteSpeed ou sans le CDN QUIC.cloud. Installée chez un hébergeur qui tourne sous Apache ou Nginx, son cache de page reste inactif, quels que soient ses réglages. À l’inverse, chez Hostinger ou o2switch, c’est elle qui pilote le cache du serveur, et une autre extension de cache de page ferait doublon.
OPcache, lui, ne se règle pas dans WordPress. Selon la documentation de PHP, il stocke le bytecode des scripts précompilés en mémoire partagée, ce qui évite de charger et d’analyser les scripts à chaque requête. C’est l’hébergeur qui l’active et le dimensionne ; une extension WordPress ne peut qu’en afficher l’état.
Le cache objet, enfin, est celui qui sert le plus aux sites dynamiques : boutique, espace membre, administration chargée. Il demande un service Redis ou Memcached côté serveur et une extension côté WordPress, qui dépose un fichier object-cache.php dans wp-content. Kinsta le facture 100 dollars hors taxes par mois et par site, quand o2switch le liste dans son offre Cloud. : l’écart tient moins à la technique qu’au modèle, une option facturée à part d’un côté, un service qui partage les quotas du compte mutualisé de l’autre.
Pour vérifier qui sert vos pages, une commande suffit, depuis un navigateur déconnecté de l’administration ou depuis un terminal :
| |
La première réponse affiche souvent miss, la seconde hit si le cache fonctionne. SiteGround documente trois valeurs dans sa page sur le Dynamic Cache : HIT pour une page servie depuis le cache, MISS pour une page générée, BYPASS quand le cache a reçu l’ordre de l’ignorer, par exemple parce que vous êtes connecté. Un BYPASS permanent sur une page publique signale un cookie ou une règle qui désactive le cache à votre insu.
Mesurer WordPress, pas son cache
Une page servie par le cache répond vite même si WordPress est lent derrière elle. Pour savoir ce que coûtent vraiment les extensions, il faut chronométrer la page hors cache, à côté d’un fichier texte et d’un PHP d’une ligne, selon la méthode des trois fichiers pour un WordPress lent.
Le panier, que le cache doit ignorer
WooCommerce demande d’exclure du cache de page le panier, la commande et le compte client, et liste les cookies à respecter. Ce qui reste alors à la charge de PHP fixe le seuil d’une boutique, détaillé dans l’hébergement adapté à WooCommerce.
Le cache préréglé, argument de vente de l’offre « WordPress »
Chez plusieurs hébergeurs, le cache préréglé est l’une des rares différences entre la page WordPress et la page mutualisée, qui vendent sinon la même offre. La comparaison complète se trouve dans l’offre WordPress comparée au mutualisé classique.