Varnish devant WordPress : configuration VCL et purge automatique

Sur un site à fort trafic, à l’audience régulière et au contenu majoritairement identique pour tous les visiteurs, Varnish reste une des solutions de cache les plus efficaces qui soit : il intercepte la requête avant même qu’elle n’atteigne PHP, et sert la réponse directement depuis la mémoire vive. Correctement configuré, il transforme un temps de réponse de plusieurs centaines de millisecondes en quelques millisecondes. Mal configuré, il devient une source de bugs difficiles à diagnostiquer, en particulier autour des cookies de session.

Installation et positionnement dans l’architecture

Varnish se place devant le serveur web (nginx ou Apache), qui lui-même transmet à PHP-FPM. L’architecture typique ressemble à ceci :

Visiteur → Varnish (port 80) → nginx (port 8080) → PHP-FPM → MySQL

Configuration VCL de base pour WordPress

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    # Ne jamais mettre en cache l'admin ni les zones connectées
    if (req.url ~ "^/wp-admin" || req.url ~ "^/wp-login.php") {
        return (pass);
    }

    # Ne jamais mettre en cache si l'utilisateur a un cookie de connexion
    if (req.http.Cookie ~ "wordpress_logged_in") {
        return (pass);
    }

    # Retirer les cookies inutiles pour les visiteurs anonymes
    if (req.http.Cookie !~ "wordpress_logged_in") {
        unset req.http.Cookie;
    }

    return (hash);
}

Le piège classique : les cookies mal exclus

Le problème le plus fréquent avec Varnish devant WordPress n’est pas la configuration du backend, mais la gestion des cookies. Beaucoup d’extensions (formulaires, sondages, personnalisation) déposent leur propre cookie, ce qui empêche Varnish de servir une réponse en cache dès que ce cookie est présent, si la règle d’exclusion ne cible pas précisément le bon cookie.

La règle ci-dessus ne retire les cookies que pour les visiteurs sans session de connexion active, ce qui permet à Varnish de mettre en cache leur visite tout en laissant passer sans cache les utilisateurs réellement connectés (administrateurs, auteurs, clients connectés sur une boutique).

Exclure le panier et le tunnel d’achat sur WooCommerce

sub vcl_recv {
    if (req.url ~ "^/panier" || req.url ~ "^/commande" || req.url ~ "^/mon-compte") {
        return (pass);
    }
}

Ces zones restent dynamiques par nature et ne doivent jamais être mises en cache, sous peine d’afficher le panier d’un visiteur à un autre.

Purge automatique à la publication

Sans purge automatique, Varnish continuerait de servir une ancienne version d’un article corrigé pendant toute la durée du TTL configuré. Le module VCL de purge, combiné à un plugin WordPress qui déclenche la purge au bon moment :

acl purge {
    "127.0.0.1";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return (synth(405, "Non autorisé"));
        }
        return (purge);
    }
}

function wpm_purge_varnish( $post_id ) {
    $url = get_permalink( $post_id );
    wp_remote_request( $url, array( 'method' => 'PURGE' ) );
}
add_action( 'save_post', 'wpm_purge_varnish' );

Cette purge cible uniquement l’URL modifiée. Sur un site où la page d’accueil affiche les derniers articles, prévoyez aussi une purge de cette page à chaque publication, faute de quoi elle continuera d’afficher l’ancienne liste jusqu’à expiration du TTL.

Vérifier que le cache fonctionne réellement

curl -I https://exemple-client.test/ | grep -i "x-cache"

Un en-tête X-Cache: HIT confirme que Varnish a servi la réponse depuis son cache, sans solliciter le backend. Sur le projet mesuré, le temps de réponse moyen est passé de 380 millisecondes sans Varnish à 8 millisecondes en cache HIT.

Checklist avant mise en production

• Exclure explicitement l’admin, le panier et toute zone connectée avant d’activer Varnish sur un domaine en production.
• Vérifier qu’aucun cookie non identifié ne force involontairement le passage en pass sur une page qui devrait être en cache.
• Mettre en place la purge automatique dès l’activation, jamais après coup une fois le contenu obsolète signalé par un client.
• Surveiller le ratio HIT/MISS régulièrement, une chute soudaine du taux de HIT signale souvent une régression de configuration.

Le meilleur signe qu’un cache Varnish fonctionne correctement, c’est qu’aucun client ne signale jamais de contenu obsolète.

En résumé

Varnish reste un des leviers de cache les plus puissants pour un site WordPress à fort trafic, à condition de traiter avec le plus grand soin la gestion des cookies et la purge à la publication. Ces deux points concentrent la quasi-totalité des problèmes rencontrés sur les installations mal maîtrisées.