1 janvier 2019

HĂ©bergement de vernis

Qu'est-ce que le vernis ? Pourquoi choisir l'hébergement Varnish surtout si vous utilisez WordPress ou WooCommerce ?

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.

502 Passerelle incorrecte nginx

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.

Opération de vernissage

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.

mascotte de vernis

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.

 

Informations sur l'auteur

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions systÚme GNU/Linux avancées orientées vers la haute performance. Avec un modÚle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accÚs à des technologies avancées en matiÚre d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils systÚme sur les systÚmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. dĂ©tient les droits de Red HatÂź, RHELÂź, RedHat LinuxÂź et CentOSÂź ; AlmaLinuxℱ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky LinuxÂź est une marque dĂ©posĂ©e de la Rocky Linux Foundation ; SUSEÂź est une marque dĂ©posĂ©e de SUSE LLC ; Canonical Ltd. dĂ©tient les droits sur UbuntuÂź ; Software in the Public Interest, Inc. dĂ©tient les droits sur DebianÂź ; Linus Torvalds dĂ©tient les droits sur LinuxÂź ; FreeBSDÂź est une marque dĂ©posĂ©e de la FreeBSD Foundation ; NetBSDÂź est une marque dĂ©posĂ©e de la Fondation NetBSD ; OpenBSDÂź est une marque dĂ©posĂ©e de Theo de Raadt. Oracle Corporation dĂ©tient les droits sur OracleÂź, MySQLÂź et MyRocksÂź ; PerconaÂź est une marque dĂ©posĂ©e de Percona LLC ; MariaDBÂź est une marque dĂ©posĂ©e de MariaDB Corporation Ab ; REDISÂź est une marque dĂ©posĂ©e de Redis Labs Ltd. F5 Networks, Inc. dĂ©tient les droits sur NGINXÂź et NGINX PlusÂź ; VarnishÂź est une marque dĂ©posĂ©e de Varnish Software AB. Adobe Inc. dĂ©tient les droits sur MagentoÂź ; PrestaShopÂź est une marque dĂ©posĂ©e de PrestaShop SA ; OpenCartÂź est une marque dĂ©posĂ©e d'OpenCart Limited. Automattic Inc. dĂ©tient les droits sur WordPressÂź, WooCommerceÂź et JetPackÂź ; Open Source Matters, Inc. dĂ©tient les droits sur JoomlaÂź ; Dries Buytaert dĂ©tient les droits sur DrupalÂź. Amazon Web Services, Inc. dĂ©tient les droits sur AWSÂź ; Google LLC dĂ©tient les droits sur Google Cloudℱ et Chromeℱ ; Facebook, Inc. dĂ©tient les droits sur FacebookÂź ; Microsoft Corporation dĂ©tient les droits sur MicrosoftÂź, AzureÂź et Internet ExplorerÂź ; La Fondation Mozilla dĂ©tient les droits sur FirefoxÂź. ApacheÂź est une marque dĂ©posĂ©e de The Apache Software Foundation ; PHPÂź est une marque dĂ©posĂ©e du groupe PHP. CloudFlareÂź est une marque dĂ©posĂ©e de Cloudflare, Inc. ; NETSCOUTÂź est une marque dĂ©posĂ©e de NETSCOUT Systems Inc. ; ElasticSearchÂź, LogStashÂź et KibanaÂź sont des marques dĂ©posĂ©es d'Elastic NV. Ce site n'est affiliĂ©, sponsorisĂ© ou autrement associĂ© Ă  aucune des entitĂ©s mentionnĂ©es ci-dessus et ne reprĂ©sente aucune de ces entitĂ©s de quelque maniĂšre que ce soit. Tous les droits sur les marques et noms de produits mentionnĂ©s sont la propriĂ©tĂ© de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnĂ©es appartiennent Ă  leurs titulaires. MANAGED SERVERÂź est une marque dĂ©posĂ©e au niveau europĂ©en par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systĂšmes sans avoir Ă  migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entiÚrement gratuite.

Non merci, mes clients préfÚrent le site lent.
Retour en haut de page