Comment nous avons rendu WordPress plus rapide que les générateurs de sites statiques (Étude de cas – Accélérer WPBeginner)

---

À l'occasion du 10e anniversaire de WPBeginner, j'ai partagé que l'infrastructure d'hébergement de WPBeginner avait bénéficié d'une énorme mise à niveau grâce à notre partenaire d'hébergement Web, HostGator.

Peu de temps après, j'ai commencé à recevoir des e-mails de lecteurs me demandant de partager des détails sur la façon dont nous avons rendu le chargement de WPBeginner extrêmement rapide.

Oui, WPBeginner se charge plus rapidement que la plupart des générateurs de sites statiques et, dans certains cas, plus rapidement que les sites Google AMP.

Dans cet article, je vais vous expliquer en coulisses comment nous avons rendu WordPress plus rapide que les générateurs de sites statiques et les plates-formes CMS sans tête.

Remarque : Cet article est un peu plus technique que ce que nous publions habituellement sur WPBeginner. Pour les utilisateurs non experts, je recommande de suivre notre guide ultime sur la façon d’accélérer WordPress.

Mise à jour : nous n'utilisons plus la configuration partagée dans cet article. Au lieu de cela, nous sommes entièrement passés à la plateforme Google Cloud gérée par SiteGround. Nous avons les mêmes résultats en termes de vitesse et avons débloqué des performances back-end encore plus rapides. Découvrez pourquoi nous sommes passés à SiteGround.

Arrière-plan

Dernièrement, WordPress a reçu beaucoup de mauvaise réputation de la part des développeurs « modernes » qui disent que WordPress est lent.

La déclaration est généralement suivie par le fait que vous devez passer à un générateur de site statique JAMstack comme GatsbyJS. D'autres dans le monde de l'entreprise diront que vous devriez passer à un CMS sans tête comme Contentful.

Plusieurs de mes amis entrepreneurs très prospères ont commencé à me demander si c’était vrai.

Certains ont même commencé le processus de migration vers un CMS sans tête après avoir lu des études de cas montrant comment d’autres ont débloqué d’énormes améliorations de vitesse en passant de WordPress aux générateurs de sites statiques.

C’était très frustrant pour moi car je savais qu’ils gaspillaient des dizaines de milliers de dollars en coûts de migration. Sans parler des coûts de personnalisation interminables qui s’accumuleront à l’avenir.

J’ai donc pris pour défi de prouver qu’un grand site de contenu WordPress comme WPBeginner peut se charger aussi vite, voire plus vite, que la plupart des générateurs de sites statiques modernes.

Vous pouvez m'appeler vieille école, mais en fin de compte, un site statique n'est qu'une page chargée à partir du cache.

Résultats

Avant de passer à l’infrastructure d’hébergement WordPress exacte, aux configurations de serveur et aux plugins, je pense qu’il est utile de partager les résultats.

Voici à quelle vitesse la page d'accueil de WPBeginner se charge sur Pingdom à partir de son serveur de Washington, DC :

En fonction de l'heure de la journée et du lieu à partir duquel vous vérifiez, ce résultat variera entre 400 ms et 700 ms, ce qui est assez rapide pour une page d'accueil.

Voici un test que j'ai effectué pour une seule page de publication car elle contient des images plus grandes et plus de contenu :

Nous avons également obtenu un score parfait de « 100 » au test de vitesse des pages Google pour ordinateur. Bien que nous ayons une certaine marge d’amélioration sur le score mobile.

Les résultats ci-dessus concernent les pages mises en cache, ce que nos lecteurs et les robots des moteurs de recherche obtiennent lorsqu'ils consultent notre site Web. Le temps de chargement perçu de WPBeginner est quasi instantané (nous y reviendrons plus tard).

À titre de comparaison, voici un résultat d’un test de vitesse pour la page d’accueil de Gatsby. Il s'agit d'un générateur de sites statiques populaire dont de nombreux développeurs raffolent :

Voici le résultat du test de vitesse de la page d’accueil de Netlify, un hébergeur de sites statiques populaire, recommandé par de nombreux développeurs. Notez qu'ils ont la moitié du nombre de requêtes et que la taille de leur page est de 30 % de celle de WPBeginner, mais elle se charge toujours plus lentement que notre page d'accueil.

La vitesse de la page d'accueil de Contentful, le CMS sans tête qui permet aux entreprises d'offrir de meilleures expériences numériques, n'est tout simplement pas optimisée du tout. C'est le site Web le plus lent que nous ayons testé.

Je partage ces statistiques non pas pour discréditer les autres frameworks, mais plutôt pour montrer que toutes les nouveautés ne sont pas aussi brillantes qu'elles le paraissent.

WordPress avec une infrastructure d'hébergement et des optimisations appropriées peut être aussi rapide que n'importe quel générateur de site statique. De plus, aucune autre plate-forme n’atteindra le niveau de flexibilité que WordPress offre aux propriétaires d’entreprise grâce à son vaste écosystème de plugins et de thèmes.

Infrastructure d'hébergement WPBeginner

Lorsqu'il s'agit de vitesse d'un site Web, rien ne joue un rôle plus important que votre infrastructure d'hébergement Web.

Comme beaucoup d'entre vous le savent déjà, je suis client HostGator depuis 2007. J'ai lancé le blog WPBeginner en 2009 sur un petit compte d'hébergement partagé HostGator.

Au fur et à mesure de la croissance de notre site Web, nous sommes passés à leur hébergement VPS puis à leurs serveurs dédiés.

Au cours de la dernière décennie, j'ai eu la chance de travailler en étroite collaboration avec plusieurs membres de leur équipe, et ils sont devenus un membre élargi de la famille WPBeginner.

Ainsi, lorsque j'ai relevé le défi de rendre WPBeginner plus rapide que les générateurs de sites statiques, je me suis tourné vers eux pour obtenir de l'aide.

J'ai partagé ma vision avec leur équipe de direction et ils m'ont proposé de m'aider à créer une configuration d'hébergement d'entreprise unique en son genre pour WPBeginner.

Ils ont fait appel aux meilleurs ingénieurs de l'équipe Bluehost et HostGator pour travailler en étroite collaboration avec moi pour rendre WPBeginner ultra-rapide.

Voici un aperçu de ce à quoi ressemble la configuration de l’hébergement WPBeginner :

Comme vous pouvez le constater, il s'agit d'une configuration multi-serveurs répartie sur deux régions géographiques (Texas et Utah). Il existe un total de 9 serveurs, sans compter le cloud de l'équilibreur de charge. Chaque serveur est un processeur Xeon-D avec 8 cœurs (16 threads) avec 32 Go de RAM et 2 SSD de 1 To (configuration RAID).

Nous utilisons la plateforme Cloud Load Balancing de Google, afin de pouvoir bénéficier d'une mise à l'échelle automatique et d'un équilibrage de charge transparents, dans le monde entier.

Une fois le matériel configuré avec une synchronisation appropriée des données en place, l'équipe Bluehost et HostGator ont travaillé ensemble pour optimiser les configurations du serveur pour WordPress. J'espère que certaines de ces optimisations seront bientôt intégrées aux futurs plans d'hébergement WordPress ?

Résumé de la configuration du serveur

Résumer les configurations de serveur de cette configuration complexe en quelques paragraphes seulement est très difficile, mais je ferai de mon mieux.

Nous utilisons Apache pour notre logiciel de serveur Web car l'équipe le connaît mieux. Je n'entrerai pas dans le débat NGINX vs Apache.

Nous utilisons PHP 7.2 avec des pools PHP-FPM, afin de pouvoir gérer des charges élevées de processus et de requêtes. Si votre société d'hébergement n'utilise pas PHP 7+, vous passez à côté d'une optimisation sérieuse de la vitesse.

Nous utilisons la mise en cache Opcode avec un réchauffeur de cache avancé pour garantir qu'aucun utilisateur réel ne devrait rencontrer une page vue non mise en cache.

Nous utilisons également le cache d'objets avec Memcache, afin de pouvoir améliorer le temps de réponse pour les pages non mises en cache et les autres temps de réponse de l'API dans la zone d'administration de WordPress pour les utilisateurs connectés (nos rédacteurs). Voici un onglet de charge réseau de notre écran « Tous les messages » dans l'administrateur WordPress :

Pour mettre en perspective, notre expérience dans la zone d'administration est désormais 2 fois plus rapide que ce que nous avions auparavant.

Pour notre serveur de base de données, nous sommes passés de MySQL à MariaDB qui est un clone de MySQL mais plus rapide et meilleur. Nous sommes également passés d'HyperDB à LudicrousDB car cela nous aide à améliorer la réplication, le basculement et l'équilibrage de charge de notre base de données.

Il existe également de nombreuses autres configurations qui nous aident en termes de performances et d'évolutivité, telles que HTTP/2 et HSTS pour une connexion et un cryptage plus rapides, la possibilité de démarrer des serveurs supplémentaires dans de nouvelles régions en cas de panne du centre de données, etc.

J’ai l’impression de ne pas rendre justice à la configuration incroyable que l’équipe a construite, mais sachez que ma principale force est le marketing. Oui, je suis un blogueur qui écrit sur WordPress, mais la plupart des optimisations techniques ici sont bien au-dessus de mon niveau de rémunération.

Ils ont été réalisés par des ingénieurs super intelligents de l'équipe Endurance, dont David Collins (architecte en chef d'Endurance/CTO de HostGator), Mike Hansen (développeur WordPress principal) et d'autres que je remercierai dans la section crédits ci-dessous.

CDN, WAF et DNS

Outre l'hébergement Web, les autres domaines qui jouent un rôle important dans la vitesse de votre site Web sont votre fournisseur DNS, votre réseau de diffusion de contenu (alias CDN) et votre pare-feu d'application Web (WAF).

Bien que je l'ai répertorié en trois éléments distincts, de nombreuses entreprises proposent désormais ces solutions dans un forfait groupé tel que Sucuri, Cloudflare, MaxCDN (StackPath), etc.

Puisque je souhaite avoir un contrôle maximal et répartir les risques, je fais appel à trois sociétés distinctes pour gérer chaque partie efficacement.

WPBeginner DNS est alimenté par DNS Made Easy (même société que Constellix). Ils sont régulièrement classés parmi les fournisseurs DNS les plus rapides au monde. L’avantage de DNS Made Easy est que je peux gérer le trafic global lorsqu’un centre de données spécifique sur mon CDN ou WAF ne fonctionne pas correctement pour garantir une disponibilité maximale.

Notre CDN est alimenté par MaxCDN (StackPath). Ils nous permettent essentiellement de servir nos actifs statiques (images, fichiers CSS et JavaScript) à partir de leur vaste réseau de serveurs à travers le monde.

Nous utilisons Sucuri comme pare-feu d'application Web. En plus de bloquer les attaques, ils agissent également comme une autre couche de CDN, et leurs performances globales sont tout simplement incroyables. Je pense qu’ils disposent de la meilleure solution de pare-feu WordPress du marché.

Lorsque vous travaillez sur l’optimisation de la vitesse d’un site Web, il est important de réduire chaque milliseconde. C'est pourquoi l'utilisation de ces fournisseurs de solutions combinée à notre nouvelle infrastructure d'hébergement Web fait une énorme différence.

Pour illustrer, voici la répartition en cascade de WPBeginner.com vs GatsbyJS.org vs CloudFlare.com :

Notez que l'heure DNS, l'heure SSL, l'heure de connexion et le temps d'attente de WPBeginner sont toutes de premier ordre par rapport à ces autres sites Web populaires. Chacune de ces améliorations s’associe pour fournir les meilleurs résultats.

Instant.page, images optimisées et autres bonnes pratiques

L'une des choses que vous avez peut-être remarquées est le temps de chargement quasi instantané lorsque vous parcourez les publications et les pages de WPBeginner.

Outre tout ce que j'ai mentionné ci-dessus, nous trichons également sur la latence en utilisant un script appelé instant.page qui utilise le préchargement juste à temps.

Fondamentalement, avant qu'un utilisateur clique sur un lien, il doit passer sa souris sur ce lien. Lorsqu’un utilisateur a survolé pendant 65 ms (durée très courte), un utilisateur sur deux va effectivement cliquer sur le lien.

Le script Instant.page commence à précharger cette page à ce moment-là, donc lorsque l'utilisateur clique réellement sur le lien, une grande partie du travail est déjà fait. Cela fait que le cerveau humain perçoit le temps de chargement du site Web comme presque instantané.

Pour activer Instant.page sur votre site, vous pouvez simplement installer et activer le plugin WordPress Instant Page.

Ce script est plutôt soigné. Je vous recommande fortement de consulter leur site Web et de cliquer sur le bouton « Testez votre vitesse de clic » pour voir comment il trompe le cerveau.

Mise à jour : J'ai désactivé instant.page pour le moment et je vais tester le plugin FlyingPages dans un avenir proche. Gijo Varghese a partagé son nouveau plugin avec moi dans le groupe Facebook WPBeginner Engage, et il semble combiner le meilleur de l'instant.page et du script quicklink.

Optimisation des images pour le Web

Bien que de nouveaux formats d’image soient développés, tels que webp, nous ne les utilisons pas encore. Au lieu de cela, nous demandons à tous nos rédacteurs d'optimiser chaque image à l'aide de l'outil TinyPNG.

Vous pouvez également automatiser la compression d'image à l'aide de plugins comme Optimole ou EWWW Image Optimizer.

Cependant, personnellement, je préfère que l’équipe le fasse manuellement, afin que nous ne téléchargions pas de gros fichiers sur le serveur.

Actuellement, nous n'effectuons pas de chargement paresseux pour les images, mais je prévois de l'ajouter dans un avenir proche maintenant que Google intègre la prise en charge du chargement paresseux à Chrome 76.

Il existe également un ticket dans le noyau de WordPress pour ajouter cette fonctionnalité sur tous les sites (en espérant vraiment que cela se produise bientôt), donc je n'ai pas besoin d'écrire un plugin personnalisé.

Mise à jour : quelques heures après la publication de l'article de blog, Google a publié le plugin Native Lazy Load pour WordPress.

Limitation des requêtes HTTP + Bonnes pratiques

Selon les plugins WordPress que vous utilisez, certains ajouteront des fichiers CSS et JavaScript supplémentaires à chaque chargement de page. Ces requêtes HTTP supplémentaires peuvent devenir incontrôlables si vous avez de nombreux plugins sur votre site Web.

Pour plus de détails, découvrez comment les plugins WordPress peuvent affecter le temps de chargement de votre site.

Maintenant, avant de tirer la mauvaise conclusion selon laquelle trop de plugins WordPress sont mauvais, je tiens à vous faire savoir qu'il existe 62 plugins actifs en cours d'exécution sur le site Web WPBeginner.

Ce que vous devez faire est de combiner les fichiers CSS et JavaScript lorsque cela est possible pour réduire les requêtes HTTP. Certains plugins de mise en cache WordPress comme WP Rocket peuvent le faire automatiquement grâce à leur fonction de minification.

Vous pouvez également suivre les instructions de cet article pour le faire manuellement, ce que notre équipe de WPBeginner a fait.

Outre les requêtes HTTP ajoutées par les plugins et les thèmes, vous devez également faire attention aux autres scripts tiers que vous ajoutez sur votre site Web, car chaque script aura un impact sur la vitesse de votre site Web.

Par exemple, si vous exécutez de nombreux scripts publicitaires ou de reciblage, ils ralentiront votre site. Vous souhaiterez peut-être utiliser un outil tel que Google Tag Manager pour charger des scripts de manière conditionnelle uniquement lorsqu'ils sont nécessaires.

Si vous êtes un site Web financé par la publicité comme TechCrunch ou TheNextWeb, vous ne pouvez pas faire grand-chose à ce sujet, car la suppression des publicités n'est pas une option.

Heureusement, WPBeginner ne s'appuie pas sur des scripts publicitaires tiers pour gagner de l'argent. Vous voulez voir comment WPBeginner gagne de l’argent ? Voir mon article de blog sur les revenus WPBeginner.

Leçons apprises (jusqu'à présent) + Mes dernières réflexions

Il s’agit d’une toute nouvelle infrastructure d’hébergement, et je suis sûr que j’apprendrai des tonnes de leçons au fil du temps.

Jusqu'à présent, j'apprécie les améliorations de vitesse, car elles nous ont aidés à améliorer notre classement SEO et notre zone d'administration est beaucoup plus rapide.

Avec la nouvelle configuration multi-serveur, nous avons introduit un nouveau flux de déploiement pour mettre WPBeginner au niveau du reste des sites de produits Awesome Motive.

Cela signifie que nous disposons désormais d'un contrôle de version approprié intégré et que des mesures ont été mises en place pour m'empêcher d'être imprudent (c'est-à-dire ajouter des plugins sans tests appropriés, mettre à jour les plugins à partir du tableau de bord sans tests, etc.).

Ces changements m'ont également ouvert la voie pour enfin sortir du développement et confier les règnes du site WPBeginner à notre équipe de développement.

Cela fait des années que je résiste, mais je pense que le moment est venu et je dois juste l'accepter.

La nouvelle configuration n'a pas de cPanel ou WHM, donc cela me rend pratiquement inutile de toute façon puisque je ne maîtrise plus très bien la ligne de commande.

Jusqu’à présent, nous avons appris deux grandes leçons :

Premièrement, la mise à jour de WordPress n’est pas aussi simple en raison de la synchronisation/réplication du serveur. Lorsque nous avons mis à niveau mon blog personnel (SyedBalkhi.com) vers WordPress 5.2, les fichiers de mise à jour n'ont pas été synchronisés correctement sur l'un des nœuds Web et le débogage a pris beaucoup plus de temps que prévu. Nous travaillons à la création d'un meilleur processus de construction/test pour cela.

Deuxièmement, nous devons avoir une meilleure communication entre les équipes car nous avons eu une crise mineure avec des mauvaises configurations de l'équilibreur de charge qui ont entraîné des temps d'arrêt. Pour aggraver les choses, j'étais sur un vol transatlantique sur Turkish Airlines et le WiFi ne fonctionnait pas.

Heureusement, tout a été réglé grâce au temps de réponse rapide de l'équipe d'hébergement, mais cela nous a aidé à créer plusieurs nouvelles procédures opérationnelles standard (SOP) pour mieux gérer l'incident à l'avenir.

Dans l'ensemble, je suis très satisfait de la configuration et je sais que certaines des configurations/optimisations de mise en cache qui ont été faites pour WPBeginner deviendront une partie standard des plans d'hébergement HostGator Cloud et Bluehost WordPress.

Je pense que cela va sans dire que si vous démarrez tout juste un site Web, un blog ou une boutique en ligne, vous n'avez PAS besoin de cette configuration d'entreprise sophistiquée.

Je vous recommande toujours de commencer petit avec les forfaits partagés HostGator ou Bluehost comme je l'ai fait, puis de mettre à niveau votre infrastructure d'hébergement à mesure que votre entreprise se développe.

Vous pouvez appliquer de nombreuses optimisations que j'ai partagées ci-dessus sur vos plans d'hébergement WordPress actuels.

Par exemple, le plan standard Bluehost est déjà livré avec un plugin de mise en cache intégré que vous pouvez utiliser, et ils proposent également PHP 7 par défaut.

Vous pouvez combiner cela avec un CDN + WAF comme Sucuri pour accélérer considérablement votre site Web.

Maintenant, si vous êtes une entreprise de taille moyenne/entreprise qui souhaite une configuration d'hébergement similaire, veuillez me contacter via notre formulaire de contact. Je peux vous aider à vous orienter dans la bonne direction.

Remerciements spéciaux + crédits

Bien que dans l'article ci-dessus, j'aie salué les marques HostGator et Bluehost, je souhaite prendre un moment pour reconnaître et apprécier les personnes qui ont travaillé dans les coulisses pour y parvenir.

Tout d’abord, je tiens à remercier l’équipe de direction d’Endurance Suhaib, Mitch, John Orlando, Mike Lillie et Brady Nord d’avoir accepté de m’aider à relever le défi.

Je tiens également à remercier Mike Hansen, David Collins, Rick Radinger, Chris Miles, David Ryan, Jesse Cook, David Foster, Micah Wood, William Earnhardt, Robin Mendieta, Rod Johnson, Alfred Najem et les autres membres de l'équipe du centre de données pour avoir réellement faire le travail acharné et le réaliser.

Je tiens à remercier tout particulièrement Steven Job (fondateur de DNSMadeEasy) pour avoir répondu rapidement à mes questions et m'avoir aidé à mieux comprendre certains paramètres. Je tiens également à remercier Tony Perez et Daniel Cid de Sucuri pour m'avoir toujours soutenu.

Enfin et surtout, je tiens à remercier tout particulièrement Chris Christoff. Il est le co-fondateur de MonsterInsights et il a eu la gentillesse de m'aider avec une grande partie des tests et du déploiement.

J'espère vraiment que vous avez trouvé cette étude de cas en coulisses sur l'infrastructure d'hébergement WPBeginner utile. Vous voudrez peut-être également consulter notre guide ultime sur la façon d’accélérer WordPress, qui est bien plus convivial pour les débutants.

Bonus : Voici les meilleurs plugins et outils WordPress que je recommande pour tous les sites WordPress.

Si vous avez aimé cet article, abonnez-vous à notre chaîne YouTube pour les didacticiels vidéo WordPress. Vous pouvez également nous trouver sur Twitter et Facebook.