Activer xtremCache (Varnish) chez o2switch

Cet article s’inscrit dans la série “Opti­mi­ser son site avec les outils d’o2switch”.
Après avoir abor­dé LiteS­peed Cache, Redis et Mem­ca­ched, nous allons nous inté­res­ser à xtrem­Cache, l’implémentation Var­nish pro­po­sée par o2switch.

Contrai­re­ment aux outils vus pré­cé­dem­ment, xtrem­Cache n’est pas la solu­tion de cache recom­man­dée par défaut par o2switch.
L’hébergeur recom­mande en prio­ri­té LiteS­peed Cache, plus simple à mettre en place, mieux inté­gré à Word­Press et dis­po­sant d’une exten­sion dédiée per­met­tant un pilo­tage fin sans mani­pu­la­tion serveur.

xtrem­Cache repose sur Var­nish, un cache HTTP très per­for­mant, mais aus­si plus com­plexe à com­prendre et à confi­gu­rer. Il ne dis­pose pas d’extension Word­Press, est par­ti­cu­liè­re­ment sen­sible aux cookies et s’appuie stric­te­ment sur les en-têtes HTTP, qui doivent être défi­nis manuel­le­ment, le plus sou­vent via le fichier .htaccess.

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

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

xtrem­Cache est un cache HTTP ser­veur, basé sur Var­nish.
Il fonc­tionne comme un reverse proxy, pla­cé entre le visi­teur et votre site web. Son rôle est de ser­vir direc­te­ment des pages HTML déjà géné­rées, sans sol­li­ci­ter PHP ni la base de données.

Contrai­re­ment à LiteS­peed Cache, qui s’intègre au fonc­tion­ne­ment interne de Word­Press, Var­nish est tota­le­ment indé­pen­dant du CMS. Il ne “connaît” ni Word­Press, ni ses uti­li­sa­teurs, ni ses règles internes. Il se base uni­que­ment sur :

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

C’est ce qui fait sa force, mais aus­si sa com­plexi­té.
Là où LiteS­peed Cache “com­prend” Word­Press, Var­nish applique stric­te­ment les règles qu’on lui donne.

Pour bien com­prendre les dif­fé­rents types de cache, vous pou­vez lire l’ar­ticle : Tout savoir sur le cache : les dif­fé­rents caches, com­ment les vider

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

xtrem­Cache repose sur Var­nish, un cache HTTP très per­for­mant, mais qui applique des règles strictes. Il n’est donc pas adap­té à tous les pro­jets WordPress.

Cas où xtremCache peut être pertinent

• sites majo­ri­tai­re­ment publics ;
• sites vitrines ou éditoriaux ;
• sites d’actualités avec un fort volume de pages consultées ;
• pro­jets où le conte­nu est iden­tique pour tous les visiteurs ;
• besoins de cache HTTP très agres­sif côté serveur.

Dans ces contextes, Var­nish peut appor­ter des gains signi­fi­ca­tifs en temps de réponse et en charge serveur.

Cas où xtremCache est peu adapté

• sites e‑commerce ;
• sites avec espace membre ou conte­nu personnalisé ;
• sites repo­sant for­te­ment sur des cookies ;
• Word­Press très dyna­mique ou for­te­ment extensible.

Dans ces situa­tions, les contraintes liées aux cookies et aux en-têtes HTTP peuvent limi­ter for­te­ment l’efficacité du cache, voire empê­cher toute mise en cache réelle.

Le positionnement recommandé sur o2switch

Sur un héber­ge­ment o2switch, LiteS­peed Cache reste la solu­tion recom­man­dée par défaut.
Elle est plus simple à confi­gu­rer, mieux inté­grée à Word­Press et suf­fi­sante dans la grande majo­ri­té des cas.

xtrem­Cache doit donc être envi­sa­gé comme une solu­tion ciblée, pour des besoins pré­cis et bien iden­ti­fiés, et non comme un rem­pla­ce­ment sys­té­ma­tique de LiteS­peed Cache.

3. Activer xtremCache (Varnish) chez o2switch

L’activation de xtrem­Cache se fait direc­te­ment depuis le cPa­nel o2switch.
Il s’agit d’un méca­nisme de cache HTTP côté ser­veur, tota­le­ment indé­pen­dant de WordPress.

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

xtrem­Cache ne s’applique pas aux sous-domaines.
Le cache Var­nish fonc­tionne uni­que­ment sur le domaine prin­ci­pal concerné.

Les sous-domaines (par exemple blog.exemple.com, preprod.exemple.com, etc.) ne béné­fi­cient donc pas de xtrem­Cache, même si le domaine prin­ci­pal est cor­rec­te­ment confi­gu­ré.
C’est un point essen­tiel à prendre en compte lors du choix de cette solu­tion de cache.

Choix du template de cache

Lors de l’activation, xtrem­Cache pro­pose plu­sieurs tem­plates de cache, adap­tés aux prin­ci­paux types d’applications :

• Word­Press ;
• Cache des fichiers sta­tiques uniquement ;
• Appli­ca­tion Symfony ;
• Joom­la ;
• Appli­ca­tion PHP générique ;
• Pres­ta­Shop.

Dans la majo­ri­té des cas, Word­Press est détec­té auto­ma­ti­que­ment et le tem­plate cor­res­pon­dant est sélec­tion­né. Si ce n’est pas le cas, il est pos­sible de choi­sir manuel­le­ment le tem­plate le plus adap­té au site.

Chaque tem­plate four­nit une base de confi­gu­ra­tion, mais ne rem­place pas une ana­lyse fine du fonc­tion­ne­ment du site, notam­ment en ce qui concerne les en-têtes HTTP et les cookies.

Options de personnalisation disponibles

L’outil xtrem­Cache pro­pose un menu Options de per­son­na­li­sa­tion, per­met­tant d’agir sur le com­por­te­ment du cache côté serveur.

Cer­taines options his­to­riques sont aujourd’hui dépré­ciées et ne consti­tuent plus la méthode recom­man­dée pour gérer le cache avec Word­Press. C’est notam­ment le cas des options visant à igno­rer auto­ma­ti­que­ment cer­tains élé­ments côté interface.

La ges­tion fine du cache HTTP, en par­ti­cu­lier en pré­sence de cookies, doit désor­mais être réa­li­sée via les règles HTTP, prin­ci­pa­le­ment dans le fichier .htaccess.

Dans la suite de cet article, nous nous concen­tre­rons donc sur les méthodes recom­man­dées, basées sur les en-têtes HTTP et le com­por­te­ment réel des requêtes, plu­tôt que sur des options gra­phiques appe­lées à disparaître.

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

Avec xtrem­Cache, tout repose sur les en-têtes HTTP.
Var­nish ne “devine” rien : il applique stric­te­ment ce que le ser­veur 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é ;
• com­bien de temps la page peut être conservée ;
• dans quels cas le cache doit être ignoré.

Sans direc­tives expli­cites, Var­nish adopte un com­por­te­ment conser­va­teur et met peu, voire rien, en cache.

Les en-têtes les plus importants

Sans entrer dans des confi­gu­ra­tions avan­cées, cer­tains hea­ders sont incontournables.

Cache-Control
C’est l’en-tête prin­ci­pal. Il per­met notam­ment de définir :

• public ou private ;
• une durée de vie (max-age) ;
• des exclu­sions expli­cites (no-cache, no-store).

Expires
Il indique une date d’expiration du conte­nu.
Il est aujourd’hui sou­vent secon­daire par rap­port à Cache-Control, mais reste pris en compte.

Prag­ma
Ancien hea­der, encore pré­sent dans cer­tains contextes, qui peut blo­quer 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éser­vée au navi­ga­teur du visi­teur et ne doit pas être sto­ckée côté serveur.

Un simple private mal pla­cé suf­fit à rendre xtrem­Cache inefficace.

Où ces headers sont définis

Dans le cas de xtrem­Cache chez o2switch, les en-têtes HTTP ne sont pas géné­rés auto­ma­ti­que­ment par Word­Press pour Varnish.

Ils sont géné­ra­le­ment définis :

• via le fichier .htaccess ;
• par­fois via la confi­gu­ra­tion serveur ;
• ou indi­rec­te­ment par cer­taines extensions.

C’est ce point qui rend l’outil plus déli­cat à uti­li­ser que LiteS­peed Cache.

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

À lire avant d’aller plus loin : le bloc ci-des­sous est four­ni à titre d’exemple péda­go­gique.
Il illustre la manière dont des en-têtes HTTP peuvent être décla­rés pour être exploi­tés par Var­nish. Il ne s’agit pas d’une confi­gu­ra­tion uni­ver­selle ni d’une recom­man­da­tion à appli­quer telle quelle sur un site Word­Press en pro­duc­tion. Chaque site ayant ses propres contraintes (exten­sions, cookies, conte­nu dyna­mique), les règles de cache doivent tou­jours être adap­tées et testées.

Ce type de décla­ra­tion doit être pla­cé 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 :

• dis­tin­guer conte­nu public et conte­nu sensible ;
• expli­ci­ter ce qui peut être mis en cache ;
• évi­ter toute ambi­guï­té pour Varnish.

Même avec des en-têtes HTTP cor­rec­te­ment défi­nis, 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 Var­nish, la pré­sence de cookies est sou­vent le prin­ci­pal fac­teur blo­quant pour la mise en cache des pages. Par défaut, lorsqu’un cookie est détec­té, Var­nish consi­dère que le conte­nu peut être per­son­na­li­sé et évite donc de le mettre en cache.

Ce com­por­te­ment est sain d’un point de vue tech­nique, mais il peut for­te­ment limi­ter l’efficacité du cache avec Word­Press, où de nom­breux cookies sont pré­sents même pour des visi­teurs non connectés.

À propos de l’option « Ignorer les cookies »

L’option « Igno­rer les cookies » pro­po­sée dans xtrem­Cache est aujourd’hui dépré­ciée, comme indi­qué dans la docu­men­ta­tion offi­cielle o2switch. Elle ne doit plus être uti­li­sée comme méthode prin­ci­pale pour gérer le cache avec WordPress.

La ges­tion du cache vis-à-vis des cookies doit désor­mais être réa­li­sée via les règles HTTP, prin­ci­pa­le­ment à l’aide des en-têtes Cache-Control, défi­nis dans le fichier .htaccess.

La logique recommandée avec WordPress

Plu­tôt que de cher­cher à lis­ter tous les cookies pou­vant être “accep­tés”, l’approche recom­man­dée consiste à faire l’inverse :

• auto­ri­ser le cache par défaut pour les pages publiques ;
• désac­ti­ver expli­ci­te­ment le cache lorsqu’un cookie réel­le­ment blo­quant est présent.

Les cookies réel­le­ment blo­quants sont ceux qui indiquent :

• un uti­li­sa­teur connecté ;
• une ses­sion d’administration ;
• un contexte néces­si­tant un affi­chage personnalisé.

Les cookies de consen­te­ment (RGPD), de mesure d’audience ou de pré­fé­rences n’impactent géné­ra­le­ment pas le conte­nu HTML affi­ché et n’ont donc pas voca­tion à blo­quer le cache HTTP.

Exemple : adapter le cache HTTP en fonction des cookies WordPress

Impor­tant : l’exemple ci-des­sous est four­ni à titre péda­go­gique.
Il illustre la logique recom­man­dée pour Word­Press avec Var­nish sur o2switch. Il doit tou­jours être adap­té et tes­té selon le contexte du site.

Ce type de règles doit être pla­cé 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 com­plète celui pré­sen­té pré­cé­dem­ment en se concen­trant spé­ci­fi­que­ment sur la ges­tion des cookies Word­Press et montre comment :

• auto­ri­ser le cache pour les pages publiques ;
• désac­ti­ver le cache en pré­sence de cookies Word­Press réel­le­ment bloquants ;
• lais­ser pas­ser sans impact les cookies de consen­te­ment ou de mesure d’audience.

Une approche prudente indispensable

Une mau­vaise ges­tion des cookies peut entraîner :

• l’affichage de conte­nu incorrect ;
• des inco­hé­rences entre visiteurs ;
• des pro­blèmes fonc­tion­nels sur le site.

Il est donc essen­tiel de :

• com­prendre le rôle des cookies présents ;
• tes­ter sys­té­ma­ti­que­ment le com­por­te­ment du site dans un navi­ga­teur réel ;
• pro­cé­der par ajus­te­ments progressifs.

6. Vérifier le fonctionnement du cache xtremCache

Une fois xtrem­Cache acti­vé et les règles de cache en place, il est indis­pen­sable de véri­fier que le cache fonc­tionne réel­le­ment. Plu­sieurs outils per­mettent de le faire, mais ils n’ont pas tous la même por­tée ni la même fiabilité.

L’outil de vérification dans le cPanel o2switch

o2switch met à dis­po­si­tion un outil de véri­fi­ca­tion direc­te­ment acces­sible depuis le cPa­nel.
Cet outil per­met de confir­mer que xtrem­Cache est bien actif et opé­ra­tion­nel côté ser­veur. Il effec­tue deux requêtes suc­ces­sives sur la page testée :

• une pre­mière requête afin que la page puisse être mise en cache ;
• une seconde requête pour véri­fier si la réponse peut être ser­vie depuis le cache.

Le for­mu­laire de test per­met de choisir :

• le pro­to­cole (HTTP ou HTTPS) ;
• la ver­sion du domaine (avec ou sans www) ;
• l’URL à tes­ter.
  Si ce champ est lais­sé vide, la page d’accueil est utilisée.

Le rap­port géné­ré indique notamment :

• si la page a été ser­vie depuis le cache ou non ;
• les en-têtes HTTP ren­voyés par le serveur.

Cet outil est par­ti­cu­liè­re­ment utile pour vali­der que le méca­nisme de cache est actif, mais il ne reflète pas le com­por­te­ment d’un navi­ga­teur réel.

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

Il est éga­le­ment pos­sible de contrô­ler les hea­ders HTTP direc­te­ment depuis la ligne de commande :

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

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

Cette méthode per­met de vérifier :

• la pré­sence de l’en-tête Cache-Control ;
• les valeurs asso­ciées (public, max-age, etc.) ;
• l’absence de direc­tives blo­quantes sur les pages publiques.

Comme l’outil du cPa­nel, cette véri­fi­ca­tion reste théo­rique. Elle ne tient pas compte du contexte réel d’un visi­teur (cookies, ses­sion, user-agent).

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

Pour savoir si une page est réel­le­ment ser­vie depuis le cache pour un visi­teur, l’inspection dans le navi­ga­teur reste la méthode la plus fiable. À l’aide des outils de déve­lop­pe­ment du navigateur :

• ouvrir l’onglet Réseau ;
• rechar­ger la page ;
• sélec­tion­ner la requête HTML prin­ci­pale (la pre­mière en haut de page) ;
• ana­ly­ser les en-têtes de réponse.

C’est dans ce contexte que l’on peut véri­fier si la page est ser­vie en HIT ou en MISS, et obser­ver le com­por­te­ment réel du cache en pré­sence de cookies et d’un contexte uti­li­sa­teur complet.

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

Un cache peut être :

• actif côté serveur ;
• cor­rec­te­ment confi­gu­ré en apparence ;
• mais peu ou pas uti­li­sé dans un navi­ga­teur réel.

C’est pour­quoi il est impor­tant de croi­ser les méthodes de véri­fi­ca­tion et de ne pas tirer de conclu­sion uni­que­ment à par­tir d’un test ser­veur ou d’une com­mande curl.

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

Mal­gré une acti­va­tion cor­recte, xtrem­Cache peut ne pas pro­duire les effets atten­dus. Dans la majo­ri­té des cas, les pro­blèmes ren­con­tré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 pos­sibles :

• pré­sence de cookies non ignorés ;
• en-tête Cache-Control trop res­tric­tif (private, no-cache, no-store) ;
• règles de cache inexis­tantes ou mal posi­tion­nées dans le fichier .htaccess ;
• page trop dyna­mique ou personnalisée.

Véri­fi­ca­tions à effectuer :

• ins­pec­ter la page dans le navigateur ;
• iden­ti­fier les cookies envoyés ;
• ajus­ter pro­gres­si­ve­ment les règles de cache et les en-têtes HTTP, notam­ment en lien avec les cookies.

Des pages sensibles sont mises en cache par erreur

Cela peut arri­ver si :

• des cookies cri­tiques ont été ignorés ;
• des règles de cache trop glo­bales ont été appliquées ;
• le cache a été for­cé en igno­rant les en-têtes HTTP.

Consé­quences possibles :

• affi­chage de conte­nu incorrect ;
• pro­blèmes de connexion ou de navigation ;
• inco­hé­rences entre visiteurs.

Bonnes pra­tiques :

• ne jamais igno­rer les cookies de ses­sion ou d’authentification ;
• évi­ter l’option « For­cer le cache » sur WordPress ;
• tes­ter sys­té­ma­ti­que­ment les pages sen­sibles (connexion, for­mu­laires, tun­nel e‑commerce).

Conclusion

xtrem­Cache (Var­nish) est un outil de cache HTTP puis­sant, mais exi­geant. Contrai­re­ment à LiteS­peed Cache, il ne s’intègre pas à Word­Press et repose exclu­si­ve­ment sur les en-têtes HTTP et la ges­tion des cookies.

Sur un héber­ge­ment o2switch, il ne consti­tue pas la solu­tion de cache recom­man­dée par défaut. LiteS­peed Cache reste, dans la majo­ri­té des cas, plus simple à mettre en place et suf­fi­sam­ment per­for­mant pour un site WordPress.

xtrem­Cache peut néan­moins être per­ti­nent dans des contextes bien iden­ti­fiés, à condi­tion d’en com­prendre les limites, de pro­cé­der avec méthode et de tes­ter sys­té­ma­ti­que­ment son fonc­tion­ne­ment dans des condi­tions réelles de navigation.