Accélérez WooCommerce et WordPress. Comment accélérer votre site ?

Table des matières de l'article :

En fin de compte, quelqu'un a dû le faire, expliquer une fois pour toutes de manière claire, précise et concise pourquoi WordPress est lent, ce que cela signifie d'augmenter ses performances, comment le rendre plus rapide à la fois du point de vue du développement et du point de vue point de vue Système et hébergement WordPress.

Cela vous permettra de tirer les bonnes conclusions et de faire le tri parmi les milliers d'offres d'experts autoproclamés qui tentent chaque jour de vous vendre des services d'optimisation de la vitesse WordPress, ou des services d'accélération WordPress, comme certains les appellent.

Avertissement : La suite de cet article est assez technique et pourrait ne pas convenir aux entrepreneurs qui excellent dans d’autres domaines et dont le site web est lent ; ils souhaitent simplement l’optimiser. Si vous préférez ne pas vous familiariser avec des termes techniques comme la mise en cache, TCP BBR, la partie visible de la page (Above the Fold), le CSS critique, etc., veuillez nous contacter directement via la section contact.

Si, en revanche, vous êtes curieux de comprendre ce que nous faisons et les problèmes de lenteur que nous allons résoudre, poursuivez cette lecture.

Comme nous l'avons dit au départ, il y a malheureusement une posture plutôt malhonnête dans le panorama, les ingénieurs système disent qu'un hébergement et un serveur rapides suffisent pour avoir un site rapide, et les développeurs avancent plutôt qu'il suffit d'avoir un site développé ad hoc (évidemment d'eux des dizaines de milliers d'euros par an), afin de ne pas avoir de problèmes en termes de performances et de vitesse.

Voici ce qu'un développeur WordPress renommé et très compétent écrit sur son site à propos de nous, les administrateurs système.

Ce que le monsieur ci-dessus omet manifestement de mentionner, c'est que l'entreprise avec laquelle nous avons travaillé est passée d'un temps de chargement de page d'environ 6 secondes à 1,5 seconde UNIQUEMENT et exclusivement grâce à un réglage expert du système côté serveur, et ce n'est que par la suite qu'une amélioration supplémentaire de l'ordre d'à peine une demi-seconde a été obtenue grâce à une approche de développement ad hoc très coûteuse qui a coûté des dizaines de milliers d'euros par an, comme nous l'a rapporté le PDG d'une entreprise que nous omettrons par souci d'équité et de confidentialité pour toutes les parties.

Il est donc entendu que très souvent une approche vestimentaire ad-hoc au niveau du développement (comme développer des plugins ou des thèmes à partir de zéro) n'est possible qu'après que l'entreprise a réussi à obtenir des résultats économiques importants en ligne avec un faible investissement initial au niveau du système ce qui a permis d'amener le site à une vitesse au moins plus qu'adéquate pour réussir en ligne, et ce n'est que plus tard éventuellement de réinvestir une somme importante (de plusieurs dizaines et dizaines de milliers d'euros par an) pour un réglage ad hoc également à le niveau applicatif.

Cela ne veut pas dire qu'une approche au niveau du développement n'est pas importante, au contraire nous sommes les premiers à soutenir exactement le contraire, c'est pourquoi souvent lorsque nous détectons l'opportunité nous nous adressons à des clients qui ont déjà obtenu des résultats brillants grâce à notre conseil. l'ingénierie des systèmes, vers les développeurs avec lesquels nous collaborons dans un équilibre mutuel et dans le respect du métier et du professionnalisme respectifs.

Nous n'oserions jamais affirmer que le développement n'est pas important en termes de performance , contrairement à ceux qui, pour faire avancer leurs propres intérêts, n'hésitent pas à minimiser l'importance d'un hébergement optimisé et performant, ainsi que le rôle professionnel de l'administrateur système, improvisant ainsi avec des résultats pour le moins discutables.

Nous voulons juste souligner à quel point il est plus facile de passer de 6 secondes à 1,5 en dépensant (investissant) par exemple 50 ou 100 € par mois pour un site en phase embryonnaire qui doit encore obtenir les bons succès au niveau entrepreneurial et lucratif , plutôt que de se concentrer immédiatement sur le développement à des dizaines de milliers d'euros par an.

Strictement parlant, juste pour faire un point sur la situation désagréable qui s'installe maintenant dans le contexte de l'optimisation des performances et de la vitesse de WordPress, nous avons voulu écrire ce billet qui, bien qu'avec un soupçon de controverse authentique et pacifique, ne veut pas à autre chose que de représenter la réalité des cas que nous avons vécus (même malgré nous) à la première personne.

Voyons donc grossièrement comment se met en place une installation WordPress dans sa "complexité", dans laquelle on listera les principaux composants comme le Serveur (physique), le CMS (WordPress) qui s'appuie quant à lui sur PHP (côté interpréteur serveur) et le SGBD (MySQL).

Nous allons donc décomposer le problème en ses composantes individuelles : le serveur Web, PHP, MySQL et l’application WordPress développée par-dessus, en mentionnant les besoins et les indicateurs les plus récents dans les champs PageSpeed et Google Core Web Vitals , et en indiquant dans chaque cas quelle pourrait être la meilleure solution en termes de performance et de vitesse, aussi bien pour les sites lents déjà existants et donc déjà développés que pour les sites qui devront être conçus à partir de zéro.

Alors commençons.

Qu'est-ce que WordPress ?

WordPress est un plate-forme logicielle des "blog"Et système de gestion de contenu (SGC) open source c'est un programme qui, en tournant côté serveur, permet la création et la diffusion d'un site Internet formé par le contenu textuel o multimédia, gérable et actualisable en quelque sorte dynamique. Il a été initialement créé par Matt Mullenweg et distribué sous licence GNU General Public License. Il est développé en PHP avec le soutien de gestionnaire de base de données MySQL.

C'est le CMS le plus utilisé au monde

Selon W3TECHS (https://w3techs.com/technologies/details/cm-wordpress), il est actuellement utilisé par 65,1 % des sites web disposant d'un système de gestion de contenu connu. Cela représente 42,7 % de l'ensemble des sites web en ligne.

Inutile de vanter ses atouts désormais bien connus concernant la communauté, la facilité d'apprentissage, l'utilisation, les milliers de plugins pour tout faire, ce qui en fait le CMS le plus populaire de tous les temps.

Il convient de s'attarder sur les points faibles : WordPress n'est pas un système performant, léger et réactif . C'est au contraire un système extrêmement lent et lourd, principalement en raison des technologies sur lesquelles il a été développé : PHP et MySQL.

Le premier est un langage de programmation côté serveur obsolète développé depuis 1994, l'autre un SGBD relationnel qui, devant satisfaire certaines propriétés et particularités importantes des SGBD compatibles ACID, sont nécessairement lents par rapport aux solutions modernes.

Qu'est-ce que WooCommerce ?

WooCommerce est une extension WordPress téléchargeable qui vous permet de transformer votre site en une véritable boutique en ligne . Lancée en septembre 2011, WooCommerce est une plateforme en constante évolution , tant au niveau de ses fonctionnalités que de ses caractéristiques. Elle est utilisée par les commerçants, débutants comme experts, pour lancer une activité en ligne performante et vendre des produits ou des services.

WordPress est lent, car il est basé sur PHP

Le développement de ce langage de programmation a débuté en 1994, lorsque Rasmus Lerdorf créait des scripts CGI (Common Gateway Interface) en Perl pour mettre à jour régulièrement son site web. Ces petits outils effectuaient des tâches relativement simples et répétitives, comme l'affichage de son CV et le suivi du nombre de visiteurs sur sa page personnelle.

PHP n'a pas été initialement conçu, et encore moins développé, comme un langage de programmation autonome. Avec le temps et la croissance de la communauté de développeurs web l'utilisant, il a été décidé de systématiser l' ensemble des fonctions et scripts développés. Ce travail a abouti à la deuxième version de PHP/FI, publiée en novembre 1997.

PHP n'est pas le langage le plus rapide dans lequel nous pourrions écrire des applications Web, mais nous continuons à le faire pour de nombreuses autres raisons. La vitesse d'une langue est rarement le principal facteur décisif pour de nombreux projets. La productivité des développeurs, d'une part, est généralement plus importante. Et dans de nombreuses applications, les goulots d'étranglement ne seront pas dans le code de l'application ; c'est plutôt là que l'interaction avec d'autres systèmes a lieu. Par exemple, la communication avec les bases de données, les API et les files d'attente de messages prend du temps.

Alors pourquoi PHP est-il lent par rapport aux autres langages ? PHP est un langage dynamique et interprété. Cela signifie qu'il n'est pas compilé en langage machine mais plutôt lu au moment de l'exécution. PHP a également une architecture sans partage, donc à chaque demande, il interprète tout à partir de zéro. La conséquence en est que les performances ne sont pas aussi bonnes que pour les langages compilés, mais cela permet également des fonctionnalités que les langages compilables n'ont pas.

Ne pas avoir besoin de compiler PHP peut aider à la productivité des développeurs de plusieurs manières. Permet des boucles de rétroaction plus courtes pendant le développement - les résultats des modifications de code peuvent être visualisés immédiatement sans avoir à passer par les étapes de compilation au préalable. Il y a moins à se soucier de la récupération de place et de l'utilisation de la mémoire. Le débogage des erreurs d'exécution est plus facile car vous pouvez identifier directement où elles se produisent dans le code source. Il autorise également le code dynamique tel que les variables variables, les types dynamiques, etc., bien que vous deviez être prudent avec ceux-ci pour éviter de rendre votre application difficile à tester.

Cependant, tout cela fait de PHP un langage lourd et lent si on voulait le comparer à des langages asynchrones plus modernes comme GO ou Node.js qui contrairement à PHP sont des langages asynchrones et non bloquants et en fait plus performants que nous peut facilement voir à partir de l'image suivante.

MySQL est lent, car c'est un véritable SGBD relationnel avec des propriétés ACID.

Un autre composant fondamental sur lequel WordPress fonctionne est le serveur de base de données, dans tous les cas un serveur MySQL ou son fork et dérivé tel que MariaDB ou Percona Server.

MySQL satisfait pleinement aux exigences ACID pour un SGBDR transactionnel, comme suit :

Atomicité il est géré en stockant les résultats des instructions transactionnelles (les lignes modifiées) dans une mémoire tampon et en écrivant ces résultats sur le disque et dans le journal binaire à partir de la mémoire tampon uniquement une fois que la transaction a été confirmée. Cela garantit que les déclarations d'une transaction fonctionnent comme une unité indivisible et que leurs effets sont perçus collectivement ou pas du tout.
La cohérence il est principalement géré par les mécanismes de journalisation de MySQL, qui enregistrent toutes les modifications de la base de données et fournissent une piste d'audit pour la récupération des transactions. En plus du processus d'enregistrement, MySQL fournit des mécanismes de verrouillage qui garantissent que toutes les tables, lignes et index qui composent la transaction sont verrouillés hors du processus de démarrage suffisamment longtemps pour valider la transaction ou annuler.
Les variables sémaphores côté serveur et les mécanismes de blocage agissent comme des gestionnaires de trafic pour aider les programmes à gérer leurs propres mécanismes de trafic. isolation . Par exemple, le moteur InnoDB de MySQL utilise un verrouillage au niveau des lignes à granularité fine à cette fin.
MySQL implémente le durabilité maintenir un fichier journal des transactions binaire qui suit les modifications du système au cours d'une transaction. En cas de panne matérielle ou d'arrêt soudain du système, la restauration des données perdues est une tâche relativement simple utilisant la dernière sauvegarde en combinaison avec le redémarrage du système de connexion. Par défaut, les tables InnoDB sont 100% durables (en d'autres termes, toutes les transactions validées dans le système avant le crash peuvent être annulées pendant le processus de restauration), tandis que les tables MyISAM offrent une durée partielle.

Ce paradigme remonte à 1970, partiellement formalisé (ACD, l'isolation est venue plus tard) dans un article marquant de 1981 intitulé The Transaction Concept: Virtues and Limitations de Jim Grey et atteignant sa maturité en 1983 dans un deuxième article intitulé Principles of Transaction-Oriented Database Recovery , écrit par Andreas Reuter et Theo Härder.

Les bases de données relationnelles destinées à un usage OLTP – par exemple les moteurs de bases de données relationnelles produits par Oracle et Microsoft – ont été conçues , selon ce paradigme, en mettant l'accent sur la fiabilité et la cohérence des données gérées .

Cela en fait un SGBD vraiment puissant et stable capable de maintenir un état de cohérence des données, de ne pas les perdre ou de générer des erreurs lors de l'écriture ou de la lecture.

Les bases de données conformes à ACID sont souvent utilisées par les institutions financières telles que les banques ou les casinos et les systèmes critiques où les données doivent être intactes et cohérentes.

Une base de données compatible ACID ayant besoin d'offrir ces garanties devra nécessairement avoir des vérifications au niveau de la logique métier (logique applicative interne) ce qui la rendra nécessairement plus lente que les bases de données NOSQL de nouvelle génération que contrairement à un SGBD SQL Acide conforme sont juste suffisants pour lire et écrire des informations sans trop de fioritures.

En revanche, les bases de données non relationnelles garantissent généralement l'atomicité de chaque requête, quelle que soit sa complexité. Eric Brewer a forgé le terme BASE que les bases de données NoSQL doivent respecter :

Disponibilité de base: une réponse à chaque demande est garantie, qu'elle soit réussie ou non.
État doux: l'état du système peut évoluer dans le temps, même sans intervention de l'utilisateur.
Cohérence éventuelle: puisque vous avez état souple, il peut y avoir des cas d'incohérence, qui doivent être traités manuellement par le développeur.

Tout ceci démontre clairement que chaque fois qu'il est nécessaire de représenter dans une base de données un concept du monde réel contenant le mot « transaction » , à moins d'être suicidaire et de vouloir implémenter manuellement son propre mécanisme de gestion des transactions, le choix se porte nécessairement sur les bases de données relationnelles.

Laissant de côté le langage SQL standard ANSI, la normalisation des données et d'autres sujets extrêmement techniques et académiques (se souvenant du Buon Prof. Montesi du cours de bases de données à l'Université de Camerino), nous pouvons affirmer avec confiance qu'un CMS développé BIEN avec un conçu WELL sur un système NOSQL sera certainement plus rapide que la solution respective développée WELL sur un SGBD relationnel.

WordPress est lent car certains plugins sont lents.

L'un des cas standard que tout développeur WordPress aura rencontré au cours de sa carrière est celui d'avoir un site somme toute suffisamment performant et rapide jusqu'à l'installation d'un plugin qui a ruiné les performances de WordPress. site.

Ce scénario est très fréquent lorsque vous avez l'intention d'ajouter de nouvelles fonctionnalités et fonctionnalités au site, comme peut-être l'ajout d'un compteur de visiteurs trivial tel que Post View Counts, un système multilingue simple tel que WPML, ou un système de commerce électronique tel que WooCommerce ou même un système de sauvegarde tel que Updraft Update and Restore par exemple.

En réalité, la liste des plugins problématiques est très longue et une encyclopédie ne suffirait pas à tous les traiter correctement.

Qu'il suffise donc de penser que de nombreux Hébergeurs internationaux performants, dont nous, bien sûr, ont dressé une liste de plugins qu'il convient de déconseiller voire d'interdire, sous peine de voir le site et ses performances ralentir considérablement.

Nous ne suggérons en aucun cas que l'un de ces plugins non autorisés soit un "mauvais" plugin. Certains d'entre eux, comme les plugins de publication connexes, peuvent être parfaits pour la découverte du contenu. Cependant, en tant qu'hébergeur WordPress géré, notre principale préoccupation est de fournir l'expérience d'hébergement WordPress la plus rapide et la plus sécurisée possible. Il a été démontré que ces plugins ont un impact négatif sur les performances ou la sécurité de notre plate-forme et nous avons décidé d'empêcher leur utilisation.

En ce qui concerne les plugins dangereux, nous essayons de travailler avec le développeur du plugin pour les corriger. Pendant ce temps, le plugin peut être temporairement ajouté à notre liste d'utilisateurs non autorisés et nous serons heureux de l'autoriser à nouveau une fois le problème résolu.

Plugin de mise en cache

Les plug-ins de mise en cache peuvent entrer en conflit avec le cadre de mise en cache intégré de notre plate-forme. Ces plugins sont connus pour provoquer des conflits directs et, s'ils sont utilisés, auraient un impact sur la capacité de chargement de votre site :

WP Super Cache
Cache rapide WP

La plupart des fonctionnalités de mise en cache offertes par ces plugins sont intégrées par défaut à nos serveurs dans le cadre de votre expérience d'hébergement WordPress géré. Nous sommes là pour vous, ne vous inquiétez pas !

Plugin de sauvegarde

Nous ne recommandons pas l'utilisation de plugins de sauvegarde car ils surchargent inutilement votre site et peuvent stocker des fichiers de manière non sécurisée. Beaucoup de ces plugins exécutent également leurs tâches de sauvegarde à des moments inopportuns, ralentissant les requêtes MySQL et provoquant même des délais d'attente sur votre site.

Les solutions de sauvegarde suivantes ne sont pas des plug-ins autorisés :

Sauvegarde de la base de données WP : gonfle inutilement la mémoire locale de votre site.
Gestionnaire de bases de données WP : la sécurité .htaccess est recommandée, mais l'utilisation du stockage local est la principale préoccupation car elle n'offre qu'une option de stockage local.
SauvegardeWordPress - Dupliquer un grand nombre de fichiers dans le stockage local déjà présent dans nos sauvegardes.
VersionPresse - Pour fonctionner, ce plugin a besoin d'accéder à des fonctions au niveau du serveur que nous n'autorisons pas pour des raisons de sécurité.

Nous effectuons des sauvegardes nocturnes de tous les sites Web WordPress hébergés chez nous. Celles-ci sont effectuées de manière efficace et automatique, et les données sont stockées en toute sécurité sur un serveur distinct de votre installation WordPress. Nos sauvegardes automatiques ne comptent pas dans les limites de stockage local de votre plan et nous mettons ces sauvegardes à votre disposition pour que vous puissiez les restaurer, les copier ou les télécharger selon vos besoins.

Si vous préférez une sauvegarde secondaire hors site, nous autorisons par exemple VaultPress sur nos serveurs.

Plugin serveur et Thrashing MySQL

Ces plugins ne sont pas autorisés car ils provoquent une charge élevée sur le serveur ou créent trop de requêtes de base de données. Ils affecteront directement la charge du serveur et finiront par entraver les performances de votre site.

Link Checker brisé - Accable le serveur avec une très grande quantité de requêtes HTTP
MonPlugin d'examen - Gèle la base de données avec une quantité importante d'écritures.
Speaker - Tout comme MyReviewPlugin ci-dessus, LinkMan utilise une quantité non évolutive d'écritures de base de données.
Booster de référencement flou : cause des problèmes avec MySQL lorsqu'un site se développe.
WP PostViews : Écrit de manière inefficace dans la base de données à chaque chargement de page.
Tweet Mélangeur - N'interagit pas bien avec la mise en cache et peut augmenter la charge du serveur.

Pour un suivi du trafic plus évolutif, le module de statistiques du plugin Jetpack d'Automattic et Google Analytics fonctionnent tous deux parfaitement.

Nous vous recommandons d'utiliser l'un des outils suivants pour rechercher les liens brisés sur votre site. Comme ce ne sont pas des plugins, ils n'auront pas d'effet négatif sur les performances de votre site.

Articles connexes Plugins

Presque tous les plugins « Articles similaires » souffrent des mêmes problèmes d'indexation et de recherche MySQL. Ces problèmes rendent ces plugins extrêmement gourmands en ressources de base de données.

Ceux que nous avons purement et simplement interdits sont :

Publications connexes dynamiques
Liens automatiques de référencement et articles connexes
Yet Another Related Posts Plugin
Similar Posts
Articles liés au contexte

Il existe des services dédiés qui vous permettent de télécharger des fonctionnalités de publication connexes sur leurs serveurs. Au lieu de cela, nous vous recommandons de consulter l'un des services de messagerie associés :

Plugin de messagerie

Ce n'est pas parce que WordPress permet d'envoyer des e-mails que c'est forcément conseillé. Nous souhaitons que nos clients bénéficient de la même excellente expérience d'envoi d'e-mails que pour leur hébergement web ; c'est pourquoi nous recommandons l'utilisation d'un service tiers. Des services spécialisés comme MailChimp , Constant Contact , AWeber et bien d'autres proposent des solutions d'e-mailing complètes pour votre entreprise et vous garantissent des résultats optimaux.

Si le fournisseur de messagerie de votre domaine propose son propre serveur SMTP, vous pouvez le configurer en tant que serveur sortant. Assurez-vous de vérifier auprès de votre fournisseur de messagerie ses politiques de blocage du courrier, de courrier électronique et anti-spam avant de le faire.

Divers plugins

Les autres plugins que nous avons décidé de supprimer de manière proactive incluent :

Salut Dolly !
WP phpMyAdmin - Non autorisé en raison d'un problème de sécurité assez serieux. Nous offrons également un accès gratuit au plug-in phpMyAdmin depuis le vôtre Portail utilisateur .
Captcha doux - Après que nos partenaires Sucuri aient révélé que le service Sweet Captcha a été utilisé pour distribuer des logiciels publicitaires, nous avons décidé de suivre l'exemple de WordPress Plugin Repo et d'interdire complètement le plugin.
Carte d'accès numérique (DAP) - Bien que nous ne le supprimions pas activement des sites, veuillez noter qu'il ne fonctionnera pas correctement sur notre plate-forme en raison de l'utilisation de sessions PHP et cron à l'échelle du système. Au lieu de cela, vous voudrez utiliser l'un des autres plugins d'abonnement de premier plan comme Paid Memberships Pro , Restreindre le contenu o S2Member .

Scripts supplémentaires

Certains scripts fréquemment utilisés sont connus pour contenir des failles de sécurité. Notre plate-forme analyse périodiquement le système de fichiers pour identifier et corriger ou supprimer ces scripts.

TimPouce : Les versions précédentes de TimThumb sont connues pour contenir des vulnérabilités. Lorsque notre analyse du système identifie une version précédente, elle mettra automatiquement à jour le script. Une fois la mise à jour terminée, le système vous en informera par e-mail.
Mettre en ligne - L'accès à ce script est bloqué en raison de menaces de sécurité connues. Le raisonnement qui sous-tend cela a été largement éclairé par cet article de blog de nos partenaires à Sucuri.

Évidemment, la liste n'est pas exhaustive mais ne sert qu'à expliquer à quel point un plugin suffit à mettre un site WordPress à genoux. Par conséquent, vous devez toujours être prudent lors de l'installation d'un plugin en vous demandant si nous avons réellement besoin de cette fonctionnalité et si nous installons le meilleur plugin disponible pour implémenter cette fonction particulière.

Nous devrons peut-être utiliser un système multilingue, alors lequel choisir entre WPML, PolyLang et MultilingualPress ? Quels avantages, quels inconvénients, lequel installer ?

C'est la bonne approche que nous devons utiliser chaque fois que nous voulons ajouter une fonction via un plugin.

WordPress est lent, car les thèmes sont lents.

De la même manière que les plugins susmentionnés peuvent être lents, un thème peut également être plus rapide ou plus lent en fonction du thème et de la configuration de celui-ci. Il existe des thèmes extrêmement rapides avec quelques requêtes à la base de données et du code PHP très rapide, et d'autres extrêmement encombrants avec de multiples requêtes à la base de données (peut-être pour créer un menu) ce qui rend tout très complexe, redondant et donc lent.

Nous n'irons pas trop loin dans la discussion concernant les Thèmes WordPress puisqu'il y a peu à dire, si ce n'est qu'un système développé ad-hoc sera certainement plus rapide qu'un de ces nombreux thèmes General Purpose aux mille fonctionnalités inutiles que vous pourrez trouver sur les sites comme ThemeForest.

Si vous avez déjà un site en production avec un thème déjà mis en place et que vous ne voulez pas dépenser plusieurs milliers d'euros pour le développement d'un thème ad-hoc (budget au moins autour de 5000 - 10000 euros pour au moins quelques mois de travail par un développeur WordPress compétent), ne vous souciez pas de savoir comment optimiser le thème en cours d'utilisation en intervenant au niveau de l'application et essayez de résoudre le poids et la lenteur du site en intervenant sur d'autres points abordés dans ce post, notamment ceux côté serveur.

WordPress lent. mais qu'est ce que ça veut dire?

Expliquer ce que signifie WordPress lent peut avoir plusieurs interprétations. Cela dépend évidemment de l'étalon qui est utilisé et que par souci de concision on peut représenter avec deux entités distinctes : l'utilisateur et Google.

L'utilisateur qui a besoin d'un site web réactif et rapide bénéficie d'une expérience optimale, ce qui améliore le temps de chargement du site, réduit les taux de rebond et d'abandon de panier, et par conséquent augmente les conversions et les ventes. C'est la grande satisfaction de l'entrepreneur qui constate une hausse de son chiffre d'affaires et, vraisemblablement, de ses bénéfices.

Google mesure le site grâce à des tests automatisés, ainsi qu'à des données réelles envoyées à Google par les navigateurs Chrome (et uniquement par eux), et nous évalue à l'aide des Core Web Vitals modernes, simulant une connexion 3G lente, ce qui n'affecte actuellement qu'une petite partie des connexions réelles.

Google Page Speed Insights affiche des résultats basés sur deux appareils. Votre version de bureau de votre site Web et une version mobile.

Le test sur ordinateur de bureau permet de visualiser approximativement comment votre site sera affiché par un utilisateur se connectant depuis un ordinateur portable ou de bureau disposant d'une connexion internet généralement bonne.

Les tests sur appareil mobile permettront de voir comment votre site fonctionne lorsqu'il est consulté depuis un smartphone ou une tablette, généralement avec des vitesses plus lentes et moins de ressources.

Ce test mobile est volontairement effectué en simulant un réseau 3G limité rarement utilisé dans le monde numérique moderne. La plupart utilisent le test de Google pour vérifier rapidement leur site Web et n'ont aucune idée de la raison pour laquelle leurs sites Web semblent fonctionner si mal sur les appareils mobiles.

Jusqu'à récemment, il était courant de justifier cette pratique en conseillant aux utilisateurs de ne pas trop se soucier des résultats du test mobile Google PageSpeed Insights, car, en pratique, même un site affichant un score mobile très faible pouvait être rapide et se charger en moins de deux secondes. Cependant, suite à l'annonce de Google selon laquelle le score Core Web Vitals n'est plus un simple indicateur de vanité (contrairement à ce que certains développeurs, trop fiers et ignorants, voudraient encore nous faire croire), mais un facteur de classement et de positionnement, cette exigence doit désormais être prise en compte.

Partons d'un concept, cependant, comment se passe la visualisation d'une page Web lorsque nous écrivons, par exemple, https://www.wikipedia.org ?

Voici toutes les étapes que notre navigateur va faire de la requête à l'affichage du contenu qui peut être lu et aussi cliqué :

Demande de site en l'insérant dans la barre de navigation du navigateur.
Requête DNS au serveur de noms de notre fournisseur de connectivité qui demandera au DNS faisant autorité l'IP correspondante du nom de domaine wikipedia.org
Demande du vhost à l'IP qui nous a été renvoyée à l'étape 2
Le serveur Web accepte la requête et découvre que le navigateur demande une navigation en mode sécurisé HTTPS
Le serveur Web négocie la poignée de main SSL avec le client pour établir la connexion en mode sécurisé
Le serveur Web transmet la requête au gestionnaire du site en question, en l'occurrence un pool PHP qui devra créer des processus (s'ils ne sont pas déjà démarrés et en attente de requêtes) pour commencer à interpréter les fichiers PHP.
L'interpréteur PHP va lire les fichiers produisant un bytecode qui rappellera les différents fichiers WordPress, thèmes, plugins et requêtes associées à la base de données MySQL
La base de données recevra les centaines de Requêtes qu'elle exécutera plus ou moins efficacement, renvoyant un enregistrement de dataset plus ou moins volumineux qui sera ensuite traité par PHP.
PHP qui a reçu les données produira une mise en page HTML et CSS qui sera renvoyée au navigateur de l'utilisateur, y compris des images et du multimédia.
Le navigateur de l'utilisateur téléchargera les contenus statiques associés en un temps variable qui dépend du poids des données à télécharger et de la vitesse de téléchargement relative.
Le navigateur va reprendre la mise en page html et les feuilles de style pour tout recomposer en dessinant la page dans la structure que l'on va visualiser (rendu).

Comme nous l'avons vu, donc, derrière une visite très banale sur un site Internet, une série d'opérations inévitables s'instaurent qui peuvent pourtant être bien ou mal faites.

Prenons la liste ci-dessus et commençons à nous poser quelques questions si ce que nous faisons, nous le faisons de la meilleure façon.

Demande de site en l'insérant dans la barre de navigation du navigateur.
Utilisons-nous un navigateur moderne de dernière génération ? La connexion est-elle bonne ? Si nous venons de smartphones, profitons-nous d'une bonne couverture ? Sommes-nous en 5G, 4G ou 3G ? Avons-nous des limites de vitesse de téléchargement de notre fournisseur de téléphonie mobile ? Nous avons utilisé le protocole dans notre serveur Web TCP-BBR pour des connexions 3G lentes vous permettant de toujours utiliser leur débit maximum possible malgré leur lenteur ?
Requête DNS au serveur de noms de notre fournisseur de connectivité qui demandera au DNS faisant autorité l'adresse IP correspondante du nom de domaine de notre site.it
Le serveur de noms que nous utilisons comme serveur de noms faisant autorité pour oursite.it est-il rapide ? Combien de millisecondes faut-il pour renvoyer la bonne adresse IP au système d'exploitation de notre smartphone ? Pourquoi n'utilisons-nous pas un DNS Anycast peut-être sur un fournisseur tiers spécialisé tel qu'Amazon Route 53 ou CloudFlare DNS ?
Demande du vhost à l'IP qui nous a été renvoyée à l'étape 2
Le serveur Web accepte la requête et découvre que le navigateur demande une navigation en mode sécurisé HTTPS
Quel serveur Web utilisons-nous ? À quelle vitesse accepte-t-il une connexion ? Comment se comporte-t-il face à plus de 10 XNUMX connexions par seconde ? Quel est l'impact sur le CPU et la mémoire ? Travaillez-vous sur des processus ? Un fil ? Utilisons-nous le très rapide NGINX ou l'ancien et très lent Apache ?
Le serveur Web négocie la poignée de main SSL avec le client pour établir la connexion en mode sécurisé
Quels protocoles SSL utilisons-nous et quel type de cryptage voulons-nous utiliser pour établir les connexions ? Quel type de certificat SSL utilisons-nous ? Voulons-nous également aborder les anciens systèmes d'exploitation avec Windows Vista, Windows XP, Android 7 et les anciennes versions de MacOS El Captain ? Peut-être que Let's Encrypt n'est pas bon et que nous devons adopter un certificat DV commercial pour satisfaire tout le monde et ne pas avoir d'erreurs de connexion.
Le serveur Web transmet la requête au gestionnaire du site en question, en l'occurrence un pool PHP qui devra créer des processus (s'ils ne sont pas déjà démarrés et en attente de requêtes) pour commencer à interpréter les fichiers PHP.

Combien de temps faut-il au serveur Web pour accepter la connexion ? Combien de temps faut-il au serveur web pour activer le processus PHP correspondant à la requête ? Le processus PHP doit-il être démarré à partir de zéro ou le processus PHP est-il déjà en mode veille et pouvons-nous économiser le temps de démarrage du processus ? Si nous utilisons PHP-FPM, quel type de mode utilisons-nous ? à la demande, statique, dynamique ? Avec quelles limites et dans quels contextes ?
L'interpréteur PHP va lire les fichiers produisant un bytecode qui rappellera les différents fichiers WordPress, thèmes, plugins et requêtes associées à la base de données MySQL
Nous devons lire le fichier en accédant au disque. Quelle est la vitesse du lecteur? Devons-nous écrire sur le disque que nous avons effectué une opération de lecture de fichier ou pouvons-nous l'ignorer car ce sont des données superflues qui ne feraient que nous faire perdre du temps à écrire sur le disque ? Devons-nous nécessairement relire et exécuter le code interprété à chaque fois que nous appelons index.php ou pouvons-nous utiliser un bytecode précompilé à mettre dans un cache pour augmenter les performances via OpCache ? À quelle fréquence devons-nous vérifier si les fichiers ont changé et régénérer le nouveau bytecode mis à jour ?
La base de données recevra les centaines de Requêtes qu'elle exécutera plus ou moins efficacement, renvoyant un enregistrement de dataset plus ou moins volumineux qui sera ensuite traité par PHP.
Utilisons-nous un cache au niveau du SGBD ? Les tables ont-elles des index ? Existe-t-il des chrones fonctionnant au niveau de WordPress ? Y a-t-il des transitoires périmés ou inutiles ? Avons-nous des jeux d'enregistrements géants renvoyés par des plugins/thèmes non optimisés ?
PHP qui a reçu les données produira une mise en page HTML et CSS qui sera renvoyée au navigateur de l'utilisateur, y compris des images et du multimédia.
Quelle est la vitesse du serveur Web ? Nous utilisons le contenu compressé JS et CSS avec compression gzip ou mieux Brotli ?
Le navigateur de l'utilisateur téléchargera les contenus statiques associés en un temps variable qui dépend du poids des données à télécharger et de la vitesse de téléchargement relative.
Les contenus statiques tels que les images utilisent des systèmes de compression tels que images webp au lieu du lourd png, jpg, jpeg ? Au cas où nous utilisions un cache statique comme Varnish, les images devraient-elles être mises en cache dans la RAM ou servies directement à partir du disque ? Peut-on utiliser HTTP/2 ou HTTP/3 pour améliorer le parallélisme des téléchargements sans utiliser l'ancien sharding de damain ? Le contenu de notre site est-il d'intérêt national ? Peut-on et doit-on utiliser un CDN comme Cloudflare ? Avec quels pros ? Avec qui contre ? Pouvons-nous utiliser des images webp de manière conditionnelle avec CloudFlare en fonction du navigateur compatible ou non, sans avoir à utiliser leur plan d'affaires à site unique de 200 $ par mois ?
Le navigateur va reprendre la mise en page html et les feuilles de style pour tout recomposer en dessinant la page dans la structure que l'on va visualiser (rendu).
Une page de 2000 pièces est plus lente à rendre qu'une page de 100 pièces, tout comme un puzzle de 2000 pièces est plus complexe à compléter qu'un puzzle de 100 pièces.
Sommes-nous sûrs de n'utiliser pas un trop grand nombre d'éléments ? Sommes-nous sûrs de ne pas avoir à télécharger des styles CSS qui ne sont pas utilisés sur la page que nous examinons ? Sommes-nous sûrs d'avoir paramétré les temps de cache côté navigateur de manière intelligente pour éviter d'avoir à retélécharger des éléments non modifiés comme le logo de la page à chaque visite ? Est-il judicieux d'attendre que vous ayez chargé toutes les ressources telles que les images, les polices, les feuilles de style et le javascript, puis de commencer le rendu de la page ou pouvons-nous commencer dès que possible et continuer plus tard pendant que l'utilisateur visualise déjà quelque chose sur le site ? Peut-on éviter le « scintillement » de la mise en page, ce scintillement et essayer de ne pas le recomposer de manière gênante sous les yeux de l'utilisateur ?

Pour chaque point que nous avons répertorié (12), nous avons des problèmes (plus ou moins importants et sérieux) et des solutions relatives à ceux-ci.

Bref, accélérer un site WooCommerce, c'est analyser tous ces aspects (ou du moins les plus importants) et réaliser des opérations qui peuvent résoudre ou améliorer considérablement le temps perdu pour chaque opération.

Les opérations diffèrent principalement dans deux macro-catégories, les optimisations côté serveur et les optimisations côté application.

Voyons ensemble comment les deux branches se divisent et comment elles peuvent parfois se chevaucher en partie.

Optimisation côté serveur.

Par optimisation des performances côté serveur, nous entendons toutes les opérations et fonctionnalités qui concernent l'aspect matériel et logiciel du côté système, qui doivent être traitées par un ingénieur système Linux verticalisé spécialisé dans les performances.

Optimisation et dimensionnement du matériel

Par exemple, un ingénieur système Linux spécialisé sur les performances WooCommerce aura le bon sens de savoir dimensionner les ressources matérielles et le serveur sur la base d'un excellent compromis entre coûts/performances et les réelles possibilités d'investissement et de dépenses du client.

Certes il optera pour le bon dimensionnement du CPU, le nombre de cœurs, le nombre de threads, la bonne quantité de mémoire RAM, la technologie des disques SSD ou mieux encore nVME pour maximiser la vitesse d'E/S sur les disques, et donc aussi sur la base de données MySQL par exemple.

Il s'occupera également de mettre en place les bons composants logiciels côté serveur afin que le matériel soit utilisé au mieux et/ou que les problèmes connus de WooCommerce plutôt que d'autres CMS puissent être résolus avec des solutions de contournement et des correctifs pouvant nécessiter l'installation et la configuration de logiciels supplémentaires à des fins très spécifiques.

Normalement, les options et les opérations relèvent toujours du choix du bon service, de la bonne configuration et de la bonne intégration avec WooCommerce.

Optimisation du réseau et du noyau

Cela vous permettra de vous assurer que vous avez correctement implémenté et configuré TCP BBR pour améliorer les connexions lentes ou présentant une perte de paquets élevée, telles que les connexions 3G, comme vous pouvez le lire dans cet article : TCP BBR : la formule magique pour les performances réseau.

Installation d'un Serveur Web léger et rapide

Il se chargera d'installer un serveur web léger et extrêmement performant tel que NGINX Webserver plutôt que le plus populaire Apache.

Le marché est désormais mature et la suprématie de NGINX est enfin reconnue avec une tendance extrêmement croissante et une diffusion toujours plus grande.

Pour en savoir plus sur les performances, les benchmarks, ainsi que sur d'autres fonctionnalités et comparaisons intéressantes, nous vous invitons à consulter cet article : Apache VS NGINX. Quel est le meilleur serveur web ?

En fait, si vous voulez aller à l'essentiel, vous vous rabattez toujours sur l'utilisation de systèmes logiciels et de Cache pour les différents composants.

Cache de réglage de MySQL ou dans tous les cas de la base de données en tant que cache de pool de tampons InnoDB

InnoDB (le moteur plus performant de MySQL que MyISAM) maintient une zone de stockage appelée Buffer Pool pour la mise en cache des données et des index en mémoire. Connaître le fonctionnement du Buffer Pool et l'utiliser pour conserver en mémoire les données fréquemment consultées est un aspect important de l'optimisation MySQL.

L'optimisation des bases de données MySQL est l'une des tâches d'optimisation les plus importantes pour les performances web. Lors de l'optimisation de MySQL, vous rencontrerez inévitablement des problèmes avec InnoDB.

InnoDB est sans aucun doute le moteur MySQL le plus performant en matière de traitement des requêtes de type SELECT. Sa configuration comprend plusieurs paramètres, dont innodb_buffer_pool_size.

Le pool de mémoire tampon InnoDB indique la taille de la RAM à consacrer au stockage des index, des caches, des structures de données et de tout ce qui est lié à InnoDB.

Il s'agit de l'un des paramètres les plus importants de la configuration MySQL et sa valeur doit être définie en fonction de la quantité de RAM disponible et des services exécutés sur le serveur.

Cache de bytecode PHP comme Zend OpCache

L'un des plus gros problèmes avec les sites Web est le temps de chargement. L'un des meilleurs moyens de réduire le temps de chargement est d'activer les systèmes de mise en cache. Il n'y a pas que le cache de fichiers HTML, OpCache est en fait un cache opcode, qui augmente la vitesse des sites Web PHP en stockant des scripts bytecode précompilés dans la mémoire partagée.

La mise en cache des scripts PHP signifie que la première fois que le script est exécuté, il est également précompilé et enregistré en mémoire. Chaque fois que le script est appelé, il ne sera pas nécessaire de l'exécuter à nouveau car opcache a stocké le code résultant dans la mémoire RAM. Ce gain de temps vous apporte des améliorations de performances, en particulier sur les sites Web constamment soumis à un stress.

La définition officielle dit :

OPCache améliore les performances de PHP en stockant un script bytecode précompilé dans la mémoire partagée, éliminant ainsi le besoin pour PHP de charger et d'analyser les scripts pour chaque requête.

Autrement dit, lorsqu'un script PHP est exécuté, il est compilé en opcode, du code lisible par machine. OPCache stocke ce code en mémoire lors de la première exécution afin de le réutiliser ultérieurement. La mise en cache PHP permet ainsi d'améliorer les performances. OPCache remplace APC et constitue une alternative à XCache, un accélérateur PHP. Contrairement à Memcached, qui fonctionne au niveau de la base de données, OPCache fonctionne au niveau des scripts PHP.

Cette extension est fournie avec PHP 5.5.0 et supérieur, et est disponible dans PECL pour les versions PHP 5.2, 5.3 et 5.4.

Fondamentalement, lorsque le système compile du code en PHP, le code lisible par l'homme est converti en langage machine et il faut du temps pour compiler tous les scripts. Ainsi, si l'application effectue de nombreuses requêtes de manière cyclique, les performances pourraient être améliorées en mettant en cache les différents scripts. En activant PHP OPcache, le processus s'exécutera une fois et mettra en cache tous les scripts. Les scripts seront stockés en mémoire et seules les mises à jour seront compilées et continueront d'être archivées.

OPCACHE peut considérablement améliorer les performances et réduire significativement le temps de chargement des sites web . Par défaut, OPcache pour PHP 7 utilise 64 Mo de mémoire. Aucune bibliothèque externe n'est requise pour activer cette extension.

Cache d'objets WordPress

Le cache d'objets WordPress est un mécanisme côté code permettant de réduire les requêtes à la base de données et d'améliorer les temps de chargement et les performances du site. Défini dans le fichier principal wp-includes/cache.php , il peut être utilisé via un ensemble de fonctions prédéfinies, similaires à celles disponibles pour les données transitoires. Il s'en distingue par sa fonction de stockage de données pour la mise en cache, une fonctionnalité toutefois indisponible chez tous les hébergeurs et qui, surtout, nécessite un plugin de cache pour fonctionner.

Il s'agit d'une fonctionnalité avancée que peu de développeurs connaissent et utilisent activement, mais dont de nombreux plugins de mise en cache et d'optimisation s'appuient. Par défaut, le cache d'objets WP n'est pas persistant et ne dure généralement que le temps de la requête HTTP en question. Il n'est donc pas conservé pour une utilisation ultérieure, sauf si vous installez un plugin dédié (recommandé : W3 Total Cache). Nous parlons ici de mise en cache côté serveur, et non côté client ; évitons toute confusion à ce sujet dès le départ.

Le principal avantage de l'utilisation du cache à ce jour est lié à l'amélioration des performances des temps de chargement du site, s'il n'est pas possible d'intervenir autrement.

Le but de la mise en cache des objets est de mettre en cache les résultats des requêtes à partir de la base de données.

Une base de données efficace est l'un des facteurs cruciaux pour un site web rapide : WordPress est un système de gestion de contenu qui dépend naturellement de sa base de données MySQL.

Chaque fois que les utilisateurs (ou les robots) font une demande sur votre site Web, ils génèrent des requêtes de base de données. Si votre site reçoit un grand nombre de requêtes de base de données, les requêtes peuvent s'accumuler rapidement, surcharger votre serveur MySQL et ralentir votre site Web.

La bonne nouvelle, c'est que WordPress a introduit sa classe de mise en cache d'objets il y a longtemps : c'est en 2005 que la classe appelée WP_Object_Cache a été implémentée dans le noyau de WordPress.

Normalement, vous pouvez utiliser Memcached ou REDIS.IO comme backend pour effectuer le stockage de données de cache d'objets.

Cache de page, alias cache de page WordPress.

Memcached est l'un des mécanismes de mise en cache qui résident sur votre serveur d'hébergement. Il traite principalement des requêtes de base de données qui aident à réduire la charge de la base de données, ce qui entraîne un chargement rapide de la page Web. Si votre site Web / magasin repose fortement sur des requêtes de base de données, l'utilisation de Memcached pour votre site Web WordPress améliorerait considérablement les performances et réduirait le temps de chargement des pages.

Les géants de l'Internet, notamment YouTube, Reddit, Facebook, Twitter et Wikipedia, utilisent Memcached pour augmenter le temps de chargement des pages. Google App Engine, Microsoft Azure, IBM Bluemix et Amazon Web Services proposent également le service Memcached via une API.

Compte tenu de son importance dans l'amélioration et la diminution du temps de chargement des pages, nous proposons Memcached pré-installé sur nos serveurs d'hébergement WordPress gérés. Cependant, vous devrez parfois configurer votre application (WordPress) pour tirer pleinement parti de Memcached.

Memcached est utilisé pour accélérer les applications Web dynamiques telles que les magasins de commerce électronique, les sites Web d'inscription / connexion, etc. réduire la charge de la base de données. Il stocke le résultat traité afin que chaque fois qu'un visiteur demande à nouveau la même requête, Memcached puisse y répondre au lieu de traiter la requête et de répondre. En gardant le serveur moins occupé, vos visiteurs bénéficieront d'un temps de chargement plus rapide et d'une meilleure expérience utilisateur.

Vous trouverez sur GitHub une histoire vraie amusante et intéressante ; allez- y jeter un œil pour comprendre un cas d’utilisation typique de Memcached.

Cache statique pleine page tel que Varnish Cache, NGINX FastCGI Cache, LsCache ou CloudFlare Cache

Assurément la pleine page statique côté serveur est la composante la plus appréciable en terme de performances pour des contenus qui sont "les mêmes pour tout le monde", c'est à dire ceux d'un blog, d'un journal ou d'un ecommerce comme WooCommerce si vous n'êtes pas connecté.

En effet, un cache pleine page statique permet de stocker le contenu d'une page statique et de le proposer à ceux qui l'ont demandé sans aller exécuter PHP et interroger la base de données MySQL, économisant ainsi des cycles machine importants et permettant ainsi comme nous l'avons vu dans dans certains cas, chargement unique de 12 secondes à 1 seconde en mettant simplement en cache correctement avec Varnish ou NGINX FastCGI Cache.

Évidemment ce n'est pas la panacée à tous les maux, car si le site est lent, une fois que l'utilisateur décide de se connecter peut-être pour avoir une liste de prix réservée, voici où le site commence à aller à la vitesse réelle de la façon dont il aurait été sans cache.

Mais être déjà en mesure d'obtenir une excellente vitesse lorsqu'il n'est pas connecté, ce qui se produit dans la plupart des magasins de commerce électronique où vous vous connectez uniquement à la caisse, signifie faire la différence entre un commerce électronique qui a facturé des centaines de milliers d'euros à la fin de l'année et un commerce électronique qui ferme le budget avec peu de changement.

Les solutions les plus populaires actuellement sur le marché sont : Varnish Cache, dont nous avons longuement parlé ici (Varnish Hosting) , NGINX FastCGI Cache, qui est selon nous un moyen rapide et facile d’utiliser un cache de page complète si vous ne disposez pas des compétences nécessaires pour utiliser correctement Varnish et son langage de configuration VCL, LsCache, un cache relativement récent qui convient parfaitement au serveur web LiteSpeed ou à sa version gratuite Open LiteSpeed, et CloudFlare Cache.

LsCache

En ce qui concerne LsCache, nous pouvons dire que c'est un produit limité et limitatif qui n'est bon que sur le serveur Web commercial LiteSpeed, il n'a pas de langage de programmation interne pour pouvoir travailler avec des règles très élaborées et donc c'est bien si vous le faites ne pas avoir de besoins particuliers tels que ceux de séparer le cache en fonction du cookie, de l'agent utilisateur et de beaucoup d'autres choses très intéressantes que LSCache ne fait pas.

Cache NGINX FastCGI

Le cache FastCGI de NGINX serait également prometteur si certaines de ses fonctionnalités (voir par exemple la possibilité de PURGER TOUT pour vider l'intégralité du cache) n'étaient pas uniquement présentes dans la version commerciale Nginx Plus ou NGINX+, ce qui n'est certainement pas attractif en termes de coûts pour l'abonnement commercial annuel.

Comme déjà mentionné pour LSCache, NGINX FastCGI Cache ne dispose pas non plus de langage de configuration qui vous permette d'effectuer des exercices de compétences techniques et de style pour atteindre les objectifs les plus complexes et de mise en cache.

Cache CloudFlare

CloudFlare Cache est un service commercial de logiciel en tant que service qui implique plusieurs plans à abonnement allant du plan gratuit au plan d'entreprise de 200 $ par mois pour un seul site.

Par défaut, CloudFlare n'offre pas de cache de page complet, c'est-à-dire qu'il ne met pas réellement en cache le HTML tel que les pages, les articles, les produits, mais met uniquement en cache les ressources multimédias telles que les images, JS et CSS. Pour obtenir les fonctions de mise en cache HTML, il faut avoir la possibilité d'exclure les cookies et travailler avec l'abonnement de 200$ par mois pour chaque site.

Comme mentionné dans l'introduction, le coût peut tout à fait être abordable, voire économique, pour les entreprises déjà consolidées et capables de réaliser un profit proportionnel à l'investissement dans ce service désormais leader sur le marché, qui comprend de nombreuses options telles que la protection contre les attaques DDoS.

Cependant, nous avons remarqué qu'il y a souvent de la confusion et même les hébergeurs et les experts du secteur le font, estimant que le plan gratuit agit comme Full Page Cache, et donc voici l'essor des sociétés d'hébergement qui annoncent un CDN impliquant une pleine page. et vous invitent à acheter leur solution d'hébergement la plus chère en annonçant la disponibilité de CloudFlare qu'ils installent dans la version gratuite et que ne pas avoir la fonctionnalité Full Page Cache n'améliore en rien votre vitesse.

Si vous souhaitez en savoir plus sur cette erreur majeure, consultez cet article : Cache HTML du CDN CloudFlare ?

Vernis Cache

Un cache statique côté serveur diront certains, il serait plus correct de dire le cache statique. Utilisé par les sites les plus fréquentés et les plus populaires au monde, c'est également le seul cache statique côté serveur qui, même dans la version gratuite, inclut pratiquement toutes les fonctions nécessaires pour créer des règles de mise en cache complexes dans le monde réel.

Certaines lacunes que l'on trouve exclusivement dans la version commerciale de Varnish Plus peuvent être judicieusement comblées en utilisant de manière experte les configurations ad-hoc du serveur Web NGINX en "combo".

Probablement sans des centaines d'heures passées à développer les meilleures configurations Varnish et Combo, nous serions aujourd'hui l'un des nombreux hébergeurs et nous n'aurions pas obtenu les chiffres et les succès qui nous ont permis d'atteindre des centaines de millions de pages vues par mois et des pics de des centaines de milliers d'utilisateurs par minute sans plantage.

Si vous souhaitez en savoir plus sur Varnish, nous vous recommandons de lire ceci : Hébergement WordPress pour les journaux et l’édition en ligne.

Quelle que soit la solution que vous souhaitez adopter (nous recommandons TOUJOURS Varnish) ou CloudFlare pour le trafic intercontinental, ces solutions doivent toujours être configurées de manière appropriée ad hoc pour votre installation WooCommerce. En effet, il faut pouvoir gérer et exclure les cookies de session, certaines pages spécifiques comme celles réservées à l'utilisateur, le panier, la caisse, la wishlist afin d'éviter des collisions de pages gênantes, c'est à dire que l'utilisateur A arrive au panier et voit les produits placés dans le panier de l'utilisateur B, et de même d'autres visiteurs commencent à voir du contenu qui n'est pas le leur.

Tout cela se traduit évidemment par un abandon de panier et une perte de chiffre d'affaires et de chiffre d'affaires.

Les fichiers XML, les plans de site, les flux Google, les délais d'attente si nous travaillons avec un logiciel d'importation d'entrepôt et bien d'autres choses doivent être gérés.

On dirait à l'utilisateur novice : « J'installe Varnish et je le configure », mais cela finit toujours par créer des dégâts aux proportions gigantesques, il est donc toujours préférable de s'appuyer sur ceux comme nous qui ne vivent que de ça.