4 janvier 2022

Accélérez WooCommerce et WordPress. Comment augmenter la vitesse d'un site.

Astuces et principales techniques à utiliser pour la rapidité d'un site WordPress

Bannière d'hébergement WooCommerce

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 pouvoir vous démêler parmi les milliers d'offres d'experts autoproclamés qui essaient chaque jour de vous vendre des services de Vitesse de WordPress ou des services de accélérer WordPress comme certains l'appellent.

Attention : la suite de l'article est plutôt technique et peut-être pas adaptée à l'entrepreneur qui excelle dans tout autre chose dans la vie et qui se retrouve un site lent et qui a pour seule envie de le rendre rapide. Si vous préférez ne pas vous plonger dans des terminologies étranges, telles que cache, TCP BBR, Above the Fold, Critical Css et plus encore, nous vous encourageons à contactez-nous directement dans la rubrique 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'écrit, par exemple, une personne bien connue et très bien préparée Développeur WordPress sur son site à propos de nous, ingénieurs système.

Vitesse de WordPress

Ce que ce monsieur ci-dessus oublie évidemment de mentionner, c'est que l'entreprise avec laquelle nous avons travaillé ensemble il est passé d'un chargement de page d'environ 6 secondes à 1,5 seconde UNIQUEMENT et exclusivement grâce à un réglage système habile du côté serveur et seulement alors une amélioration supplémentaire de l'ordre d'une demi-seconde rare, grâce à une approche de développement ad hoc très coûteuse coûtant quelque chose comme des dizaines et des dizaines de milliers d'euros par an tel que rapporté par le PDG d'une entreprise que nous omettons pour l'exactitude et la confidentialité de 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.

On ne songera jamais à dire que le développement n'est pas important en termes de performance, contrairement à ceux qui, pour apporter de l'eau à leur moulin, n'hésitent pas à minimiser l'importance d'un hébergement optimisé et performant, ainsi que la figure professionnelle de l'ingénieur système, s'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).

Architecture de serveur WordPress PHP MySQL

Nous allons donc nous occuper de décomposer le problème en composants uniques : Le serveur Web, PHP, MySQL, et l'application WordPress développée au-dessus, en citant les derniers besoins et métriques dans le domaine PageSpeed ​​​​et Google. Vitaux Web de base, indiquant dans tous les cas quelle pourrait être la meilleure solution en termes de performances et de vitesse aussi bien pour des sites lents déjà existants et donc déjà développés, que pour des sites qui devront être conçus de toutes pièces.

Alors commençons.

Qu'est-ce que WordPress ?

Outils de gestion est un plate-forme logicielle des "article"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 actuellement il est utilisé par 65,1% de tous les sites Web pour lesquels nous connaissons le système de gestion de contenu. Cela représente en fait 42,7% de tous les sites Web en ligne.

Statistiques WordPress de diffusion

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.

Nous devrions nous concentrer sur les douleurs connues, c'est-à-dire WordPress n'est pas un système performant, léger et rapide. WordPress est au contraire un système extrêmement lent et encombrant, dérivé principalement 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 un plugin téléchargeable dans WordPress, ce qui vous permet de transformer votre site en un vrai boutique virtuelle. Lancé en septembre 2011, WooCommerce est l'un des plate-forme constamment amélioré et mis à jour, à la fois en termes de fonctionnalités et de fonctionnalités. Utilisé par les commerçants, débutants ou experts, pour démarrer une entreprise de vente en ligne hautement professionnelle de produits ou de services.

WordPress est lent, car il est basé sur PHP

Le développement de ce langage de programmation a commencé en 1994, lorsque Rasmus Lerdorf luttait avec la création de scénario Interface de passerelle commune (« Interface commune pour la passerelle » en italien) en Perl à utiliser pour les mises à jour périodiques de son site Web. Ces petits outil ils ont effectué des tâches simples et répétitives, telles que montrer son curriculum vitae et enregistrer le nombre de visiteurs sur sa page personnelle.

Initialement, PHP n'était pas destiné - encore moins conçu - à être un langage de programmation à part entière. Au fil du temps, et avec la croissance de la communauté de développeurs web qui l'utilisaient, il a été décidé de systématiser le corpus de fonctions et de scripts créés. De ce travail est née la deuxième version de PHP/FI, lancé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 s'exécute est le serveur de base de données, dans tous les cas un serveur MySQL ou sa fourche et son dérivé comme MariaDB o Serveur Percona.

MySQL est entièrement conforme à i Exigences ACID pour un SGBDR sécurisé pour les transactions, 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.

SGBD ACID

Ce paradigme remonte à 1970, en partie formalisé (ACD, l'isolement est venu plus tard) dans un article historique de 1981 intitulé Le concept de transaction : vertus et limites da Jim Gray et devenir mature en 1983 dans un second document intitulé Principes de la récupération de base de données orientée transaction, écrit par Andréas Reuter e Théo Härder.

Bases de données relationnelles à usage OLTP - on cite par exemple les moteurs de bases de données relationnelles produits par Oracle et Microsoft - ils ont été conçus en plaçant au centre la fiabilité et la cohérence des données gérées, selon ce paradigme.

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.

D'autre part, les bases de données non relationnelles garantissent généralement l'atomicité sur une seule instruction, quelle que soit sa complexité. Cet Eric Brewer a inventé 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 cela montre clairement qu'à chaque fois qu'il est nécessaire de représenter sur une base de données un concept du monde réel qui contient le mot transaction, à moins que vous ne soyez suicidaire et que vous souhaitiez implémenter à la main leur propre mécanisme de gestion des transactions, le choix se porte forcément 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 vous sentez plus en sécurité avec une sauvegarde secondaire hors site, permettons 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 suivre le trafic de manière plus évolutive, le module de statistiques du plug-in jetpack d'Automatic que Google Analytics ils travaillent très bien.

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 plug-ins « Related Posts » souffrent des mêmes problèmes que MySQL, l'indexation et la recherche. Ces problèmes rendent les plugins  extrêmement  base de données intensive.

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 toujours parce que vous pouvez envoyer des e-mails avec WordPress que vous devriez le faire. Nous voulons que nos clients bénéficient de la même meilleure expérience de messagerie que celle que nous proposons avec l'hébergement Web, nous vous recommandons donc d'utiliser un service tiers. Des services spécialisés tels que  MailChimp ,  Constant Contact ,  AWeber et d'innombrables autres offrent des solutions de messagerie complètes pour votre entreprise et vous fourniront 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 Adhésions payées 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'avoir un site responsive et rapide pour profiter d'une expérience utilisateur (ou user experience) satisfaisante qui améliore le séjour sur le site, réduit les taux de rebond, les abandons de panier et donc améliore les conversions et les ventes pour le bonheur de l'entrepreneur qui voit une augmentation du chiffre d'affaires et vraisemblablement aussi des bénéfices.

Google qu'en mesurant le site grâce à des tests automatisés, ainsi qu'à des données réelles sur le terrain qui sont envoyées à Google par les navigateurs Chrome (et seulement eux), nous nous pesons et nous évaluons grâce à des méthodes modernes Vitaux Web de base simulant une connexion 3G lente qui concerne aujourd'hui une petite partie des connexions réelles.

Google Page Speed Insights affiche les résultats sur la base de deux appareils. Votre version de bureau de votre site Web et une version mobile.

Le test effectué sur la version desktop montre plus ou moins comment votre site sera vu par un utilisateur visitant son ordinateur portable ou de bureau avec des vitesses Internet généralement bonnes.

Tests effectués sur un appareil mobile ils montreront comment votre site fonctionne lorsque vous vous connectez à partir d'un smartphone ou d'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.

Si jusqu'à il y a quelque temps il était courant de se justifier en disant au client final de ne pas trop se soucier de ce que dit le test mobile de Google PageSpeed ​​Insight, étant donné qu'à un niveau de navigation réel, même un site avec un mobile gravement insuffisant le score peut être très rapide en réalité et se charger en moins de deux secondes, il est également vrai qu'avec l'annonce Google que le score Vitaux Web de base n'est plus une métrique de vanité (comme certains développeurs trop fiers et ignorants veulent encore nous le faire croire) mais un facteur de classement et de positionnement, il faut aujourd'hui aussi satisfaire ce besoin.

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é :

  1. Demande de site en l'insérant dans la barre de navigation du navigateur.
  2. 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
  3. Demande du vhost à l'IP qui nous a été renvoyée à l'étape 2
  4. Le serveur Web accepte la requête et découvre que le navigateur demande une navigation en mode sécurisé HTTPS
  5. Le serveur Web négocie la poignée de main SSL avec le client pour établir la connexion en mode sécurisé
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.

  1. 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 ?
  2. 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 ?
    DNS Benchmark
  3. Demande du vhost à l'IP qui nous a été renvoyée à l'étape 2
  4. 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 ?
  5. 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.
  6. 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 ?
  7. 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 ?
  8. 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 ?
  9. 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 ?
  10. 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 ?
  11. 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

Il s'assurera que vous avez correctement implémenté et configuré TCP BBR pour améliorer les connexions lentes ou à forte perte de paquets telles que les connexions 3G, comme vous pouvez le lire dans cet article. BBR TCP : la formule magique pour la performance du 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.

Concernant les performances et les benchmarks ainsi que d'autres fonctionnalités et comparaisons intéressantes, nous vous renvoyons à cet article : Apache contre 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 de la base de données MySQL fait partie des réglages les plus importants en termes de performances Web. Quand il s'agit d'optimiser MySQL, vous vous y heurtez irrémédiablement 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.

Pool de tampons InnoDB indique la taille de la RAM à consacrer au stockage des index, des caches, des structures de données et tout ce qui tourne autour d'InnoDB.

C'est 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 qui opèrent sur le serveur.

Cache de bytecode PHP comme Zend OpCache

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.

En d'autres termes, lorsqu'un script PHP est exécuté, il est compilé en opcode, un code compréhensible par la machine. OPCache stocke ce code en mémoire lors de la première exécution pour une réutilisation ultérieure. Le cache PHP conduit ainsi à des augmentations de performances. OPCache remplace APC et est une alternative à XCache, un accélérateur PHP. Contrairement à Memcached qui fonctionne sur la base de données, Opcache fonctionne sur 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 vous donner une amélioration notable des performances et peut réduire considérablement le temps de chargement du site Web. PHP7 OPcache utilise 64 Mo de mémoire par défaut. Aucune bibliothèque externe n'est nécessaire pour activer cette extension.

Comment fonctionne Zend OpCache

Cache d'objets WordPress

Cache d'objets WordPress

Le cache d'objets de WP (object cache) est un mécanisme côté code utilisé pour réduire les accès à la base de données et améliorer les temps de chargement et les performances de notre site. Ils sont définis dans le core wp-includes / cache.php, et ils peuvent être utilisés à travers un ensemble prédéfini de fonctions - similaires à celles mises à disposition pour les transitoires, dont ils se distinguent par le fait qu'ils sont également un système de stockage de données pour le cache, qui n'est cependant pas disponible sur tous les hébergements et il nécessite surtout un plugin de cache pour fonctionner.

Il s'agit d'un caractéristique avancé que peu de programmeurs connaissent, et encore moins utilisent activement : mais de nombreux plugins de mise en cache et d'optimisation, après tout, s'appuient dessus. Par défaut, WP Object Cache n'est pas une forme de données persistante et a tendance à ne durer que pendant la très courte durée de la requête HTTP en question. Par conséquent, ils ne sont pas stockés pour le futur sauf si un plugin spécial est installé (recommandé : W3 Total Cache). Nous parlons de mise en cache côté serveur, pas côté client bien sûr, alors ne nous perdons pas dans la confusion dès le début.

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 est que WordPress a introduit sa classe de mise en cache d'objets il y a longtemps - c'était en 2005 lorsque la classe nommée WP_Object_Cache il a été implémenté dans le noyau 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.

Cache de pages 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.

Il y a une histoire intéressante et amusante du monde réel sur GitHub, allez une lecture pour comprendre le 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 : Vernis Cache dont nous avons longuement parlé ici Hébergement de vernis, NGINX FastCGI Cache qui, à notre avis, est un moyen rapide et facile d'utiliser un Full Page Cache si vous n'avez pas les attributs pour utiliser correctement Varnish et son langage de configuration VCL, LsCache qui est un cache plutôt nouveau qui convient bien à le serveur Web LiteSpeed ​​​​ou la 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

Cache NGINX FastCGI ce serait aussi prometteur si certaines fonctionnalités (voir par exemple la possibilité de PURGER TOUT pour nettoyer tout le cache) ne sont présentes que dans la version commerciale Nginx Plus ou NGINX + ce qui n'est certainement pas attractif en terme 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 déjà mentionné dans la phase d'introduction, le coût peut certainement être abordable et même économique pour les entreprises déjà consolidées et capables de réaliser un bénéfice à la mesure de l'investissement dans ce service leader sur le marché qui comprend de nombreuses options comme par exemple la protection des 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 voulez en savoir plus sur cette énorme erreur, lisez également cet article : Cache HTML 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 voulez en savoir plus sur Varnish, nous vous recommandons cette lecture : Hébergement WordPress pour journaux et publication 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.

 

 

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