20 juin 2022

WordPress lent. Découvrons les causes et les solutions.

Découvrons les principales raisons pour lesquelles WordPress est lent et comment y remédier.

WordPress lent

L'importance de la vitesse d'un site Web est désormais incontestée, surtout après l'avènement de Google Vitaux Web de base, qui ont confirmé avec éloquence que la vitesse d'un site est un facteur de classement.

Avec cette prise de conscience il serait trompeur, déplacé, déplacé et contre-productif de ne pas s'attarder sur une question aussi importante, susceptible de décréter l'échec de votre site (et de votre personne), ou d'un business rentable et gratifiant capable de vous garantir un cadre de vie confortable .. c'est satisfaisant.

Soyons sérieux, si vous êtes en première page et que vous avez un site rapide et accrocheur, vous ferez des affaires. En revanche, si votre site est lent et non positionné, votre site ne sera qu'un coût, une dépense, un passif et non une machine à sous.

Après avoir dit et clarifié le concept ci-dessus, demandons-nous si nous avons vraiment la moindre idée de ce que signifie avoir un site rapide. La plupart des professionnels qui parlent aujourd'hui de vitesse n'ont pas la moindre idée de ce qu'ils disent à leurs clients et même à eux-mêmes.

Nous ne voulons pas être présomptueux, mais de plus en plus souvent, nous voyons des hébergeurs et des ingénieurs système ne s'occuper que de leur branche, ainsi que des développeurs et développeurs complètement désintéressés des implications systèmes sur le résultat final.

Dans d'autres contextes, et d'autres articles que vous trouvez en ligne à la place, nous nous limitons à recommander un hébergement WordPress plutôt qu'un autre, souvent avec des conflits d'intérêts embarrassants tels que de fausses critiques et des commissions non déclarées.

Pour notre part, il suffit de savoir que WordPress était lent avant l'avènement de Vitaux Web de base, et WordPress est lent même après eux. Nous avions simplement des mesures qui permettaient même à l'homme du commun de comprendre ce qui est bon et ce qui ne l'est pas.

Cependant, cette volonté de simplifier, avec un score anodin, ne nous permettait pas de comprendre facilement ce qui est rapide et ce qui est lent dans un site WordPress, et donc on se retrouve des professionnels qui n'ont rien compris à comment optimiser un site web et à comment vous devez nécessairement prêter au composant Serveur, si vous voulez bien commencer et mieux finir.

On parle pour des raisons commerciales évidentes de lenteur de WordPress, mais force est de constater que les concepts théoriques que nous allons exprimer sont applicables et adaptables à tout autre CMS ou langage côté serveur.

WordPress lent. Comprendre le problème en le décomposant

Il a toujours été inutile dans la vie de commencer par résoudre un problème sans en avoir compris l'origine et les causes. Dans cet article, nous voulons séparer le problème en parlant de la vitesse de génération de la page HTML et de la vitesse que le navigateur utilise pour réassembler les ressources qu'il voit indiquées dans la page HTML.

Un peu comme dire que pour réaliser un plat culinaire exotique, il faut d'abord commander les ingrédients, attendre qu'ils nous soient livrés, et ensuite seulement commencer par l'élaboration de la recette qui produira le plat exotique prêt et fini à déguster .

Problèmes côté serveur et TTFB.

Il est aisé de comprendre que si la réalisation d'une recette élaborée prend une demi-heure, mais que chercher les ingrédients et les amener en cuisine nous occuperait une demi-matinée, le temps de réalisation du plat équivaut au temps qu'il a fallu à nous de trouver et d'acheter les ingrédients ajoutés au temps nécessaire à la réalisation de la recette.

Parfois, en bref, le temps de récupération du code HTML côté serveur peut être beaucoup plus long que le temps nécessaire au navigateur pour télécharger les ressources et les reconstituer comme un puzzle.

Le problème avec la récupération de HTML est ce qui est techniquement mesuré dans la valeur de Temps jusqu'au premier octet.

Processus TTFB Apache PHP MySQL

Cette valeur dont nous avons longuement parlé dans l'article dont vous pouvez trouver le lien ci-dessus, est celle qui peut être brièvement définie avec la vitesse du serveur, influencée par du code PHP non performant, requêtes lentes à la base de données MySQL, et l'inefficacité de tout ce qui est construit sur cette architecture PHP + MySQL.

Qu'il s'agisse d'un plugin, d'un thème, d'une fonction, d'un extrait de code, le problème de ce qui est fait en PHP et MySQL sera toujours consultable en PHP et MySQL. Qu'il s'agisse de plugins, de thèmes, de fonctions, de morceaux de code, nous le savons, dont nous avons voulu abstraire les concepts architecturaux avec des superstructures organisationnelles, mais côté serveur, niveau interpréteur PHP rien ne change, on ne sait pas si ce qui tourne est un module, un plugin, un thème ou autre. Le code PHP est du code PHP, la requête MySQL est une requête MySQL.

Fin des discours, fin des aménagements divers et de la "philosophie informatique", utile uniquement pour grossir les honoraires des consultants et diminuer les portefeuilles de clients et de clients.

Ces problèmes doivent évidemment être identifiés et profilés avec débogage et profilage, l'utilisation de journaux de requêtes lents dans le débogage des requêtes lentes, etc...etc...

L'utilisation de matériel performant, efficace, à faible latence et à haut débit est certainement une valeur ajoutée adjuvante pour atteindre les objectifs visés, à savoir avoir un temps de traitement le plus court possible.

Une requête qui prend 100ms au lieu de 200ms est une requête double performante, qui en bout de chaîne de génération de la page HTML à retourner au navigateur va nous permettre d'avoir un site peut-être deux fois plus rapide, voire pas, mais certainement plus rapide.

Ne parlons pas des plugins ? Ne parlons pas des 10 secrets pour accélérer WordPress ?

Comment accélérer WordPress en 10 astuces ?

Il n'y a pas de "plugins" miraculeux, il n'y a pas de "méthodes" secrètes, il existe plutôt des compétences et des approches ainsi que des combinaisons de procédures et de tâches qui améliorent chaque aspect de votre pile logicielle et de votre serveur.

Nous sommes maintenant humainement fatigués de voir des "listes" de choses écrites par des gens qui n'ont jamais installé de distribution Linux de leur vie, qui n'ont jamais écrit de code en langage C ou qui ne savent pas comment fonctionne le protocole TCP/IP, proposant peut-être la séparation du serveur d'application et du serveur de base de données, peut-être avec une connexion gigabit.

On en a marre de se faire arnaquer par des gens qui ont des sites d'épicerie fine de proximité dans leur portefeuille, et qui peut-être en atteignant le score fatidique de 90 sur Google PageSpeed ​​Mobile, ont compromis le bon fonctionnement du pixel Facebook et le suivi des campagnes, peut-être sans se soucier du TTFB et de la latence DNS extrêmement élevée.

Certes vous croiserez des individus qui amélioreront aussi sensiblement la vitesse et le TTFB en utilisant des plugins Cache comme WordPress SuperCache, W3 Total Cache ou des plugins commerciaux comme WP Rocket par exemple et démonstration en main, vous vous sentirez également pleinement satisfait.

Peu iraient plus loin que ces plugins, n'étant pas des ingénieurs système compétents. Allez recompiler le noyau avec les bonnes valeurs de tuning au niveau TCP/IP, le bon support au niveau du serveur web comme le support de BBR TCP , le soutien de la Brotli compressionQu'il s'agisse d'un vin rare et exotique ou du même vin dans différents millésimes, quel que soit votre choix au 0-RTT avec prise en charge des données précoces, Et cache statique côté serveur tel que Varnish Cache capable de très bien fonctionner même avec du trafic provenant des réseaux sociaux.

Vous obtiendrez donc probablement un bon résultat mais pas le meilleur, et compte tenu de la concurrence de plus en plus féroce pour vous positionner dans les premiers résultats cela n'a aucun sens de recourir à des demi-mesures.

Problèmes côté client, problèmes côté navigateur et rendu HTML

Maintenant que nous avons le code HTML de la page que nous voulons afficher, nous devons commencer à télécharger les ressources qu'il contient. Imaginons que cette page HTML soit une longue page d'accueil classique, avec des centaines de ressources et d'images, dont certaines dans l'en-tête, certaines dans le diaporama initial, certaines dans le corps central du texte et bien d'autres dans le pied de page final.

Lequel devrait commencer à télécharger tout de suite ? Évidemment ceux que nous verrons en premier et donc, les parties inhérentes à l'en-tête et au menu, au diaporama et seulement ensuite les éléments d'image du contenu que nous allons lire (peut-être) ou du pied de page, en supposant que cela nous intéresse en poursuivant la lecture complète jusqu'à arriver au pied de page.

C'est là qu'entrent en jeu des approches telles que le CSS critique, le chargement paresseux des ressources, la suppression des CSS et des JS inutilisés, ainsi que la garantie du meilleur poids possible pour les ressources, ainsi qu'une efficacité importante du côté du réseau et de la mise en réseau. sont largement couverts dans la section de Vitaux Web de base.

navigateur de rendu html

Ces aspects devraient normalement être vus par les développeurs qui, cependant, sont souvent incapables de résoudre les problèmes décrits ci-dessus côté serveur et donc la meilleure recette est d'unir des développeurs et des ingénieurs système compétents pour résoudre les problèmes de vitesse du site.

Méfiez-vous toujours des approches classiques "Installez un plugin, faites 3 clics et le tour est joué". Ce n'est pas comme ça que ça marche et vous risquez de faire plus de dégâts qu'autre chose, ou du moins de penser que vous avez bien fait et de ne pas réaliser que peut-être le trafic provenant de Facebook ou Instagram ou des campagnes Google coupe votre cache comme un fer rouge. dans un bâton de beurre et les mauvaises valeurs de navigation de l'utilisateur sont envoyées à Google qui les utilise pour générer et compiler des rapports sur Données CRUX de Vitaux Web de base qui sera jugé insuffisant et donc vous serez pénalisé ou du moins pas récompensé.

Conclusions

Si vous avez un site WordPress lent et que vous souhaitez l'accélérer, vous devez obligatoirement atteindre les deux objectifs indiqués ci-dessus : avoir un serveur qui renvoie du HTML de l'ordre de 200 - 300ms maximum ; que ce HTML et les ressources associées telles que JS et CSS soient structurés de manière à avoir le minimum d'informations nécessaires au rendu de la page, le minimum d'espace occupé (compression efficace), et que le balisage soit conçu dans le but de télécharger immédiatement les ressources que nous devons afficher en premier (par exemple, Critical CSS).

Satisfaire ces deux exigences vous procurera un avantage important tant en termes d'ergonomie utilisateur et donc d'Expérience Utilisateur, que des avantages en termes de SEO puisque la rapidité d'un site est désormais un facteur d'indexation.

 

 

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 The 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™ ; 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. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. 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