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

Lors du 10ème anniversaire de WPBeginner, j’ai partagé que l’infrastructure d’hébergement de WPBeginner a été 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 les 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 également.

Dans cet article, je vais vous donner un aperçu des coulisses de la façon dont nous avons rendu WordPress plus rapide que les générateurs de sites statiques et les plateformes CMS sans tête.

Note : Cet article est un peu plus technique que ce que nous publions habituellement sur WPBeginner. Pour les utilisateurs/utilisatrices non-techniciens, 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 passés entièrement à la plateforme Google Cloud gérée par SiteGround. Nous avons les mêmes résultats en termes de vitesse et nous avons déverrouillé des performances de back-end encore plus rapides. Lisez pourquoi nous sommes passés à SiteGround.

Arrière-plan

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

Cette affirmation est généralement suivie d’une autre : vous devriez 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 qui ont bien réussi ont commencé à me demander si c’était vrai.

Certains ont même entamé le processus de migration vers un CMS sans tête parce qu’ils ont lu des études de cas sur la façon dont d’autres ont déverrouillé d’énormes améliorations de la vitesse en passant de WordPress à des 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 sans fin qui s’accumuleront à l’avenir.

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

Vous pouvez me traiter de vieille école, mais en fin de compte, un site statique n’est qu’une page qui se charge à partir d’une mise en cache.

Résultats

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

Voici la vitesse de chargement de la page d’accueil de WPBeginner sur Pingdom depuis leur serveur de Washington, DC :

Selon l’heure de la journée et l’Emplacement que vous vérifiez à partir, ce résultat variera n’importe où de 400ms – 700ms plage qui est assez rapide pour une page d’accueil.

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

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

Les résultats ci-dessus sont pour les pages mises en cache, ce qui est ce que nos lecteurs et les robots des moteurs de recherche obtiennent lorsqu’ils voient notre site. Le temps de chargement perçu de WPBeginner est quasi instantané (plus d’informations à ce sujet ultérieurement).

À titre de comparaison, voici un résultat de test de vitesse pour la page d’accueil de Gatsby. Il s’agit d’un générateur de site statique populaire dont beaucoup de développeurs/développeuses font l’éloge :

Voici le résultat du test de vitesse de la page d’accueil de Netlify, un hébergeur de sites statiques populaire, que beaucoup de développeurs/développeuses recommandent. Notez qu’ils ont la moitié de la quantité de demandes, et que la taille de leur page est de 30% de WPBeginner, mais qu’elle se charge toujours plus lentement que notre page d’accueil.

La vitesse de la page d’accueil de Contentful, le headless CMS qui est « comment les entreprises offrent de meilleures expériences numériques » n’est tout simplement pas optimisée du tout. C’est le site le plus lent que nous avons testé.

Je partage ces statistiques non pas pour discréditer les autres frameworks, mais plutôt pour donner une perspective que toutes les nouvelles choses ne sont pas aussi brillantes qu’elles le paraissent.

WordPress, avec une infrastructure d’hébergement adéquate et des optimisations, peut être aussi rapide que n’importe quel générateur de site statique. En outre, aucune autre plateforme ne se rapprochera du niveau de flexibilité que WordPress offre aux propriétaires d’entreprises grâce à son vaste écosystème d’extensions et de thèmes.

Infrastructure d’hébergement de WPBeginner

Lorsqu’il s’agit de la vitesse d’un site, rien ne joue un rôle plus important que l’infrastructure de votre hébergeur.

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

Au fur et à mesure que notre site grandissait, nous avons mis à niveau vers leur hébergement VPS, puis vers des serveurs dédiés.

Au cours de la dernière décennie, j’ai eu la chance de travailler en étroite collaboration avec de nombreux membres de leur équipe, et ils sont devenus une partie étendue 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 ont offert de m’aider à construire une configuration d’hébergeur d’entreprise unique en son genre pour WPBeginner.

Ils ont mis les meilleurs ingénieurs des équipes de Bluehost et HostGator à travailler en étroite collaboration avec moi pour rendre WPBeginner extrêmement rapide.

Voici un aperçu de la configuration de l’hébergeur de WPBeginner :

Comme vous pouvez le voir, il s’agit d’une configuration multi-serveurs répartie sur deux régions géographiques (Texas et Utah). Il y a un total de 9 serveurs sans compter le nuage d’équilibreur de charge. Chaque serveur est un CPU Xeon-D avec 8 cœurs (16 threads) avec 32GB RAM et 2 x 1TB SSD (configuration RAID).

Nous utilisons la plateforme Cloud Load Balancing de Google, ce qui nous permet de bénéficier d’une mise à l’échelle automatique et d’un équilibrage de la charge sans faille, dans le monde entier.

Une fois le matériel configuré et la synchronisation des données en place, les équipes de Bluehost et HostGator ont travaillé ensemble pour optimiser la configuration des serveurs pour WordPress. J’espère que certaines de ces optimisations seront bientôt intégrées dans les futures offres d’hébergement WordPress

Résumé de la configuration du serveur

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

Nous utilisons Apache pour notre serveur web car l’équipe est plus familière avec ce logiciel. Je n’entrerai pas dans le débat NGINX vs Apache.

Nous utilisons PHP 7.2 ainsi que des pools PHP-FPM, afin de pouvoir gérer des charges élevées de processus et de demandes. Si votre entreprise d’hébergement n’utilise pas PHP 7+, vous passez à côté d’une sérieuse optimisation de la vitesse.

Nous utilisons la mise en cache Opcode avec un cache warmer avancé pour s’assurer qu’Aucun utilisateur/utilisatrice ne puisse voir une page non mise en cache.

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

Pour mettre en perspective, notre expérience de la zone d’administration est maintenant 2X 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 plus performant. Nous sommes également passés d’HyperDB à LudicrousDB parce qu’il nous aide à améliorer la réplication, le basculement et l’équilibrage de la charge de notre base de données.

Il y a aussi beaucoup d’autres configurations qui nous aident avec la performance et l’évolutivité, comme HTTP/2 et HSTS pour une connexion plus rapide + chiffrement, la capacité de faire tourner 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 étonnante que l’équipe a construite, mais veuillez noter que mon cœur de métier est le marketing. Oui, je suis un blogueur qui écrit sur WordPress, mais beaucoup d’optimisations techniques ici sont bien au-dessus de mes compétences.

Elles ont été réalisées par des développeurs/développeuses super intelligents de l’équipe Endurance, notamment David Collins (architecte en chef d’Endurance / CTO de HostGator), Mike Hansen (développeur/développeuse WordPress cœur), et d’autres personnes que je remercierai dans la section crédits ci-dessous.

CDN, WAF et DNS

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

Bien que je les ai répertoriés comme trois choses distinctes, beaucoup d’entreprises offrent maintenant ces solutions dans une offre lot, comme Sucuri, Cloudflare, MaxCDN (StackPath), etc.

Comme je veux avoir un contrôle maximal et répartir les risques, j’utilise trois entreprises distinctes pour gérer efficacement chaque partie.

Le DNS de WPBeginner est alimenté par DNS Made Easy (la même entreprise que Constellix). Ils sont régulièrement classés comme les fournisseurs de DNS les plus rapides au monde. L’avantage de DNS Made Easy est que je peux faire une direction globale du trafic lorsqu’un centre de données spécifique sur mon CDN ou WAF ne fonctionne pas correctement pour assurer un temps de disponibilité maximal.

Notre CDN est alimenté par MaxCDN (StackPath). Ils nous permettent essentiellement de servir nos actifs statiques (images, fichiers CSS et JavaScripts) à partir de leur grand 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 calque de CDN, et leur performance globale est tout simplement incroyable. Je pense qu’ils ont la meilleure solution de pare-feu WordPress sur le marché.

Lorsque l’on travaille sur l’optimisation de la vitesse du site, il est important d’économiser chaque milliseconde. C’est pourquoi l’utilisation de ces fournisseurs d’hébergement combinée à notre nouvelle infrastructure d’hébergement web fait une énorme différence.

Pour illustrer, voici la répartition de la chute d’eau entre WPBeginner.com vs GatsbyJS.org vs CloudFlare.com :

Notez que le temps DNS, le temps SSL, le temps de connexion et le temps d’attente de WPBeginner sont tous de premier ordre par rapport à ces autres sites populaires. Chacune de ces améliorations composé 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.

En plus de toutes les choses que j’ai mentionnées ci-dessus, nous trichons également sur la latence en utilisant un script appelé instant.page qui utilise le préchargement juste à temps.

Link : avant qu’un compte ne clique sur un lien, il doit survoler ce lien avec sa souris. Lorsqu’un compte a survolé le lien pendant 65 ms (très courte période de temps), un sur deux cliquera effectivement sur le lien.

Le scriptInstant.page commence à précharger la page à ce moment-là, de sorte que lorsque le compte clique sur le lien, une grande partie du travail a déjà été effectuée. Le cerveau humain perçoit donc le temps de chargement du site comme quasi instantané.

Pour activer Instant.page sur votre site, il vous suffit d’installer et d’activer l’extension WordPress Instant Page.

Ce script est très intéressant. Je vous recommande vivement de consulter leur site 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 l’extension FlyingPages dans un futur proche. Gijo Varghese a partagé sa nouvelle extension avec moi dans le groupe Facebook WPBeginner Engage, et elle semble combiner le meilleur de instant.page et du script quicklink.

Optimiser les images pour le web

Bien que de nouveaux formats d’images soient développés/développeuses comme le webp, nous ne les utilisons pas encore. Nous demandons plutôt à tous nos rédacteurs d’optimiser chaque image à l’aide de l’outil TinyPNG.

Vous pouvez également automatiser la compression des images à l’aide d’extensions comme Optimole ou EWWW Image Optimizer.

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

Actuellement, nous ne faisons pas de chargement paresseux pour les images, mais j’ai l’offre de l’ajouter dans un avenir proche maintenant que Google a intégré le support du chargement paresseux dans Chrome 76.

Il y a également un ticket dans le cœur de WordPress pour ajouter cette fonctionnalité sur tous les sites (j’espère vraiment que cela arrivera bientôt), de sorte que je n’ai pas à écrire une extension personnalisée.

Mise à jour : Quelques heures après la publication du blog, Google a publié l’extension Native Lazy Load pour WordPress.

Limiter les requêtes HTTP + Meilleures pratiques

Selon les extensions WordPress que vous utilisez, certaines ajouteront des modules CSS et JavaScript supplémentaires à chaque chargement de page. Ces demandes HTTP supplémentaires peuvent devenir incontrôlables si vous avez beaucoup d’extensions sur votre site.

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

Maintenant, avant de sauter à la mauvaise conclusion que trop de plugins WordPress sont mauvais, je tiens à vous faire savoir qu’il y a 62 plugins actifs en cours d’exécution sur le site WPBeginner.

Ce que vous devez faire, c’est combiner les fichiers CSS et JavaScript dans la mesure du possible pour réduire les demandes HTTP. Certaines extensions de mise en cache WordPress comme WP Rocket peuvent le faire automatiquement grâce à leur fonctionnalité de minification.

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

En dehors des demandes HTTP que les extensions et les thèmes ajoutent, vous voulez également être attentif aux autres scripts tiers que vous ajoutez sur votre site, car chaque script aura un impact sur la vitesse de votre site.

Par exemple, si vous exécutez beaucoup de scripts d’annonces ou de reciblage, ils ralentiront votre site. Vous pouvez utiliser un outil tel que Google Tag Manager pour charger les scripts de manière conditionnelle, uniquement lorsqu’ils sont nécessaires.

Si votre site est financé par la publicité, comme TechCrunch ou TheNextWeb, vous ne pouvez pas faire grand-chose, car il n’est pas facultatif de retirer les publicités.

Ajoutéé à cela, WPBeginner ne dépend pas de scripts publicitaires tiers pour gagner de l’argent. Vous voulez voir comment WPBeginner gagne de l’argent ? Voir ma publication de blog sur les revenus de WPBeginner.

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

Il s’agit d’une toute nouvelle infrastructure d’hébergeur, et je suis confiant qu’il y a des tonnes de leçons que j’apprendrai au fil du temps.

Jusqu’à présent, j’aime les améliorations de la vitesse parce qu’elles nous ont aidés à améliorer notre classement SEO, et notre zone d’administration est beaucoup plus rapide.

Avec la nouvelle configuration multi-serveurs, nous avons introduit un nouveau flux de travail de déploiement pour mettre WPBeginner au même niveau que le reste des sites de produits Awesome Motive.

Cela signifie que nous avons maintenant un bon contrôle de version intégré, et il y a des mesures mises en place pour m’empêcher d’être imprudent (i.e. ajouter des extensions sans les tester, mettre à jour des extensions depuis le Tableau de bord sans les tester, etc).

Ces modifications ont également défini le chemin pour que je me retire enfin du développement et que je remette les rênes du site WPBeginner à notre équipe de développeurs.

J’ai résisté pendant des années, mais je pense que le moment est venu, et je dois juste l’accepter.

La nouvelle configuration n’a pas de cPanel ni de WHM, ce qui me rend pratiquement inutile de toute façon puisque je ne suis plus très à l’aise avec 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 ne se sont pas 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 Version d’un meilleur processus de construction et de test pour cela.

Deuxièmement, nous avons besoin d’une meilleure communication entre les équipes car nous avons eu une crise mineure avec une mauvaise configuration de l’équilibreur de charge qui a entraîné des temps d’arrêt. Pour couronner le tout, j’étais sur un vol transatlantique de Turkish Airlines et le WiFi ne fonctionnait pas.

Heureusement, tout est rentré dans l’ordre grâce à la rapidité de réponse de l’équipe d’hébergeurs, mais cela nous a aidés à créer plusieurs nouvelles procédures opérationnelles standard (POS) 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 offres d’hébergement WordPress de HostGator Cloud et Bluehost.

Je pense que cela devrait aller sans dire que si vous commencez juste un site, un blog, ou un stock en ligne, alors vous N’AVEZ PAS besoin de cette configuration d’entreprise sophistiquée.

Je vous recommande toujours de commencer petit avec les offres partagées HostGator ou Bluehost comme je l’ai fait, puis de mettre à niveau votre infrastructure d’hébergement au fur et à mesure que votre entreprise se développe.

Vous pouvez appliquer une grande partie des optimisations que j’ai partagées ci-dessus sur vos offres d’hébergement WordPress actuelles.

Par exemple, l’offre standard de Bluehost est déjà livrée avec une extension de mise en cache intégrée que vous pouvez utiliser, et ils offrent PHP 7 par défaut également.

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

Maintenant, si vous êtes une entreprise de taille moyenne / entreprise qui veut 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 et crédits

Bien que dans l’article ci-dessus, j’ai donné des tonnes de shout out aux marques HostGator et Bluehost, je veux prendre un moment pour reconnaître et apprécier les personnes individuelles qui ont travaillé dans les coulisses pour faire en sorte que cela se produise.

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 fait le gros du travail et permis la réalisation de ce projet.

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 réglages. Je tiens également à remercier Tony Perez et Daniel Cid de Sucuri qui m’ont toujours soutenu.

Dernier point, mais non des moindres, je tiens à remercier tout particulièrement Chris Christoff. Il est le cofondateur 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 de WPBeginner pour être utile. Vous pouvez également consulter notre guide ultime sur la façon d’accélérer WordPress qui est beaucoup plus convivial pour les débutants.

Bonus : Voici les meilleures extensions et outils WordPress que je recommande pour tous les sites WordPress.

Si vous avez aimé cet article, veuillez vous abonner à notre chaîne YouTube pour des tutoriels vidéo sur WordPress. Vous pouvez également nous trouver sur Twitter et Facebook.