Un regard sur la pile de serveurs WordPress moderne

Vous souvenez-vous quand vous pouviez exécuter un site Web WordPress "rapide" avec juste un serveur Apache et PHP ? Ouais, c'étaient les jours! Les choses étaient beaucoup moins compliquées à l'époque.

Maintenant, tout doit se charger à la vitesse de l'éclair ! Les visiteurs n'ont plus les mêmes attentes concernant les temps de chargement qu'avant. Un site Web lent peut avoir de graves conséquences pour vous ou votre client.

Lectures complémentaires sur SmashingMag :

• Autorisations et propriétés appropriées du système de fichiers WordPress
• Déplacer un site Web WordPress sans tracas
• Comment développer WordPress localement avec MAMP
• Méthodes de mise en cache à faire soi-même avec WordPress

Par conséquent, la pile de serveurs WordPress a dû évoluer au fil des ans pour répondre à ce besoin de vitesse. Dans le cadre de cette évolution, quelques vitesses ont dû être ajoutées à son moteur. Certains des anciens engrenages ont également dû changer.

Le résultat est que la pile de serveurs WordPress est assez différente aujourd'hui de ce qu'elle était il y a quelques années. Pour mieux le comprendre, nous allons explorer en détail ce nouveau stack. Vous verrez comment les différentes pièces s'emboîtent pour créer un site Web WordPress rapidement.

Aperçu

Avant de plonger, dézoomons et regardons la situation dans son ensemble. À quoi ressemble cette nouvelle pile de serveurs WordPress ? Eh bien, voici la réponse :

Le diagramme ci-dessus donne un bon aperçu de ce à quoi ressemble la pile de serveurs WordPress moderne. À un niveau élevé, nous pouvons diviser ce qui se passe en trois domaines :

• le cycle requête-réponse entre le navigateur et WordPress ;
• WordPress (qui est un script que le runtime PHP exécute) ;
• le cycle requête-résultat entre WordPress et la base de données MySQL.

Le rôle de la pile de serveurs WordPress moderne est d'optimiser ces trois domaines. Ces optimisations font que tout se charge plus rapidement. Et la meilleure partie est qu'il existe plusieurs façons de le faire. (Yay!)

Dans la plupart des cas, ces optimisations impliquent l'installation de nouveaux services sur votre serveur. Parfois, ces services auront besoin de l'aide d'un plugin pour interagir avec WordPress. Il y aura aussi des moments où vous pourrez vous contenter d'installer un plugin. Vous verrez beaucoup d'options différentes tout au long de cet article.

Le cycle requête-réponse

Tout commence par le navigateur. Supposons que vous souhaitiez afficher la page d'accueil de modern.wordpress-stack.org . Votre navigateur va commencer par envoyer une requête HTTP au serveur web qui l'héberge. À l'autre extrémité, le serveur Web prendra votre demande et la transformera en une réponse HTTP.

Cette première réponse doit toujours être le contenu HTML de la page d'accueil de modern.wordpress-stack.org (sauf en cas d'erreur). Cependant, le travail de votre navigateur n'est pas terminé. Non, cette page d'accueil a encore besoin de plus de fichiers, les plus courants étant les fichiers CSS, JavaScript et images.

Ainsi, le navigateur enverra des demandes pour ces fichiers. Le serveur Web répondra avec les fichiers demandés (encore une fois, tant qu'il n'y a pas d'erreurs). Ce cycle se poursuivra jusqu'à ce que le navigateur dispose de suffisamment d'informations pour afficher la page d'accueil. Plus ce cycle est rapide, plus le site Web semblera se charger rapidement.

Maintenant, c'est une simplification évidente, mais c'est ainsi que les choses fonctionnent pour la majorité des sites Web WordPress.

Optimiser le cycle requête-réponse

Très bien, cela nous amène à la question évidente : comment faire en sorte qu'un serveur Web exécute ce cycle plus rapidement ? C'est une excellente question et fait partie de la raison pour laquelle la pile de serveurs WordPress moderne existe.

La pile existe parce que vous ne pouvez pas simplement rendre un serveur Web plus rapide. Un serveur Web est également un répartiteur. Il peut recevoir une demande et simplement la transmettre à d'autres services.

Ces autres services sont souvent le goulot d'étranglement de ce cycle demande-réponse. Avec WordPress, ce goulot d'étranglement est PHP, c'est pourquoi l'optimisation du cycle requête-réponse se résume à deux choses. Nous voulons que le serveur Web :

• recevoir le moins de demandes possible,
• transmettre le moins de requêtes possible à PHP.

La pile de serveurs WordPress moderne se concentre sur ce dernier. Il souhaite transmettre le moins de requêtes possible à PHP. Ce sera l'objectif principal de l'optimisation de la pile.

Nous nous concentrons sur le deuxième objectif car la pile ne peut pas faire grand-chose pour le premier ; il n'a pas d'impact direct sur lui. Le second est traité soit par la configuration du serveur Web, soit par les techniques de développement modernes.

Éléments de pile pour le cycle requête-réponse

Alors, quels sont les éléments de la pile qui nous aideront à réduire les requêtes transmises à PHP ? Eh bien, deux éléments de la pile en particulier nous aideront à atteindre cet objectif : le serveur Web et le cache HTTP.

Serveur Web

Nous avons déjà beaucoup parlé des serveurs Web. Il existe trois grands acteurs dans l'espace des serveurs Web :

• apache
• Services d'information sur Internet (IIS)
• nginx

Ensemble, ils représentent plus de 90 % de la part de marché des serveurs Web sur Internet. Nous allons nous concentrer sur Apache et nginx. Bien qu'IIS puisse être utilisé pour exécuter WordPress, ce n'est pas courant car il n'est disponible que pour Windows et la plupart des serveurs WordPress utilisent Linux.

Cela nous laisse avec Apache et nginx. Pendant toute la vie de WordPress, Apache a été le serveur Web recommandé. Nous avions la pile LAMP (Linux, Apache, MySQL et PHP), qui exécutait WordPress à la fois sur l'ordinateur et sur le serveur.

Mais dans les coulisses, les choses changeaient. Il y avait un nouveau joueur en ville, et son nom était nginx. Automattic et WordPress.com l'utilisent depuis 2008. C'est le serveur Web qui gère le plus grand pourcentage de sites Web à fort trafic (dont beaucoup utilisent WordPress). C'est pourquoi de nombreuses sociétés d'hébergement haut de gamme et les meilleures agences WordPress l'utilisent comme serveur Web.

Ce n'est pas qu'Apache soit un mauvais serveur Web. Il existe des experts Apache qui peuvent le faire fonctionner correctement sous un trafic important. Cela ne fonctionne tout simplement pas aussi bien hors de la boîte ou avec la configuration standard de WordPress.

Pendant ce temps, le seul but de nginx est de gérer beaucoup de trafic. C'est pourquoi Igor Sysoev a lancé le projet lorsqu'il travaillait chez Rambler.

L'une des raisons pour lesquelles nginx gère mieux le trafic est qu'il utilise FastCGI pour communiquer avec PHP. Qu'est-ce que FastCGI ? C'est un protocole qui permet à PHP de s'exécuter en tant que service distinct du serveur Web.

Apache ne le fait pas par défaut. Chaque fois que le serveur Web reçoit une requête, il doit démarrer un processus d'exécution PHP, même pour les images, JavaScript et CSS. Cela réduit le nombre de requêtes que le serveur peut traiter et la vitesse à laquelle il peut les traiter.

Cela va à l'encontre de l'un des objectifs de la pile de serveurs WordPress moderne, que nous avons vu précédemment. La pile doit maintenir le temps de cycle requête-réponse aussi bas que possible. Charger PHP pour chaque requête, même lorsqu'il n'en a pas besoin, va à l'encontre de cet objectif. Donc, si vous utilisez Apache, regardez FastCGI.

HTTP/2 est une autre fonctionnalité importante du serveur Web que vous devez connaître. C'est la prochaine version de HTTP, le protocole qui alimente tout notre cycle requête-réponse.

Avant l'arrivée de HTTP/2, un navigateur ne pouvait avoir que six connexions au serveur Web. Et chaque connexion ne pouvait traiter qu'une seule requête à la fois. Ainsi, en pratique, un cycle requête-réponse était plafonné à six requêtes par cycle.

C'est un vrai problème. La plupart des sites Web ont des dizaines de demandes dans leur cycle. Les développeurs et les administrateurs système ont trouvé des moyens astucieux de contourner cette limitation.

L'une des solutions de contournement les plus connues consiste à combiner des fichiers CSS et JavaScript. Dans un scénario idéal, cela ramènerait le nombre total de demandes de fichiers CSS et JavaScript à deux : une pour JavaScript et une pour CSS.

Ce n'est pas nécessaire avec HTTP/2. HTTP/2 autorise un nombre illimité de requêtes par connexion. Cela permet à toutes les requêtes supplémentaires après la réponse HTML initiale de se produire en même temps.

Cela a d'énormes répercussions sur les performances. Une grande partie du travail d'optimisation de la pile de serveurs est centrée sur le cycle requête-réponse. En réduisant le nombre de cycles à une poignée, HTTP/2 a fait un énorme travail pour nous.

Cache HTTP

La partie la plus importante de la pile de serveurs WordPress moderne est le cache HTTP. Dans le monde WordPress, nous appelons également cette page mise en cache. Le but du cache HTTP est de mettre en cache les réponses aux requêtes. Qu'est-ce que ça veut dire?

Eh bien, revenons à notre exemple précédent. Le navigateur envoie une demande pour la page d'accueil de modern.wordpress-stack.org , et le serveur Web reçoit cette demande et la transmet à PHP.

Le problème avec ce scénario est que le serveur Web est stupide. Il transmettra toujours toutes les requêtes qu'il reçoit à PHP, que la plupart des requêtes génèrent ou non la même réponse.

C'est exactement ce qui se passe lorsque les visiteurs ne sont pas connectés. Pour le serveur Web, ce sont toutes des demandes différentes, mais cela ne s'en soucie pas. Il les transmettra tous à PHP, qui générera la même réponse pour chacun d'eux.

C'est terrible! Comme nous l'avons vu précédemment, PHP est le véritable goulot d'étranglement de notre cycle requête-réponse. Votre navigateur ne peut pas envoyer ses demandes de suivi tant qu'il n'a pas reçu cette réponse initiale de la page d'accueil. Nous ne pouvons pas faire en sorte que le serveur Web transmette tout à PHP par défaut.

C'est là qu'intervient le cache HTTP. Il se situe entre le serveur Web et PHP. Son travail consiste à vérifier chaque requête reçue par le serveur Web et à rechercher une réponse en cache. S'il n'y en a pas, il transmettra la demande à PHP, puis mettra en cache la réponse générée par PHP.

Cela réduit considérablement le temps de cycle demande-réponse, ce qui accélère le chargement du site Web. Il permet également au serveur Web de gérer davantage de requêtes simultanées sans exploser.

Les différentes saveurs du cache HTTP

À ce stade, vous devriez vous demander : "Comment puis-je obtenir ce bébé sur mon serveur dès que possible ?" La bonne nouvelle est que l'installation d'un cache HTTP sur un serveur WordPress est assez simple. C'est le composant avec la plus large gamme d'options.

Installer un plugin de mise en cache de page

Le moyen le plus simple consiste à installer un plugin de mise en cache de page. Vous avez le choix entre plusieurs options :

• Cache de lot
• Hyper cache
• Activateur de cache
• Fusée WP
• WP Super Cache
• Cache total W3

Tous sauf WP Rocket sont disponibles sous forme de plugins gratuits dans le répertoire WordPress. Vous pouvez donc en installer un et le tester immédiatement. Cela étant dit, des quatre plugins, le meilleur est WP Rocket. Bien qu'il s'agisse d'un plugin payant, il fait bien plus que simplement créer un cache HTTP. Ces autres avantages amplifient le travail effectué par le cache HTTP.

Comment fonctionne un plugin de mise en cache de pages ?

Tous ces plugins exploitent un drop-in que WordPress a mis à disposition pour la mise en cache. Ce dépôt de mise en cache permet aux plugins de créer un système de cache HTTP à l'intérieur de WordPress. Le drop-in de mise en cache a besoin de deux choses pour fonctionner.

Tout d'abord, le fichier drop-in advanced-cache.php doit se trouver dans le dossier wp-content . C'est le vrai dossier. Mais contrairement à la plupart des drop-ins WordPress, celui-ci ne démarre pas par défaut. WordPress a également besoin que la constante WP_CACHE soit true pour charger le drop-in. Dans la plupart des cas, vous définiriez cela dans wp-config.php .

Le schéma ci-dessus montre ce qui se passe lorsque vous activez le drop-in avec un plugin de mise en cache. WordPress charge le drop-in dans wp-settings.php pendant son processus de chargement. C'est assez tôt dans le processus pour que WordPress n'ait encore rien fait qui prenne du temps.

Le plugin de mise en cache vérifiera alors s'il a déjà mis en cache la réponse à la requête. Si c'est le cas, il renverra cette réponse mise en cache. Si ce n'est pas le cas, il activera la mise en mémoire tampon de sortie PHP et WordPress poursuivra le chargement.

Maintenant, la mise en mémoire tampon de sortie est un système intéressant. Ce qu'il fait, c'est capturer toute la sortie d'un script PHP dans une variable de chaîne jusqu'à ce que l'une des deux choses se produise :

• vous dites à PHP d'arrêter de tamponner sa sortie en utilisant l'une des fonctions intégrées,
• le script PHP se termine et doit renvoyer une réponse au navigateur.

Le plugin de mise en cache compte sur ce dernier scénario. Il veut que WordPress fasse son travail et cache ensuite toute la sortie avant que PHP ne la renvoie au navigateur. Vous pouvez voir le processus dans le diagramme ci-dessous.

Demandez au serveur Web de le faire

L'option suivante consiste à ajouter un cache HTTP au niveau du serveur Web. La façon dont cela fonctionne est que le serveur Web mettra en cache toutes les réponses aux requêtes qui seront transmises à PHP. Cette solution est meilleure qu'un plugin de mise en cache car elle n'a pas du tout besoin de toucher à PHP.

Le diagramme ci-dessus donne un aperçu de ce qui se passe dans le serveur Web. Le serveur Web reçoit une demande et vérifie avec le cache HTTP. Si une réponse a déjà été mise en cache, le cache HTTP la renverra.

Sinon, il transmettra la requête au module PHP (généralement FastCGI). Il transmettra la demande à WordPress afin qu'il puisse générer une réponse. Le module de cache HTTP mettra ensuite en cache cette réponse au retour.

Apache et nginx offrent tous deux la possibilité d'ajouter un système de cache HTTP. Celui de nginx est intégré. Celui d'Apache est un module séparé que vous devez ajouter à votre installation Apache.

Il n'y a pas beaucoup d'informations sur la façon d'utiliser le module Apache avec PHP ou WordPress. C'est peut-être parce qu'il n'est pas populaire auprès de la foule Apache, ou peut-être parce qu'il a quelques problèmes. Il y a au moins un problème de longue date avec lui qui est toujours ouvert.

Pendant ce temps, le système de cache HTTP nginx est robuste et bien documenté. Vous pouvez l'utiliser comme un cache HTTP normal ou comme un micro-cache plus petit mais efficace. C'est juste une raison de plus pour laquelle nginx est le serveur Web préféré de nos jours.

Ajouter du vernis à la pile

Qu'est-ce que le vernis ? C'est un serveur de cache HTTP dédié (ou, comme ses développeurs aiment l'appeler, un accélérateur HTTP). La plupart des sites Web à fort trafic et des sociétés d'hébergement premium l'utilisent comme solution de cache HTTP.

Ils l'utilisent parce qu'il est puissant et offre le plus de flexibilité. Varnish a son propre langage de configuration, appelé VCL. Il vous permet de contrôler chaque élément du processus de mise en cache. Varnish est également livré avec de nombreux outils pour analyser ce que fait le cache et ses performances.

Ce sont les principales différences entre son utilisation et la simple utilisation du cache HTTP du serveur Web intégré. Le cache HTTP du serveur Web intégré est super performant mais aussi assez basique. Vous n'avez pas beaucoup de contrôle au-delà de quelques options de configuration.

Néanmoins, cette puissance et cette flexibilité ont un prix. Varnish est également l'option de cache HTTP la plus compliquée. Il ne fait que mettre en cache les réponses HTTP. Il ne gère pas la terminaison SSL, ce que la plupart des développeurs WordPress veulent (ou devraient vouloir). Cela signifie que notre pile de serveurs WordPress moderne sera plus complexe lorsque nous l'utiliserons.

Le schéma ci-dessus illustre cette complexité supplémentaire. Nous avons maintenant deux autres composants dans notre pile de serveurs WordPress : Varnish et un proxy inverse.

Le proxy inverse est là pour surmonter la limitation que Varnish a avec SSL. Il se trouve devant Varnish et décrypte les requêtes que notre serveur reçoit. Vous pouvez également appeler ce type de proxy inverse un proxy de terminaison SSL. Le proxy envoie ensuite ces requêtes décryptées à Varnish pour traitement.

Une fois qu'une requête arrive sur Varnish, le ou les fichiers de configuration VCL entrent en jeu. Ils sont le cerveau de Varnish. Par exemple, ils lui disent comment :

• analyser, nettoyer et modifier les demandes entrantes ;
• rechercher une réponse en cache ;
• analyser, nettoyer et modifier les réponses de retour de WordPress ;
• cache ces réponses renvoyées ;
• gérer une demande de suppression d'une ou plusieurs réponses du cache.

Ce dernier est particulièrement important. Laissé à lui-même, Varnish n'a aucun moyen de savoir quand WordPress veut supprimer une page du cache. Ainsi, par défaut, si vous apportez des modifications à une publication et que vous la mettez à jour, les visiteurs continueront de voir la même page en cache. Heureusement pour nous, il existe un plugin qui supprime les pages du cache Varnish.

Wordpress

Très bien, notre demande pour la page d'accueil de modern.wordpress-stack.org a atteint WordPress. Il est passé par le cycle demande-réponse que nous venons de couvrir. Le cache HTTP a tout fait pour trouver une réponse HTTP à renvoyer.

Mais il n'y avait pas de réponse HTTP en cache à renvoyer au navigateur. À ce stade, le cache HTTP n'avait pas d'autre choix. Il devait transmettre la requête HTTP à WordPress.

Tout est entre les mains de WordPress maintenant. WordPress doit transformer notre requête HTTP en une réponse HTTP et la renvoyer au cache HTTP. Comme nous l'avons vu précédemment, il s'agit du principal goulot d'étranglement de l'ensemble de notre pile de serveurs WordPress moderne.

La cause de ce goulot d'étranglement est double. WordPress a beaucoup de code PHP à exécuter. Cela prend du temps, et plus PHP est lent à le faire, plus cela prend du temps.

L'autre goulot d'étranglement est les requêtes de base de données que WordPress doit effectuer. Les requêtes de base de données sont des opérations coûteuses. Plus il y en a, plus WordPress est lent. Ce sera l'objet de la dernière section sur le cycle requête-résultat.

Optimiser le runtime PHP

Revenons à PHP. À l'heure actuelle, WordPress a une exigence minimale de PHP 5.2. Cette version de PHP a presque 10 ans ! (L'équipe PHP a cessé de le prendre en charge en 2011.)

L'équipe PHP n'est pas restée inactive pendant toutes ces années. De nombreuses améliorations de performances ont été apportées, en particulier au cours des dernières années. Voyons ce que vous pouvez faire pour l'optimiser de nos jours.

Utilisez la dernière version de PHP

La chose la plus simple que vous puissiez faire est de mettre à jour votre version de PHP. Les versions 5.4, 5.5 et 5.6 ont toutes vu des améliorations de performances. La plus grande amélioration est passée de 5,3 à 5,4. Le passage à celui-ci a augmenté les performances de WordPress d'une quantité décente.

Installer la mise en cache d'opcode

La mise en cache des opcodes est un autre moyen d'accélérer PHP. En tant que langage de script côté serveur, PHP a un gros défaut : il doit compiler un script PHP à chaque fois qu'il l'exécute.

La solution à ce problème est de mettre en cache le code PHP compilé. De cette façon, PHP n'a pas à le compiler à chaque fois qu'il l'exécute. C'est le travail du cache d'opcode.

Avant PHP 5.5, PHP n'était pas fourni avec un cache d'opcode. Vous deviez l'installer vous-même sur le serveur. C'est une autre raison pour laquelle il est préférable d'utiliser une version plus récente de PHP.

Passer à un compilateur de nouvelle génération

La dernière chose que vous puissiez faire est de passer à l'un des deux compilateurs de nouvelle génération : soit HHVM de Facebook, soit PHP 7, la dernière version de PHP. (Pourquoi PHP 7 ? C'est une longue histoire.)

Facebook et l'équipe PHP ont construit ces deux compilateurs à partir de zéro. Ils voulaient tirer parti de stratégies de compilation plus modernes. HHVM utilise la compilation juste-à-temps, tandis que PHP 7 utilise la compilation anticipée. Les deux offrent des améliorations de performances incroyables par rapport au bon vieux PHP 5.

HHVM a été le premier à arriver sur les lieux il y a quelques années. De nombreux hébergeurs de premier plan ont eu beaucoup de succès avec lui, l'offrant comme compilateur PHP principal.

Il convient de souligner, cependant, que HHVM n'est pas un compilateur PHP officiel. Ce n'est pas 100% compatible avec PHP. La raison en est que HHVM n'est pas seulement conçu pour prendre en charge PHP ; c'est aussi un compilateur pour le langage de programmation Hack de Facebook.

PHP 7 est un compilateur PHP officiel. Il n'existe plus depuis longtemps. L'équipe PHP l'a publié en décembre 2015. Cela n'a pas empêché certaines sociétés d'hébergement WordPress de le prendre déjà en charge.

La bonne nouvelle est que WordPress lui-même est 100 % compatible avec les deux compilateurs ! La mauvaise nouvelle est que tous les plugins et thèmes ne le sont pas, car la version minimale de PHP pour WordPress est toujours la 5.2.

Rien n'oblige les auteurs à faire fonctionner leurs plugins ou thèmes avec ces compilateurs. Donc, vous ne pouvez pas vous lancer avec l'un d'eux. Votre stack doit toujours revenir à PHP 5.

Cycle de requête-résultat

À ce stade, le runtime PHP parcourt tous les fichiers PHP de WordPress et les exécute. Cependant, ces fichiers PHP WordPress ne contiennent aucune donnée. Ils ne contiennent que le code WordPress.

Le problème est que WordPress stocke toutes ses données dans une base de données MySQL. Donc, pour y accéder, le runtime PHP doit interroger cette base de données. Le serveur MySQL renvoie le résultat de cette requête, et le runtime PHP continue ensuite à exécuter les fichiers WordPress PHP… enfin, jusqu'à ce qu'il ait à nouveau besoin de données.

Ce va-et-vient peut se produire de quelques dizaines à quelques centaines de fois. (Vous voudrez peut-être parler avec votre développeur si c'est ce dernier !) C'est pourquoi c'est un goulot d'étranglement majeur.

Optimiser le cycle requête-résultat

L'objectif d'optimisation ici est d'accélérer le temps d'exécution des fichiers WordPress par PHP. C'est là que les requêtes de base de données sont problématiques. Ils ont tendance à prendre plus de temps que de simplement exécuter du code PHP simple (à moins que votre code ne fasse quelque chose de scandaleux).

Le moyen évident de résoudre ce problème est de réduire le nombre de requêtes que WordPress doit effectuer. Et ça vaut toujours la peine ! Mais ce n'est pas quelque chose que la pile de serveurs WordPress moderne peut aider.

Nous ne pourrons peut-être pas réduire le nombre de requêtes effectuées par WordPress, mais nous ne manquons pas non plus d'options. La pile peut encore nous aider à optimiser le cycle requête-résultat de deux manières. Cela peut réduire le nombre de requêtes adressées à la base de données en premier lieu. Et pour les requêtes qui parviennent à la base de données, cela peut réduire le temps nécessaire à leur exécution.

Ces deux options sont toutes deux destinées à faire la même chose : faire attendre à PHP le moins possible les résultats de la base de données, ce qui rendra WordPress lui-même plus rapide.

Éléments de pile pour le cycle de résultat de requête

Examinons les différents éléments de la pile impliqués dans le cycle requête-résultat. Cette partie de la pile est moins complexe. Mais cela implique toujours plus d'un composant, à savoir le serveur de base de données MySQL et le cache d'objets.

Serveur de base de données MySQL

Il y a quelques années, un serveur de base de données MySQL signifiait la même chose pour tout le monde. C'était un serveur avec le serveur MySQL installé. Mais les choses ont beaucoup changé ces dernières années.

Divers groupes n'étaient pas satisfaits de la façon dont Oracle gérait le projet MySQL. Ainsi, chaque groupe l'a forké et a créé sa propre version que vous pouviez "déposer" à la place. Le résultat est qu'il existe maintenant plusieurs serveurs de bases de données MySQL.

Le nouveau serveur MySQL "officiel" est le serveur MariaDB. C'est la version développée par la communauté du serveur MySQL. La communauté prévoit de maintenir une compatibilité totale avec le projet de serveur MySQL.

Une autre alternative populaire à MySQL est le serveur Percona. Contrairement à MariaDB, Percona est plus une branche de MySQL. Ses développeurs ne sont pas contre le projet MySQL lui-même ; ils veulent juste se concentrer sur l'amélioration des performances de MySQL. L'équipe MariaDB a ensuite fusionné certaines de ces améliorations de performances dans le projet MariaDB.

À la fin de la journée, vous pouvez choisir celui que vous préférez. Il n'y a pas de différence de performances entre un serveur Percona et un serveur MariaDB (pour la plupart d'entre nous en tout cas). Ils fonctionnent tous les deux mieux que MySQL. Percona maintient cependant une compatibilité plus étroite avec le projet Oracle.

Ce qui affecte les performances, c'est le moteur de stockage utilisé par la base de données WordPress. Le moteur de stockage contrôle la façon dont le serveur de base de données gère les données qu'il stocke. Vous pouvez également définir un moteur de stockage différent par table de base de données ; vous n'êtes pas obligé d'utiliser le même pour toute la base de données.

Un serveur de base de données possède plusieurs moteurs de stockage. Nous n'allons pas tous les regarder. Seuls deux nous intéressent : InnoDB et MyISAM.

Par défaut, WordPress utilise le moteur de base de données MySQL par défaut. Avant MySQL 5.5, ce moteur était MyISAM. Si vous gérez un petit site Web WordPress, alors MyISAM convient. MyISAM rencontre des problèmes de performances une fois qu'un site Web grandit. À ce stade, InnoDB est le seul choix pour un moteur de base de données.

Le seul problème avec InnoDB est qu'il nécessite quelques réglages pour fonctionner au mieux. Si vous utilisez un serveur de base de données volumineux, vous devrez peut-être ajuster les choses. Heureusement pour nous, il existe un outil pour nous aider.

MySQLTuner est un petit script qui analyse votre serveur de base de données. Il générera un rapport et vous donnera des recommandations de réglage.

Cache d'objets

L'essentiel du travail d'optimisation du cycle requête-résultat repose sur le cache d'objets. Le travail du cache d'objets consiste à stocker des données qui prennent du temps à obtenir ou à générer. Comme vous pouvez le deviner, les requêtes de base de données sont un candidat parfait.

WordPress utilise beaucoup le cache d'objets. Disons que vous utilisez get_option pour obtenir une option de la base de données. WordPress n'interrogera la base de données qu'une seule fois pour cette option. Il ne l'interrogera plus la prochaine fois que quelqu'un en aura besoin.

Au lieu de cela, WordPress récupérera le résultat de la requête dans le cache d'objets. Il s'agit d'une étape proactive que WordPress prend pour réduire le nombre de requêtes de base de données qu'il doit effectuer. Mais ce n'est pas une solution infaillible.

Alors que WordPress fera de son mieux pour tirer parti du cache d'objets, un plugin ou un thème n'a pas à le faire. Si un plugin ou un thème effectue de nombreuses requêtes de base de données et ne met pas en cache les résultats, la pile ne peut rien y faire.

Dans de tels cas, la plupart des requêtes de base de données proviendront de WordPress lui-même. Ainsi, vous tirerez un grand parti de l'utilisation intégrée du cache d'objets dans WordPress. C'est pourquoi c'est un élément important de la pile de serveurs WordPress moderne.

Maintenant, un problème avec le cache d'objets est qu'il ne conserve pas les données qu'il stocke par défaut. Il stocke simplement les données en mémoire pendant que PHP exécute tous les fichiers WordPress. Mais une fois le processus PHP terminé, toutes les données stockées en mémoire sont effacées.

Ce n'est pas idéal du tout. Un cache d'objets peut rester valide pendant longtemps, vous ne voulez donc pas le limiter à une seule requête. La solution consiste à utiliser un cache d'objets persistant .

Un cache d'objets persistant se présente souvent sous la forme d'un plugin. Ce plugin utiliserait le drop-in object-cache.php pour faire son travail. Ce drop-in permet aux auteurs de plugins de modifier le comportement par défaut du cache d'objets.

Les plug-ins connectent ensuite le cache d'objets à un magasin de données persistant. Ils le font en remplaçant la fonctionnalité de récupération et de sauvegarde du cache d'objets par défaut. Au lieu d'enregistrer et de récupérer des données dans la mémoire, le cache d'objets le fait à partir de ce magasin.

Plugins de cache d'objets persistants

De nos jours, il existe deux options de stockage de données populaires pour la mise en cache d'objets persistants :

• Memcached (plugin)
• Redis (plugin)

Ces deux magasins de données utilisent la RAM pour le stockage, ce qui les rend ultra-rapides. En fait, leurs performances sont comparables à celles du cache d'objets par défaut.

Le seul problème est qu'ils ne sont pas préinstallés sur les serveurs. Et leur extension PHP non plus (qui est facultative avec Redis). Vous devez en installer un avant de pouvoir utiliser le plugin WordPress correspondant.

Lequel devriez-vous installer? En pratique, il n'y a pas beaucoup de différence entre les deux pour la mise en cache d'objets. Dans le passé, l'option populaire était Memcached. Cela a changé au cours des dernières années. Redis a ajouté de nombreuses fonctionnalités qui en ont fait l'option incontournable pour la mise en cache d'objets.

Obtenir votre propre serveur WordPress moderne

Alors, comment obtenez-vous votre propre serveur ? Le moyen le plus évident est d'en obtenir un auprès d'une société d'hébergement WordPress de premier plan. Ces entreprises veulent rester à la pointe de l'activité d'hébergement WordPress, ce qui les motive à adopter les dernières avancées et technologies.

Et si vous en vouliez un sans vous ruiner ? Quelques outils sont disponibles pour tous ceux qui préfèrent le faire eux-mêmes et payer moins pour l'hébergement. Regardons-les.

DebOps pour WordPress

DebOps pour WordPress est un outil que j'ai créé pour aider quiconque à créer un serveur WordPress moderne. Sa mission est de rendre la pile de serveurs WordPress moderne accessible à tous les membres de la communauté. C'est pourquoi j'essaie de le rendre aussi facile à utiliser que possible. Vous n'avez besoin d'aucune connaissance en administration système pour l'utiliser.

DebOps pour WordPress configure un serveur avec les éléments suivants :

• HHVM (jusqu'à ce que PHP 7 en fasse un référentiel Linux officiel)
• MariaDB
• nginx
• Redis
• Vernis

L'outil fait plus que simplement configurer un serveur avec les dernières technologies. Il s'occupe également de sécuriser le serveur pour vous. C'est quelque chose que les gens oublient souvent lorsqu'ils gèrent leur propre serveur.

EasyEngine

EasyEngine est un outil en ligne de commande conçu pour vous aider à configurer un site Web WordPress sur un serveur. L'avantage d'EasyEngine est sa flexibilité : vous pouvez l'utiliser pour configurer presque toutes les combinaisons de technologies de serveur que nous avons examinées jusqu'à présent.

Par exemple, il vous permet de configurer un serveur avec HHVM ou PHP 7. Il vous permet de choisir entre Memcached et Redis pour votre magasin de données persistant. Et il vous permet d'installer des outils d'administration tels que phpMyAdmin.

Il offre également un grand nombre d'options lorsqu'il crée un site Web WordPress. Vous pouvez lui dire de configurer un site Web avec un cache HTTP à l'aide d'un plugin ou de nginx. Toute cette flexibilité est la raison pour laquelle EasyEngine est un outil si populaire.

Treillis

Trellis est un outil développé par Roots. Comme DebOps, il configure le serveur avec un ensemble spécifique de technologies de serveur :

• MariaDB
• Memcaché
• nginx
• Cache HTTP nginx (facultatif)
• PHP 7

Une chose à savoir sur Trellis est sa relation avec Bedrock, un autre outil construit par Roots. Bedrock est un passe-partout pour structurer un site Web WordPress autour des principes « Twelve-Factor App ».

L'équipe Roots a créé Trellis pour permettre aux utilisateurs de configurer un serveur qui utilise un ou plusieurs sites Web WordPress structurés par Bedrock. Vous ne pouvez pas l'utiliser avec une installation WordPress normale, alors gardez cela à l'esprit.

Les temps ont changé

Comme vous pouvez le voir, un serveur WordPress a beaucoup plus de pièces mobiles aujourd'hui ! Mais cela ne doit pas être une cause de désespoir. Ce n'est pas aussi mauvais qu'il y paraît car vous n'avez pas toujours besoin d'utiliser toutes les pièces.

C'est pourquoi une grande partie de cet article traite de la façon dont ces parties fonctionnent ensemble. Le but est de vous permettre de prendre vos propres décisions. Utilisez ces connaissances pour décider quelles pièces vous devez utiliser et quand. De cette façon, vous aurez vous aussi un site WordPress rapide.