Activer xtremCache (Varnish) chez o2switch

Cet article s’inscrit dans la série “Optimiser son site avec les outils d’o2switch”.
Après avoir abordé LiteSpeed Cache, Redis et Memcached, nous allons nous intéresser à xtremCache, l’implémentation Varnish proposée par o2switch.

Contrairement aux outils vus précédemment, xtremCache n’est pas la solution de cache recommandée par défaut par o2switch.
L’hébergeur recommande en priorité LiteSpeed Cache, plus simple à mettre en place, mieux intégré à WordPress et disposant d’une extension dédiée permettant un pilotage fin sans manipulation serveur.

xtremCache repose sur Varnish, un cache HTTP très performant, mais aussi plus complexe à comprendre et à configurer. Il ne dispose pas d’extension WordPress, est particulièrement sensible aux cookies et s’appuie strictement sur les en-têtes HTTP, qui doivent être définis manuellement, le plus souvent via le fichier .htaccess.

Cet outil s’adresse donc à un public averti, qui maîtrise déjà les bases du cache et souhaite aller plus loin, dans des cas bien précis.

1. Qu’est-ce que xtremCache (Varnish) ?

xtremCache est un cache HTTP serveur, basé sur Varnish.
Il fonctionne comme un reverse proxy, placé entre le visiteur et votre site web. Son rôle est de servir directement des pages HTML déjà générées, sans solliciter PHP ni la base de données.

Contrairement à LiteSpeed Cache, qui s’intègre au fonctionnement interne de WordPress, Varnish est totalement indépendant du CMS. Il ne “connaît” ni WordPress, ni ses utilisateurs, ni ses règles internes. Il se base uniquement sur :

• les URL ;
• les en-têtes HTTP ;
• la présence ou non de cookies.

C’est ce qui fait sa force, mais aussi sa complexité.
Là où LiteSpeed Cache “comprend” WordPress, Varnish applique strictement les règles qu’on lui donne.

Pour bien comprendre les différents types de cache, vous pouvez lire l’article : Tout savoir sur le cache : les différents caches, comment les vider

2. Dans quels cas xtremCache est pertinent (et ses limites)

xtremCache repose sur Varnish, un cache HTTP très performant, mais qui applique des règles strictes. Il n’est donc pas adapté à tous les projets WordPress.

Cas où xtremCache peut être pertinent

• sites majoritairement publics ;
• sites vitrines ou éditoriaux ;
• sites d’actualités avec un fort volume de pages consultées ;
• projets où le contenu est identique pour tous les visiteurs ;
• besoins de cache HTTP très agressif côté serveur.

Dans ces contextes, Varnish peut apporter des gains significatifs en temps de réponse et en charge serveur.

Cas où xtremCache est peu adapté

• sites e-commerce ;
• sites avec espace membre ou contenu personnalisé ;
• sites reposant fortement sur des cookies ;
• WordPress très dynamique ou fortement extensible.

Dans ces situations, les contraintes liées aux cookies et aux en-têtes HTTP peuvent limiter fortement l’efficacité du cache, voire empêcher toute mise en cache réelle.

Le positionnement recommandé sur o2switch

Sur un hébergement o2switch, LiteSpeed Cache reste la solution recommandée par défaut.
Elle est plus simple à configurer, mieux intégrée à WordPress et suffisante dans la grande majorité des cas.

xtremCache doit donc être envisagé comme une solution ciblée, pour des besoins précis et bien identifiés, et non comme un remplacement systématique de LiteSpeed Cache.

3. Activer xtremCache (Varnish) chez o2switch

L’activation de xtremCache se fait directement depuis le cPanel o2switch.
Il s’agit d’un mécanisme de cache HTTP côté serveur, totalement indépendant de WordPress.

Périmètre du cache : une limitation importante à connaître

xtremCache ne s’applique pas aux sous-domaines.
Le cache Varnish fonctionne uniquement sur le domaine principal concerné.

Les sous-domaines (par exemple blog.exemple.com, preprod.exemple.com, etc.) ne bénéficient donc pas de xtremCache, même si le domaine principal est correctement configuré.
C’est un point essentiel à prendre en compte lors du choix de cette solution de cache.

Choix du template de cache

Lors de l’activation, xtremCache propose plusieurs templates de cache, adaptés aux principaux types d’applications :

• WordPress ;
• Cache des fichiers statiques uniquement ;
• Application Symfony ;
• Joomla ;
• Application PHP générique ;
• PrestaShop.

Dans la majorité des cas, WordPress est détecté automatiquement et le template correspondant est sélectionné. Si ce n’est pas le cas, il est possible de choisir manuellement le template le plus adapté au site.

Chaque template fournit une base de configuration, mais ne remplace pas une analyse fine du fonctionnement du site, notamment en ce qui concerne les en-têtes HTTP et les cookies.

Options de personnalisation disponibles

L’outil xtremCache propose un menu Options de personnalisation, permettant d’agir sur le comportement du cache côté serveur.

Certaines options historiques sont aujourd’hui dépréciées et ne constituent plus la méthode recommandée pour gérer le cache avec WordPress. C’est notamment le cas des options visant à ignorer automatiquement certains éléments côté interface.

La gestion fine du cache HTTP, en particulier en présence de cookies, doit désormais être réalisée via les règles HTTP, principalement dans le fichier .htaccess.

Dans la suite de cet article, nous nous concentrerons donc sur les méthodes recommandées, basées sur les en-têtes HTTP et le comportement réel des requêtes, plutôt que sur des options graphiques appelées à disparaître.

4. Comprendre le rôle des en-têtes HTTP avec Varnish

Avec xtremCache, tout repose sur les en-têtes HTTP.
Varnish ne “devine” rien : il applique strictement ce que le serveur lui indique dans la réponse.

Pourquoi les headers sont déterminants

Les en-têtes HTTP indiquent à Varnish :

• si une page peut être mise en cache ;
• si le cache est public ou privé ;
• combien de temps la page peut être conservée ;
• dans quels cas le cache doit être ignoré.

Sans directives explicites, Varnish adopte un comportement conservateur et met peu, voire rien, en cache.

Les en-têtes les plus importants

Sans entrer dans des configurations avancées, certains headers sont incontournables.

Cache-Control
C’est l’en-tête principal. Il permet notamment de définir :

• public ou private ;
• une durée de vie (max-age) ;
• des exclusions explicites (no-cache, no-store).

Expires
Il indique une date d’expiration du contenu.
Il est aujourd’hui souvent secondaire par rapport à Cache-Control, mais reste pris en compte.

Pragma
Ancien header, encore présent dans certains contextes, qui peut bloquer la mise en cache s’il est mal utilisé.

Public vs privé : une distinction essentielle

• public : la page peut être mise en cache par un proxy comme Varnish ;
• private : la page est réservée au navigateur du visiteur et ne doit pas être stockée côté serveur.

Un simple private mal placé suffit à rendre xtremCache inefficace.

Où ces headers sont définis

Dans le cas de xtremCache chez o2switch, les en-têtes HTTP ne sont pas générés automatiquement par WordPress pour Varnish.

Ils sont généralement définis :

• via le fichier .htaccess ;
• parfois via la configuration serveur ;
• ou indirectement par certaines extensions.

C’est ce point qui rend l’outil plus délicat à utiliser que LiteSpeed Cache.

Exemple de déclaration d’en-têtes HTTP pour Varnish

À lire avant d’aller plus loin : le bloc ci-dessous est fourni à titre d’exemple pédagogique.
Il illustre la manière dont des en-têtes HTTP peuvent être déclarés pour être exploités par Varnish. Il ne s’agit pas d’une configuration universelle ni d’une recommandation à appliquer telle quelle sur un site WordPress en production. Chaque site ayant ses propres contraintes (extensions, cookies, contenu dynamique), les règles de cache doivent toujours être adaptées et testées.

Ce type de déclaration doit être placé avant la ligne # BEGIN WordPress dans le fichier .htaccess.

# BEGIN Configuration du cache Varnish (exemple)

<IfModule mod_headers.c>

    # Pages publiques : cache 24 heures
    Header always set Cache-Control "public, max-age=86400, s-maxage=86400"

    # Accès à l’administration et à la connexion : pas de cache
    <FilesMatch "wp-login.php">
        Header always set Cache-Control "no-cache, no-store, must-revalidate, max-age=0"
    </FilesMatch>

    <If "%{REQUEST_URI} =~ m#/wp-admin/#">
        Header always set Cache-Control "no-cache, no-store, must-revalidate, max-age=0"
    </If>

    # Fichiers statiques : cache longue durée
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js|woff|woff2|ttf|eot|ico|pdf)$">
        Header always set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>

</IfModule>

# END Configuration du cache Varnish (exemple)

# BEGIN Configuration du cache Varnish (exemple)

<IfModule mod_headers.c>

    # Pages publiques : cache 24 heures
    Header always set Cache-Control "public, max-age=86400, s-maxage=86400"

    # Accès à l’administration et à la connexion : pas de cache
    <FilesMatch "wp-login.php">
        Header always set Cache-Control "no-cache, no-store, must-revalidate, max-age=0"
    </FilesMatch>

    <If "%{REQUEST_URI} =~ m#/wp-admin/#">
        Header always set Cache-Control "no-cache, no-store, must-revalidate, max-age=0"
    </If>

    # Fichiers statiques : cache longue durée
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js|woff|woff2|ttf|eot|ico|pdf)$">
        Header always set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>

</IfModule>

# END Configuration du cache Varnish (exemple)

Ce qui compte ici, ce n’est pas la valeur exacte des durées, mais la logique :

• distinguer contenu public et contenu sensible ;
• expliciter ce qui peut être mis en cache ;
• éviter toute ambiguïté pour Varnish.

Même avec des en-têtes HTTP correctement définis, un autre élément peut empêcher toute mise en cache : la présence de cookies.

5. Cookies et cache : le point le plus délicat avec Varnish

Avec Varnish, la présence de cookies est souvent le principal facteur bloquant pour la mise en cache des pages. Par défaut, lorsqu’un cookie est détecté, Varnish considère que le contenu peut être personnalisé et évite donc de le mettre en cache.

Ce comportement est sain d’un point de vue technique, mais il peut fortement limiter l’efficacité du cache avec WordPress, où de nombreux cookies sont présents même pour des visiteurs non connectés.

À propos de l’option « Ignorer les cookies »

L’option « Ignorer les cookies » proposée dans xtremCache est aujourd’hui dépréciée, comme indiqué dans la documentation officielle o2switch. Elle ne doit plus être utilisée comme méthode principale pour gérer le cache avec WordPress.

La gestion du cache vis-à-vis des cookies doit désormais être réalisée via les règles HTTP, principalement à l’aide des en-têtes Cache-Control, définis dans le fichier .htaccess.

La logique recommandée avec WordPress

Plutôt que de chercher à lister tous les cookies pouvant être “acceptés”, l’approche recommandée consiste à faire l’inverse :

• autoriser le cache par défaut pour les pages publiques ;
• désactiver explicitement le cache lorsqu’un cookie réellement bloquant est présent.

Les cookies réellement bloquants sont ceux qui indiquent :

• un utilisateur connecté ;
• une session d’administration ;
• un contexte nécessitant un affichage personnalisé.

Les cookies de consentement (RGPD), de mesure d’audience ou de préférences n’impactent généralement pas le contenu HTML affiché et n’ont donc pas vocation à bloquer le cache HTTP.

Exemple : adapter le cache HTTP en fonction des cookies WordPress

Important : l’exemple ci-dessous est fourni à titre pédagogique.
Il illustre la logique recommandée pour WordPress avec Varnish sur o2switch. Il doit toujours être adapté et testé selon le contexte du site.

Ce type de règles doit être placé avant la ligne # BEGIN WordPress dans le fichier .htaccess.

# BEGIN Varnish - gestion du cache selon les cookies (exemple WordPress)

<IfModule mod_headers.c>

    # Par défaut : pages publiques cachables
    Header always set Cache-Control "public, max-age=86400"

    # Présence de cookies WordPress critiques : désactivation du cache
    <If "%{HTTP_COOKIE} =~ /(wordpress_logged_in_|wordpress_test_cookie|wp-settings-|wp-settings-time-|wp_lang)/">
        Header always set Cache-Control "private, no-cache, no-store, must-revalidate, max-age=0"
    </If>

    # Pages sensibles : administration et connexion
    <If "%{REQUEST_URI} =~ m#^/wp-(admin|login)\.php#">
        Header always set Cache-Control "private, no-cache, no-store, must-revalidate, max-age=0"
    </If>

</IfModule>

# END Varnish - gestion du cache selon les cookies

# BEGIN Varnish - gestion du cache selon les cookies (exemple WordPress)

<IfModule mod_headers.c>

    # Par défaut : pages publiques cachables
    Header always set Cache-Control "public, max-age=86400"

    # Présence de cookies WordPress critiques : désactivation du cache
    <If "%{HTTP_COOKIE} =~ /(wordpress_logged_in_|wordpress_test_cookie|wp-settings-|wp-settings-time-|wp_lang)/">
        Header always set Cache-Control "private, no-cache, no-store, must-revalidate, max-age=0"
    </If>

    # Pages sensibles : administration et connexion
    <If "%{REQUEST_URI} =~ m#^/wp-(admin|login)\.php#">
        Header always set Cache-Control "private, no-cache, no-store, must-revalidate, max-age=0"
    </If>

</IfModule>

# END Varnish - gestion du cache selon les cookies

Cet exemple complète celui présenté précédemment en se concentrant spécifiquement sur la gestion des cookies WordPress et montre comment :

• autoriser le cache pour les pages publiques ;
• désactiver le cache en présence de cookies WordPress réellement bloquants ;
• laisser passer sans impact les cookies de consentement ou de mesure d’audience.

Une approche prudente indispensable

Une mauvaise gestion des cookies peut entraîner :

• l’affichage de contenu incorrect ;
• des incohérences entre visiteurs ;
• des problèmes fonctionnels sur le site.

Il est donc essentiel de :

• comprendre le rôle des cookies présents ;
• tester systématiquement le comportement du site dans un navigateur réel ;
• procéder par ajustements progressifs.

6. Vérifier le fonctionnement du cache xtremCache

Une fois xtremCache activé et les règles de cache en place, il est indispensable de vérifier que le cache fonctionne réellement. Plusieurs outils permettent de le faire, mais ils n’ont pas tous la même portée ni la même fiabilité.

L’outil de vérification dans le cPanel o2switch

o2switch met à disposition un outil de vérification directement accessible depuis le cPanel.
Cet outil permet de confirmer que xtremCache est bien actif et opérationnel côté serveur. Il effectue deux requêtes successives sur la page testée :

• une première requête afin que la page puisse être mise en cache ;
• une seconde requête pour vérifier si la réponse peut être servie depuis le cache.

Le formulaire de test permet de choisir :

• le protocole (HTTP ou HTTPS) ;
• la version du domaine (avec ou sans www) ;
• l’URL à tester.
  Si ce champ est laissé vide, la page d’accueil est utilisée.

Le rapport généré indique notamment :

• si la page a été servie depuis le cache ou non ;
• les en-têtes HTTP renvoyés par le serveur.

Cet outil est particulièrement utile pour valider que le mécanisme de cache est actif, mais il ne reflète pas le comportement d’un navigateur réel.

Vérifier les en-têtes HTTP avec curl

Il est également possible de contrôler les headers HTTP directement depuis la ligne de commande :

curl -I https://www.exemple.com

curl -I https://www.exemple.com

Cette méthode permet de vérifier :

• la présence de l’en-tête Cache-Control ;
• les valeurs associées (public, max-age, etc.) ;
• l’absence de directives bloquantes sur les pages publiques.

Comme l’outil du cPanel, cette vérification reste théorique. Elle ne tient pas compte du contexte réel d’un visiteur (cookies, session, user-agent).

La méthode la plus fiable : l’inspection dans le navigateur

Pour savoir si une page est réellement servie depuis le cache pour un visiteur, l’inspection dans le navigateur reste la méthode la plus fiable. À l’aide des outils de développement du navigateur :

• ouvrir l’onglet Réseau ;
• recharger la page ;
• sélectionner la requête HTML principale (la première en haut de page) ;
• analyser les en-têtes de réponse.

C’est dans ce contexte que l’on peut vérifier si la page est servie en HIT ou en MISS, et observer le comportement réel du cache en présence de cookies et d’un contexte utilisateur complet.

Ne pas confondre cache actif et cache réellement utilisé

Un cache peut être :

• actif côté serveur ;
• correctement configuré en apparence ;
• mais peu ou pas utilisé dans un navigateur réel.

C’est pourquoi il est important de croiser les méthodes de vérification et de ne pas tirer de conclusion uniquement à partir d’un test serveur ou d’une commande curl.

7. Dépannage : les erreurs les plus fréquentes avec xtremCache

Malgré une activation correcte, xtremCache peut ne pas produire les effets attendus. Dans la majorité des cas, les problèmes rencontrés sont liés à des points précis et récurrents.

Le cache est actif, mais toujours en MISS

C’est le cas le plus fréquent.

Causes possibles :

• présence de cookies non ignorés ;
• en-tête Cache-Control trop restrictif (private, no-cache, no-store) ;
• règles de cache inexistantes ou mal positionnées dans le fichier .htaccess ;
• page trop dynamique ou personnalisée.

Vérifications à effectuer :

• inspecter la page dans le navigateur ;
• identifier les cookies envoyés ;
• ajuster progressivement les règles de cache et les en-têtes HTTP, notamment en lien avec les cookies.

Des pages sensibles sont mises en cache par erreur

Cela peut arriver si :

• des cookies critiques ont été ignorés ;
• des règles de cache trop globales ont été appliquées ;
• le cache a été forcé en ignorant les en-têtes HTTP.

Conséquences possibles :

• affichage de contenu incorrect ;
• problèmes de connexion ou de navigation ;
• incohérences entre visiteurs.

Bonnes pratiques :

• ne jamais ignorer les cookies de session ou d’authentification ;
• éviter l’option « Forcer le cache » sur WordPress ;
• tester systématiquement les pages sensibles (connexion, formulaires, tunnel e-commerce).

Conclusion

xtremCache (Varnish) est un outil de cache HTTP puissant, mais exigeant. Contrairement à LiteSpeed Cache, il ne s’intègre pas à WordPress et repose exclusivement sur les en-têtes HTTP et la gestion des cookies.

Sur un hébergement o2switch, il ne constitue pas la solution de cache recommandée par défaut. LiteSpeed Cache reste, dans la majorité des cas, plus simple à mettre en place et suffisamment performant pour un site WordPress.

xtremCache peut néanmoins être pertinent dans des contextes bien identifiés, à condition d’en comprendre les limites, de procéder avec méthode et de tester systématiquement son fonctionnement dans des conditions réelles de navigation.