Table des matières de l'article :
Si vous cherchez à optimiser et accélérer l'ouverture de votre site WordPress, WooCommerce ou autre, vous serez sûrement tombé sur des articles et des conseils qui vous ont parlé de l'installation de logiciels ou de plugins Cache.
Si vous avez eu de la chance, vous aurez également entendu certains professionnels en parler Cache de vernis, plutôt que du Cache inutile côté plugin ou du Cache serveur plus banal et moins fonctionnel NGINX FastCGI Cache.
Qu'est-ce que le cache vernis ?
Mais qu'est ce que c'est exactement Vernis et pourquoi est-ce le meilleur choix si vous décidez d'accélérer l'expérience utilisateur de votre site Web ?
Varnish Cache est un puissant logiciel côté serveur, écrit en langage de programmation C, reconnu pour ses performances exceptionnelles. Sa conception et son développement ont été guidés par des concepts établis et les meilleures pratiques de développement logiciel, notamment la gestion dynamique de la mémoire, le déploiement de threads, l'utilisation de la mémoire partagée et l'utilisation des sockets standard POSIX, entre autres. Ces mécanismes raffinés seraient irréalisables avec un langage interprété comme PHP.
Contrairement aux caches PHP mentionnés, qui n'entrent en jeu qu'après l'exécution du code de cache PHP et la création d'un processus d'interpréteur PHP via les threads PHP-FPM (Fast Process Manager), Varnish Cache démarre immédiatement. Cela n'implique pas du tout PHP ou la création de nouveaux threads et processus, ce qui réduit considérablement la charge sur le processeur. Cet aspect est particulièrement avantageux lorsqu'il s'agit de traiter des niveaux de trafic Web très élevés, qui peuvent atteindre des milliers, voire des dizaines de milliers de visiteurs simultanés.
En fait, dans un hébergement WordPress géré à fort trafic, l'utilisation de Varnish dans notre pile logicielle nous permet de gérer des sites qui comptent plus de 45 millions de visiteurs uniques par mois, plus de 200 millions de pages vues et des pics de plus de 100.000 XNUMX utilisateurs par minute.
Pour illustrer ce point, considérons la capture d'écran ci-dessous de Google Analytics de l'un de nos clients. Ce site attire jusqu'à 85 millions de visiteurs par mois, démontrant ainsi l'évolutivité et la résistance offertes par Varnish Cache.
Beaucoup de visiteurs, beaucoup de fils PHP ?
L'un des malentendus les plus fréquents chez les administrateurs de sites web qui gèrent un volume de trafic élevé, avec des pics de visiteurs atteignant des milliers par minute, concerne la gestion des Listeners PHP-FPM. L'erreur courante consiste à essayer d'augmenter le nombre d'écouteurs PHP-FPM afin de gérer davantage de connexions et de requêtes entrantes.
Le raisonnement qui guide souvent cette décision peut être résumé comme suit :
Si j'ai 1000 utilisateurs par minute, plutôt que de définir les écouteurs PHP-FPM sur 32, je peux les configurer sur 512. De cette façon, je pourrai gérer plus de demandes.
C'est un piège dans lequel beaucoup tombent, croyant à tort qu'augmenter la valeur du nombre de Listeners PHP-FPM suffit à traiter plus de requêtes.
Cependant, la réalité s'avère très différente. S'il est possible d'augmenter le nombre d'écouteurs PHP-FPM avec une simple modification du fichier de configuration du pool concerné, le matériel physique sous-jacent ne peut pas être adapté aussi facilement. Par exemple, si votre système dispose de 8 cœurs, définir 512 threads n'est peut-être pas le choix le plus judicieux. En effet, ces threads devront encore être exécutés sur les 8 cœurs disponibles, impliquant l'activation du multiplexage et de l'ordonnancement des processeurs. Ce mécanisme entraînera l'exécution de plus de processus, mais avec des temps d'exécution réduits, donc plus lents.
Au fur et à mesure que le processeur gère les opérations sur le pool 512, les nouvelles demandes entrantes commenceront à s'accumuler. Celles-ci s'ajouteront à la file d'attente des requêtes précédentes et, en quelques minutes, cette file d'attente pourrait devenir si longue qu'elle prendrait des minutes voire des dizaines de minutes à traiter. Cela entraîne des délais d'attente gênants, tels qu'une erreur 502 Gateway Timeout ou 502 Bad Gateway.
En conclusion, bien que cela semble une solution intuitive, augmenter le nombre de Listeners PHP-FPM n'est pas toujours la réponse optimale pour gérer un afflux important d'utilisateurs. Au contraire, une bonne compréhension du fonctionnement sous-jacent du matériel et des logiciels du système peut aider à trouver des stratégies plus efficaces pour gérer la forte simultanéité des demandes.
PHP craint. MySQL craint. Apache et NGINX sont nuls. WordPress ? Aussi.
Il n'est pas rare d'entendre des critiques sévères adressées à PHP, MySQL, Apache, NGINX et WordPress. Oui, je viens de le dire et oui, j'ai peut-être l'air un peu cynique. Cependant, mon intention n'est pas de dénigrer ces technologies, mais plutôt de souligner une réalité concrète : si PHP et MySQL étaient aussi rapides que des technologies plus modernes comme Node.js, GoLang ou des bases de données noSQL comme Redis.io et MongoDB, l'utilisation de services de mise en cache serait probablement superflue.
Malheureusement, le monde numérique n'est pas comme ça. Par exemple, bon nombre des CMS les plus importants continuent d'être basés sur la pile PHP + MySQL, ce qui rend notre travail et l'utilisation de solutions comme Varnish toujours nécessaires. Et, malgré les critiques, cela nous offre une réelle opportunité. Une opportunité qui se traduit par une valeur tangible : la possibilité d'obtenir des performances supérieures en utilisant du matériel moins cher.
En définitive, ce qui en découle est un double avantage qui suit les fondements de la recherche opérationnelle : la maximisation des profits tout en minimisant les coûts. Ainsi, au lieu de dévaloriser PHP, MySQL, Apache, NGINX et WordPress, on pourrait plutôt reconnaître leur rôle dans le paysage technologique actuel, et travailler à optimiser leurs performances avec des outils adaptés comme Varnish, afin de tirer un maximum de profit de leur présence.
Vernis Cache en pratique.
Varnish fonctionne essentiellement en stockant les requêtes GET, comme une page Web commune, dans son stockage. Ce dernier peut résider physiquement à la fois sur disque, avec des avantages en termes de capacité de stockage, et en RAM, qui offre au contraire des avantages en termes de vitesse d'accès et donc de latence réduite.
Imaginons qu'un utilisateur accède à https://www.sitoexample.it/company depuis son navigateur. Le fonctionnement de Varnish dans cette circonstance prévoit que le logiciel vérifie dans un premier temps si la page demandée est déjà présente dans son cache. Si la réponse est oui, Varnish fournira rapidement la page à l'utilisateur. Sinon, la demande sera PASSÉE au backend du serveur Web, qui est généralement représenté par Apache ou NGINX.
Ces serveurs Web vont à leur tour déclencher l'exécution du code PHP et envoyer les requêtes associées à la base de données MySQL pour générer la page HTML demandée. Une fois générée, la page est renvoyée au serveur Web, est mise en cache pour une utilisation future et finalement envoyée au navigateur de l'utilisateur. Ainsi, l'utilisateur pourra enfin visualiser la page de l'entreprise sur le site exemple.
Supposons que, lors de la première visite, la page prenne une seconde pour se générer, avec un délai supplémentaire de 50 millisecondes pour la livraison au navigateur du visiteur. Désormais, à la deuxième visite, la page ayant déjà été mémorisée par Varnish, il ne sera plus nécessaire de générer à nouveau la page, mais il suffira de l'envoyer à l'utilisateur. Par conséquent, au lieu de prendre 1 seconde et 50 millisecondes, il ne faudra que 50 millisecondes pour rechercher la page dans le cache Varnish et 50 millisecondes supplémentaires pour la livrer à l'utilisateur. En conséquence, le temps de réponse total passe de 1,050 millisecondes à 100 millisecondes, une économie de 1500%. Cela démontre comment Varnish peut avoir un impact significatif sur la vitesse de chargement des pages et, par conséquent, sur l'expérience utilisateur.
Il est évident que dans la description que je viens de donner des caractéristiques importantes de Varnish, telles que le hachage, la récupération, la suppression des cookies, les paramètres, etc., ont été omises par souci de narration. fonctions absolument vitales dans certains cas qui font de Vernis précisément le fleuron des logiciels de mise en cache.
Dans cette courte vidéo en anglais de la société mère Varnish-Software, vous pouvez comprendre de manière très élémentaire la signification d'un logiciel de cache comme Varnish.
Cache de vernis. Grands pouvoirs, grandes responsabilités.
Tout comme les super-héros dans les bandes dessinées et les films, symbolisés dans la mascotte Varnish Cache en tant que lapin super-héros, un grand pouvoir s'accompagne d'une grande responsabilité.
Varnish est sans aucun doute l'un des meilleurs logiciels de cache web disponibles (disons même le meilleur), mais, en même temps, c'est un logiciel "simple" dans le sens où il ne fait que ce pour quoi il est configuré. Cela implique qu'une configuration précise et précise, à la fois de Varnish lui-même et de l'application que vous avez l'intention d'utiliser avec lui, est absolument essentielle pour les meilleurs résultats.
Il y a plusieurs questions que chaque développeur, administrateur système et utilisateur de Varnish doit se poser lors de la phase de configuration, telles que :
Combien de temps le cache doit-il durer ?
La durée du cache est un aspect crucial à prendre en compte lors de la configuration de Varnish. En effet, le temps de rétention des informations dans le cache peut fortement varier selon le type de contenu et sa fréquence de mise à jour.
Prenons par exemple la page de présentation institutionnelle d'une entreprise. Ce type de contenu change rarement, peut-être une ou deux fois par an. Par conséquent, pour ce type de page, définir une durée de cache très longue pourrait être approprié, car cela permettrait à la page d'être servie très rapidement à tous les visiteurs, sans avoir à recharger les informations du serveur à chaque requête.
En revanche, si l'on considère un blog rapportant l'actualité du football en temps réel lors d'un match de Serie A, la situation change radicalement. Dans ce scénario, toute action importante dans le match, comme une réservation, un carton rouge, un penalty ou un but, pourrait nécessiter un rafraîchissement immédiat de la page. Dans ce cas, définir une durée de cache trop longue peut vous empêcher de fournir aux utilisateurs des mises à jour opportunes et pertinentes. Par conséquent, il serait judicieux de configurer une durée de cache beaucoup plus courte, voire de désactiver complètement la mise en cache lors des événements en direct.
La durée du cache doit être soigneusement pondérée en fonction de la nature du contenu du site et de sa fréquence de mise à jour. Cette considération permet d'équilibrer la nécessité de fournir un contenu à jour avec la nécessité de maintenir une réactivité élevée du site.
Comment gérer les pages AMP avec Cache ?
La gestion des pages mobiles accélérées (AMP) dans un environnement en cache, comme celui proposé par Varnish, présente un défi intéressant. Avec l'introduction d'AMP, de nombreux aspects du classement des moteurs de recherche, du référencement en temps réel et des services de trafic très payants comme Google News ont changé. Parmi les problèmes les plus courants qui émergent dans ce contexte figure la gestion des pages AMP.
AMP est un cadre développé par Google pour améliorer la vitesse et la convivialité des sites Web sur les appareils mobiles. Les pages AMP sont des versions simplifiées et simplifiées des pages Web standard, conçues pour se charger rapidement sur les appareils mobiles. Cela a un impact significatif sur le référencement, car Google a tendance à favoriser les pages AMP dans les résultats de recherche mobiles.
Lorsque vous utilisez un système de mise en cache comme Varnish, il est important de réfléchir à la manière de gérer les pages AMP. En particulier, lorsque le contenu d'une publication est mis à jour, il est indispensable de signaler à Google que la version AMP de la publication a également été modifiée. En effet, si le contenu AMP n'est pas mis à jour en conséquence, il peut y avoir des écarts entre la version standard de la page et celle AMP, ce qui peut entraîner des pénalités dans les résultats de recherche Google.
La stratégie idéale de gestion des pages AMP peut dépendre de divers facteurs, notamment le type de contenu sur le site, la fréquence des mises à jour et la nature de l'audience. Une possibilité serait de définir une durée de cache plus courte pour les pages AMP, afin de s'assurer qu'elles sont mises à jour plus fréquemment. Une autre option consisterait à utiliser un système d'invalidation du cache, qui permet de supprimer des pages spécifiques du cache lorsque le contenu d'origine est mis à jour.
Dans tous les cas, il est essentiel de surveiller de près les performances du site et les métriques SEO pour s'assurer que la stratégie adoptée est efficace et ne crée pas de problèmes inattendus.
Comment gérer les cookies inutiles, les laisser passer ?
La gestion des cookies peut être une chose particulièrement délicate en matière de mise en cache, en particulier avec des logiciels comme Varnish. En effet, la présence d'un cookie pourrait conduire Varnish à considérer une demande comme "personnalisée" pour un utilisateur spécifique et, par conséquent, à ne pas utiliser le cache.
Parfois, vous pouvez rencontrer des plugins ou du code qui définissent inutilement des cookies côté serveur, provoquant une invalidation du cache même lorsque cela n'est pas nécessaire. Ce comportement peut réduire considérablement l'efficacité de la mise en cache et, par conséquent, ralentir le site.
La meilleure stratégie pour faire face à cette situation peut dépendre de divers facteurs, notamment la nature du cookie et ses implications potentielles pour l'expérience utilisateur et la fonctionnalité du site. Si le cookie est vraiment inutile et n'a aucun impact sur la fonctionnalité du site ou l'expérience utilisateur, il peut être possible de le supprimer complètement. Cela peut être fait en modifiant le code qui génère le cookie ou en configurant Varnish pour ignorer ou supprimer des cookies spécifiques.
Cependant, avant de prendre cette décision, il est important d'examiner attentivement les conséquences possibles. Certains cookies, même s'ils peuvent sembler inutiles à première vue, pourraient jouer un rôle important pour certaines fonctionnalités du site ou pour le respect des lois et réglementations, telles que celles relatives à la vie privée et à la protection des données.
Par conséquent, lorsqu'il s'agit de gérer les cookies dans un contexte de mise en cache, il est important de procéder avec prudence et de préférence avec l'aide d'un expert en développement Web ou consultant SEO. Il est également essentiel que vous testiez soigneusement toutes les modifications que vous apportez pour vous assurer qu'elles n'ont pas d'effets négatifs inattendus sur votre site ou sur l'expérience utilisateur.
Qu'en est-il des fichiers volumineux ?
Lorsqu'il s'agit de gérer des fichiers volumineux dans un environnement de mise en cache, tel que celui fourni par Varnish, il est important d'examiner attentivement les avantages et les inconvénients. D'une part, la mise en cache de fichiers volumineux tels que des images haute résolution, des fichiers ISO ou des archives ZIP ou RAR peut sembler une bonne idée pour accélérer le chargement de ces éléments. Cependant, d'un autre côté, il y a quelques considérations importantes à garder à l'esprit.
Premièrement, la mise en cache de fichiers volumineux peut occuper beaucoup d'espace de stockage. Cela peut ne pas être un problème pour les sites avec une quantité limitée de contenu volumineux, mais pour les sites qui hébergent un grand nombre de ces fichiers, les ressources de stockage peuvent rapidement devenir un problème. De plus, si le matériel sous-jacent n'est pas à la hauteur de la tâche, il peut y avoir un ralentissement général du système en raison de la charge de traitement des fichiers volumineux.
Deuxièmement, il peut y avoir un problème de latence. Si un utilisateur demande le téléchargement d'un fichier volumineux et que Varnish doit d'abord charger ce fichier dans son cache, l'utilisateur devra peut-être attendre plus longtemps pour que le téléchargement commence. Dans certains cas, il peut être plus efficace de transmettre la demande directement au serveur Web, qui peut immédiatement commencer à envoyer le fichier à l'utilisateur.
Enfin, il est important de se rappeler que les fichiers volumineux, en particulier ceux tels que les fichiers ISO ou les archives ZIP ou RAR, ont tendance à être téléchargés moins fréquemment que les autres types de contenu. Par conséquent, l'avantage de la mise en cache de ces fichiers n'est peut-être pas aussi important qu'on pourrait le penser.
Par conséquent, lorsqu'il s'agit de gérer des fichiers volumineux avec Varnish, la meilleure stratégie peut dépendre du type spécifique de site et de son public. Vous voudrez peut-être consulter les statistiques d'accès de votre site pour déterminer quels fichiers sont téléchargés le plus fréquemment et déterminer s'il est judicieux de mettre ces fichiers en cache. Vous devez également surveiller de près les performances du site et effectuer des tests pour déterminer l'effet de la mise en cache de fichiers volumineux sur les performances globales du site.
Comment gérer les pages utilisateurs d'un Ecommerce ?
La gestion des pages utilisateurs dans un ecommerce, notamment dans un environnement qui utilise une solution de cache comme Varnish, demande une attention particulière. Certains aspects cruciaux doivent être pris en compte pour garantir une expérience utilisateur fluide et sûre tout en respectant les réglementations en matière de confidentialité, telles que le RGPD en Europe.
Le premier aspect concerne le chariot. Lorsqu'un client ajoute des articles à son panier dans une boutique en ligne comme WooCommerce, ces données sont spécifiques à cet utilisateur et ne doivent pas être partagées ou rendues visibles pour d'autres clients. Si le panier n'est pas correctement mis en cache par Varnish, des problèmes peuvent survenir, comme montrer le panier d'un autre utilisateur. Pour éviter cela, vous devez configurer Varnish pour ne pas mettre en cache les pages du panier. En général, toutes les pages contenant des données sensibles et spécifiques à l'utilisateur ne doivent pas être mises en cache.
Le deuxième aspect concerne l'espace privé de l'utilisateur, où les détails de son compte peuvent être consultés, tels que les informations de facturation et l'historique des commandes. Ces pages sont hautement personnalisées et contiennent des données sensibles. Par conséquent, comme dans le cas du panier, ces pages ne doivent pas être mises en cache. Il est crucial de s'assurer que chaque utilisateur ne puisse voir que ses propres données et non celles des autres clients.
En résumé, toute page ou section d'un site de commerce électronique contenant des informations spécifiques à l'utilisateur ou des données sensibles doit être exclue du cache. Cela peut nécessiter une configuration minutieuse de Varnish, ainsi qu'une compréhension claire des exigences spécifiques de la boutique en ligne. Non seulement cette approche garantit une meilleure expérience utilisateur, mais elle vous aide également à vous conformer aux réglementations en matière de confidentialité telles que le RGPD. Il est important de souligner que la configuration de Varnish doit être gérée par des professionnels expérimentés pour éviter les erreurs qui pourraient compromettre la sécurité et la confidentialité des données de l'utilisateur.
Comment gérer les URL de suivi paramétriques comme fbclid ou utm avec Varnish ?
Le problème des paramètres de suivi tels que "fbclid" dans les URL, fréquemment utilisés dans les campagnes de marketing en ligne, présente un défi pour l'optimisation du cache avec Varnish. En effet, pour chaque URL unique, Varnish crée une version distincte dans le cache. Par conséquent, si le paramètre "fbclid" change pour chaque utilisateur qui clique sur un lien de Facebook, Varnish traitera chaque demande comme unique, contournant le cache et ralentissant la vitesse du site comme s'il n'y avait pas de cache.
Cependant, il est possible de gérer cette situation de manière élégante et efficace, sans compromettre la fonctionnalité de suivi de paramètres tels que "fbclid" ou "UTM" par Google.
Une solution peut être de configurer Varnish pour normaliser les URL en supprimant ou en ignorant certains paramètres de chaîne de requête. Cela peut être fait via le langage de configuration Varnish (VCL). En fonction vcl_recv
, vous pouvez ajouter du code qui réécrit l'URL, en supprimant des paramètres de requête spécifiques. Cependant, il est important de noter que cette action n'affectera pas la fonctionnalité de suivi, car les paramètres seront simplement supprimés au moment où la demande parviendra à Varnish, mais seront toujours présents lorsque la demande initiale sera effectuée à partir du navigateur de l'utilisateur.
De plus, une autre possibilité serait d'utiliser une fonction de hachage dans Varnish. Dans VCL, vous pouvez personnaliser la fonction vcl_hash
pour ignorer certains paramètres d'URL lorsque Varnish décide si une page est mise en cache ou non.
De cette façon, vous pouvez vous assurer que votre site WooCommerce fonctionne à la vitesse la plus rapide possible, quelles que soient les campagnes publicitaires que vous exécutez, sans perdre la capacité de suivre efficacement l'origine du trafic vers votre site.
Comment utiliser Varnish avec HTTPS ?
L'utilisation de Varnish en conjonction avec HTTPS peut sembler un peu difficile, étant donné l'incompatibilité présumée entre le système de mise en cache de Varnish et le protocole HTTPS. En effet, cette hypothèse a conduit de nombreux fournisseurs de services Web, tant en Italie qu'à l'étranger, à abandonner Varnish au profit de solutions telles que LiteSpeed Cache. Cependant, nous pouvons affirmer avec certitude qu'avec une configuration appropriée, Varnish peut être utilisé efficacement avec HTTPS, et notre expérience en est la preuve vivante.
Varnish lui-même ne prend pas directement en charge HTTPS. Cependant, cela ne signifie pas qu'il ne peut pas être utilisé dans un environnement qui nécessite HTTPS. Pour contourner cette limitation, vous pouvez utiliser un proxy inverse comme NGINX ou Hitch devant Varnish. Ces serveurs peuvent gérer les connexions HTTPS, les décrypter, puis transmettre les requêtes HTTP à Varnish. De cette façon, vous pouvez tirer parti de la puissance et des performances de Varnish, tout en conservant la sécurité offerte par HTTPS.
De plus, l'implémentation de Varnish avec HTTPS nous a permis de profiter du protocole HTTP/2 mais aussi HTTP/3 qui offre des avantages supplémentaires en termes de performances. HTTP/2 permet le multiplexage des requêtes, ce qui signifie que plusieurs requêtes peuvent être envoyées simultanément sur la même connexion, ce qui permet d'économiser du temps et des ressources serveur.
Choisir de continuer à utiliser Varnish, en l'adaptant pour une utilisation avec HTTPS et HTTP2, s'est avéré être une décision gagnante pour nous. Ce choix a conduit à une amélioration significative en termes de qualité de service offert et a contribué à doubler nos bénéfices et notre chiffre d'affaires au cours de la dernière année. Le succès que nous avons connu démontre que la polyvalence et les performances de Varnish peuvent vraiment faire la différence dans un marché concurrentiel tel que l'hébergement Web.
Installer Varnish Supercache est différent de faire fonctionner Varnish.
La mise en œuvre de Varnish Supercache ne se limite pas à une installation de base - tirer le meilleur parti de Varnish nécessite un processus beaucoup plus complexe.
Vous pourriez être tenté d'utiliser Varnish via l'un des hébergements qui le proposent en solution préconfigurée. Mais il est essentiel de comprendre que l'installation ou l'achat de Varnish en tant que service auprès d'un fournisseur d'hébergement ne garantit pas la pleine fonctionnalité de ce puissant outil de mise en cache. Varnish nécessite une configuration soignée sur le serveur, selon les besoins spécifiques de votre projet, ainsi qu'un paramétrage précis sur le backend de votre site WordPress, pour assurer le bon fonctionnement de l'ensemble des nettoyages de cache (purge), des sitemaps, des AMP pages, articles instantanés, pages utilisateur, gestion des cookies et bien plus encore.
Si la solution qui vous est proposée n'est pas personnalisée et n'inclut pas le support d'un administrateur système expert qui vous assiste pendant toutes les phases initiales - de la migration, à la configuration, au réglage - alors il est probable que vous soyez sur le point d'acheter quelque chose qui pourrait causer de sérieux problèmes à votre site à court ou moyen terme. Par exemple, ne pas mettre à jour vos sitemaps pourrait empêcher vos nouveaux articles d'être indexés par Google ; un dysfonctionnement d'AMP pourrait vous exclure de Google Actualités ; et d'autres problèmes potentiellement encore plus graves pourraient conduire, dans les cas les plus extrêmes, à la désactivation de votre site.
Dans le meilleur des cas, vous pouvez vous retrouver avec Varnish installé sur votre serveur, mais incapable de mettre correctement en cache les données, permettant ainsi à toutes les requêtes d'aller directement au serveur Web et, par conséquent, à PHP et MySQL.
Si votre objectif est d'optimiser la vitesse d'un site WordPress ou WooCommerce, de gérer des pics de trafic élevés et un grand nombre d'utilisateurs, nous pouvons vous aider. Nous offrons les meilleures solutions technologiques et systémiques au meilleur prix.
N'hésitez pas à nous contacter pour savoir comment nous pouvons accompagner votre projet.