Table des matières de l'article :
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.
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.
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.
