L'indispensable Varnish
Votre site est lent ? Comprenez ce que Varnish peut accélérer, les précautions sur les données personnelles et le travail de diagnostic à prévoir.
Sur cette page6 sections
Vous ouvrez votre site pour montrer une réalisation à un client, et la page met un moment à arriver. Vous pensez d'abord à votre connexion. Puis vous réessayez, sur un autre téléphone, et le résultat reste le même. Quand on connaît son site, on attend généralement un peu. La personne qui le découvre n'a pas forcément cette patience.
Le réflexe est alors de vouloir un hébergement plus puissant ou un outil censé tout accélérer. Varnish peut faire partie de la réponse, mais pas parce que son nom apparaît dans une liste de technologies performantes. Son intérêt est plus précis : éviter de refaire certains traitements lorsque plusieurs visiteurs demandent un même contenu public.
L'objectif n'est pas de vous faire choisir un logiciel de cache. C'est de comprendre ce que l'on peut accélérer, ce qui doit rester calculé pour chaque personne et comment vérifier que le site fonctionne toujours correctement après les modifications.
Ce fonctionnement est utile : vous modifiez une prestation dans votre administration, et le site sait la présenter. Mais si plusieurs personnes consultent cette prestation sans qu'elle ait changé, le serveur peut se retrouver à fabriquer plusieurs fois une réponse très semblable.
Varnish se place devant l'application et peut conserver une réponse publique pour la réutiliser. C'est ce que l'on appelle un cache HTTP. Si la réponse disponible correspond à la demande et reste utilisable selon les règles définies, elle peut être servie sans demander à l'application de tout reconstruire. Sinon, la demande lui est transmise.
Imaginez une page de réalisation qui présente les mêmes photos et le même texte à tous les visiteurs. Il peut être intéressant de préparer cette réponse une fois puis de la réutiliser. Il n'y a, en revanche, aucune raison de traiter un espace client comme cette page publique. C'est toute la différence entre mettre un cache en place et décider correctement de ce qu'il a le droit de conserver.
La documentation de Varnish présente les règles qui pilotent ce fonctionnement. Vous n'avez pas besoin d'apprendre leur langage de configuration pour utiliser votre site, mais quelqu'un doit les comprendre pour l'exploiter.
Mais une page peut répondre vite et rester pénible à utiliser. Des photos trop lourdes, des scripts qui retardent l'affichage ou une mise en page qui bouge au chargement ne disparaissent pas parce que Varnish a répondu à la demande. Le téléphone et la connexion du visiteur comptent aussi.
C'est pour cette raison que je vous conseille de commencer par mesurer le problème. Attendez-vous la première réponse du serveur, le chargement des images ou le moment où vous pouvez réellement utiliser la page ? Ce sont des attentes différentes, qui ne se corrigent pas toujours au même endroit.
Si les ressources du serveur sont insuffisantes, si une requête de base de données est anormalement coûteuse ou si une image fait plusieurs mégaoctets, il faut examiner ces sujets. Ajouter un cache ne dispense pas de comprendre pourquoi le site travaille mal. La documentation sur les performances de Varnish détaille aussi les contraintes de son propre fonctionnement.
Pour le visiteur, le résultat attendu reste simple : accéder à l'information, parcourir vos prestations et vous contacter sans attendre inutilement. L'article sur les Core Web Vitals et la vitesse d'un site permet de compléter ce regard au-delà du cache serveur.
Le travail consiste donc à identifier ces parcours et à les protéger. On ne désactive pas les précautions sur les sessions et les cookies simplement pour afficher un meilleur taux de cache. La documentation sur les conditions de mise en cache explique notamment le rôle des cookies et des en-têtes de réponse.
Une page peut aussi mélanger des informations publiques et personnelles. Il existe des techniques pour séparer certaines parties, mais ce n'est pas une permission générale de mettre toute la page en cache. Il faut comprendre ce qui varie, tester les règles et savoir comment le site se comporte lorsque cette séparation ne fonctionne pas comme prévu.
Pour vous, cela veut dire qu'un test ne doit pas se limiter à ouvrir la page d'accueil. Il faut également vérifier les fonctions dont dépend votre activité : envoyer un formulaire, se connecter, modifier un panier, ouvrir une réservation. Accélérer la vitrine en cassant la prise de commande ne serait pas un progrès.
On peut définir une durée de conservation et retirer des réponses du cache au moment où les contenus concernés changent. Varnish documente plusieurs mécanismes d'invalidation du cache. Le choix dépend notamment de la manière dont votre site publie ses contenus et relie ses pages.
Une réalisation ajoutée peut, par exemple, modifier sa propre page, la liste des réalisations et un bloc qui affiche les derniers projets. Il faut penser à ces dépendances. Vider seulement la page modifiée n'est pas toujours suffisant ; tout vider à chaque changement peut aussi retirer une grande partie de l'intérêt du cache.
Avant de considérer l'installation terminée, je vous conseille donc de faire une modification réelle de test, puis de vérifier le résultat comme un visiteur, sans être connecté à l'administration. Ce que vous voyez avec votre compte n'est pas forcément ce qu'une autre personne reçoit.
Cette possibilité concerne les contenus et les durées que l'on a prévus. Elle ne signifie pas qu'une commande peut être traitée sans application ni que l'ensemble du site continuera de fonctionner après n'importe quelle panne. Elle ne transforme pas non plus Varnish en protection complète contre les attaques par déni de service, qui cherchent à rendre un service indisponible en le surchargeant.
Il reste nécessaire de surveiller l'infrastructure, de maintenir les composants et de préparer les sauvegardes. La question du cache rejoint donc celle de la maintenance du site : qui vérifie le fonctionnement, qui intervient si les réponses deviennent incorrectes et qui adapte les règles lorsque le site évolue ?
À partir de là, le travail que je propose consiste à regarder les pages et les parcours concernés, mesurer où se situe l'attente, puis choisir une correction adaptée. Si un cache est pertinent, il faut définir ce qu'il peut conserver, tester les parties personnelles et vérifier que les publications mettent correctement les réponses à jour. Ensuite, on compare le fonctionnement avant et après, au lieu de se contenter de la présence d'un nouvel outil.
Cette approche peut conduire à utiliser Varnish, à revoir sa configuration s'il est déjà présent ou à corriger un autre problème en priorité. Le choix technique doit servir votre site, pas l'inverse. Un composant supplémentaire demande aussi de l'entretien ; s'il n'apporte pas de bénéfice utile, il n'y a pas de raison de l'ajouter pour son nom.
Si vous ne savez pas pourquoi votre site est lent ou si vous souhaitez reprendre son fonctionnement avant qu'il ne gêne vos clients, on peut commencer par en discuter.
Le réflexe est alors de vouloir un hébergement plus puissant ou un outil censé tout accélérer. Varnish peut faire partie de la réponse, mais pas parce que son nom apparaît dans une liste de technologies performantes. Son intérêt est plus précis : éviter de refaire certains traitements lorsque plusieurs visiteurs demandent un même contenu public.
L'objectif n'est pas de vous faire choisir un logiciel de cache. C'est de comprendre ce que l'on peut accélérer, ce qui doit rester calculé pour chaque personne et comment vérifier que le site fonctionne toujours correctement après les modifications.
Pourquoi votre serveur refait-il le même travail ?
Lorsqu'un visiteur ouvre une page, le site peut avoir besoin de récupérer des informations, de composer le contenu et de préparer la réponse que le navigateur affichera. Sur un site administrable, la page n'est pas forcément un fichier déjà terminé que l'on envoie tel quel.Ce fonctionnement est utile : vous modifiez une prestation dans votre administration, et le site sait la présenter. Mais si plusieurs personnes consultent cette prestation sans qu'elle ait changé, le serveur peut se retrouver à fabriquer plusieurs fois une réponse très semblable.
Varnish se place devant l'application et peut conserver une réponse publique pour la réutiliser. C'est ce que l'on appelle un cache HTTP. Si la réponse disponible correspond à la demande et reste utilisable selon les règles définies, elle peut être servie sans demander à l'application de tout reconstruire. Sinon, la demande lui est transmise.
Imaginez une page de réalisation qui présente les mêmes photos et le même texte à tous les visiteurs. Il peut être intéressant de préparer cette réponse une fois puis de la réutiliser. Il n'y a, en revanche, aucune raison de traiter un espace client comme cette page publique. C'est toute la différence entre mettre un cache en place et décider correctement de ce qu'il a le droit de conserver.
La documentation de Varnish présente les règles qui pilotent ce fonctionnement. Vous n'avez pas besoin d'apprendre leur langage de configuration pour utiliser votre site, mais quelqu'un doit les comprendre pour l'exploiter.
Est-ce que cela suffit à rendre le site rapide ?
Pas forcément. Si l'attente vient principalement de la préparation des pages par le serveur et que ces pages peuvent être partagées entre visiteurs, un cache peut réduire ce travail. Cela peut aussi soulager l'application quand beaucoup de personnes consultent les mêmes contenus publics.Mais une page peut répondre vite et rester pénible à utiliser. Des photos trop lourdes, des scripts qui retardent l'affichage ou une mise en page qui bouge au chargement ne disparaissent pas parce que Varnish a répondu à la demande. Le téléphone et la connexion du visiteur comptent aussi.
C'est pour cette raison que je vous conseille de commencer par mesurer le problème. Attendez-vous la première réponse du serveur, le chargement des images ou le moment où vous pouvez réellement utiliser la page ? Ce sont des attentes différentes, qui ne se corrigent pas toujours au même endroit.
Si les ressources du serveur sont insuffisantes, si une requête de base de données est anormalement coûteuse ou si une image fait plusieurs mégaoctets, il faut examiner ces sujets. Ajouter un cache ne dispense pas de comprendre pourquoi le site travaille mal. La documentation sur les performances de Varnish détaille aussi les contraintes de son propre fonctionnement.
Pour le visiteur, le résultat attendu reste simple : accéder à l'information, parcourir vos prestations et vous contacter sans attendre inutilement. L'article sur les Core Web Vitals et la vitesse d'un site permet de compléter ce regard au-delà du cache serveur.
Le panier de votre client ne doit pas devenir celui du suivant
Toutes les réponses d'un site ne sont pas publiques. Un panier, une facture, un espace de réservation ou une page après connexion peuvent dépendre de la personne qui consulte. Une mauvaise règle de cache peut alors provoquer autre chose qu'une simple erreur d'affichage : une réponse destinée à une personne pourrait être donnée à une autre.Le travail consiste donc à identifier ces parcours et à les protéger. On ne désactive pas les précautions sur les sessions et les cookies simplement pour afficher un meilleur taux de cache. La documentation sur les conditions de mise en cache explique notamment le rôle des cookies et des en-têtes de réponse.
Une page peut aussi mélanger des informations publiques et personnelles. Il existe des techniques pour séparer certaines parties, mais ce n'est pas une permission générale de mettre toute la page en cache. Il faut comprendre ce qui varie, tester les règles et savoir comment le site se comporte lorsque cette séparation ne fonctionne pas comme prévu.
Pour vous, cela veut dire qu'un test ne doit pas se limiter à ouvrir la page d'accueil. Il faut également vérifier les fonctions dont dépend votre activité : envoyer un formulaire, se connecter, modifier un panier, ouvrir une réservation. Accélérer la vitrine en cassant la prise de commande ne serait pas un progrès.
Et quand vous modifiez un prix ou une prestation ?
Un cache conserve une réponse. Il faut donc prévoir ce qui doit arriver quand cette réponse devient ancienne. Sinon, vous pouvez corriger une information dans votre administration et constater qu'un visiteur voit encore la version précédente.On peut définir une durée de conservation et retirer des réponses du cache au moment où les contenus concernés changent. Varnish documente plusieurs mécanismes d'invalidation du cache. Le choix dépend notamment de la manière dont votre site publie ses contenus et relie ses pages.
Une réalisation ajoutée peut, par exemple, modifier sa propre page, la liste des réalisations et un bloc qui affiche les derniers projets. Il faut penser à ces dépendances. Vider seulement la page modifiée n'est pas toujours suffisant ; tout vider à chaque changement peut aussi retirer une grande partie de l'intérêt du cache.
Avant de considérer l'installation terminée, je vous conseille donc de faire une modification réelle de test, puis de vérifier le résultat comme un visiteur, sans être connecté à l'administration. Ce que vous voyez avec votre compte n'est pas forcément ce qu'une autre personne reçoit.
Un cache aide pendant un incident mais ne remplace pas la sécurité
Varnish peut, selon sa configuration et les réponses déjà disponibles, servir temporairement une version ancienne pendant que l'application répond mal ou tarde à reconstruire le contenu. La documentation appelle cela le mode grace.Cette possibilité concerne les contenus et les durées que l'on a prévus. Elle ne signifie pas qu'une commande peut être traitée sans application ni que l'ensemble du site continuera de fonctionner après n'importe quelle panne. Elle ne transforme pas non plus Varnish en protection complète contre les attaques par déni de service, qui cherchent à rendre un service indisponible en le surchargeant.
Il reste nécessaire de surveiller l'infrastructure, de maintenir les composants et de préparer les sauvegardes. La question du cache rejoint donc celle de la maintenance du site : qui vérifie le fonctionnement, qui intervient si les réponses deviennent incorrectes et qui adapte les règles lorsque le site évolue ?
Ce que je propose de regarder avec vous
Vous n'avez pas besoin d'arriver avec une demande d'installation de Varnish. Vous pouvez venir avec un problème bien plus concret : les pages prennent trop de temps à s'ouvrir, le site ralentit lorsque vous communiquez sur une offre ou certaines informations semblent ne pas se mettre à jour.À partir de là, le travail que je propose consiste à regarder les pages et les parcours concernés, mesurer où se situe l'attente, puis choisir une correction adaptée. Si un cache est pertinent, il faut définir ce qu'il peut conserver, tester les parties personnelles et vérifier que les publications mettent correctement les réponses à jour. Ensuite, on compare le fonctionnement avant et après, au lieu de se contenter de la présence d'un nouvel outil.
Cette approche peut conduire à utiliser Varnish, à revoir sa configuration s'il est déjà présent ou à corriger un autre problème en priorité. Le choix technique doit servir votre site, pas l'inverse. Un composant supplémentaire demande aussi de l'entretien ; s'il n'apporte pas de bénéfice utile, il n'y a pas de raison de l'ajouter pour son nom.
Si vous ne savez pas pourquoi votre site est lent ou si vous souhaitez reprendre son fonctionnement avant qu'il ne gêne vos clients, on peut commencer par en discuter.
