L\u2019h\u00e9bergement WordPress vous fournit un environnement optimis\u00e9 pour la fa\u00e7on dont WordPress se comporte sous charge, comment il g\u00e8re le cache et comment il ex\u00e9cute PHP. L’arriv\u00e9e r\u00e9cente des th\u00e8mes de blocs ne change pas les fondamentaux de l\u2019h\u00e9bergement, mais elle change parfois les endroits o\u00f9 les goulots d\u2019\u00e9tranglement apparaissent. <\/p>\n\n\n\n
C\u2019est l\u00e0 que le r\u00f4le de l\u2019h\u00e9bergeur devient plus clair. L\u2019infrastructure \u00e0 elle seule ne rend pas un site rapide, m\u00eame quand elle inclut une pile technologique compl\u00e8te, comme celle des h\u00e9bergements WordPress d’Ex2<\/a>. <\/p>\n\n\n\n Une configuration mal r\u00e9gl\u00e9e montrera des lacunes \u00e9videntes dans les workflows WordPress modernes. Cela se verra particuli\u00e8rement lorsque des blocs dynamiques, l\u2019\u00e9diteur de site, des aper\u00e7us et des sessions connect\u00e9es sont impliqu\u00e9s.<\/p>\n\n\n\n Pour comprendre pourquoi, nous examinerons d’abord ce qui se passe r\u00e9ellement lors d\u2019une requ\u00eate de page. Nous verrons ensuite comment les d\u00e9cisions d\u2019h\u00e9bergement affectent l\u2019exp\u00e9rience utilisateur lorsqu\u2019une architecture bas\u00e9e sur des blocs est utilis\u00e9e.<\/p>\n\n\n\n Pour commencer, examinons tout d’abord une requ\u00eate simple qui renvoie un code de r\u00e9ponse HTTP de succ\u00e8s (200 OK)<\/em>.<\/p>\n\n\n\n Le processus commence quand un internaute saisit une URL ou clique sur un lien. Si l\u2019adresse IP du serveur n\u2019est pas d\u00e9j\u00e0 mise en cache, le navigateur effectue alors une recherche DNS. Il ouvre ensuite une connexion TCP afin de n\u00e9gocier une session TLS s\u00e9curis\u00e9e.<\/p>\n\n\n\n Avant m\u00eame que WordPress ne soit impliqu\u00e9, la requ\u00eate passe par le serveur web et toutes les couches configur\u00e9es. Celles-ci incluent notamment les pare-feu ou les proxys invers\u00e9s.<\/p>\n\n\n\n Le serveur v\u00e9rifie si une version valide de la page demand\u00e9e est en cache.<\/p>\n\n\n\n Si un une version HTML pleine page valide est disponible dans le cache, WordPress ne s\u2019ex\u00e9cute pas. C’est alors la r\u00e9ponse mise en cache qui est renvoy\u00e9e imm\u00e9diatement.<\/p>\n\n\n\n Si aucune entr\u00e9e de cache n\u2019existe, ou si la mise en cache est intentionnellement contourn\u00e9e, la requ\u00eate continue plut\u00f4t vers WordPress.<\/p>\n\n\n\n WordPress charge les fichiers principaux de son noyau, les plugins actifs et le th\u00e8me actif. Il initialise des hooks et se pr\u00e9pare \u00e0 r\u00e9soudre la requ\u00eate.<\/p>\n\n\n\n \u00c0 ce stade, WordPress ne livre pas encore le r\u00e9sultat final. Il identifie et r\u00e9cup\u00e8re plut\u00f4t le contenu demand\u00e9.<\/p>\n\n\n\n En utilisant des r\u00e8gles de r\u00e9\u00e9criture et des variables de requ\u00eate, WordPress construit et ex\u00e9cute la requ\u00eate principale de la base de donn\u00e9es. <\/p>\n\n\n\n Il d\u00e9termine si la requ\u00eate concerne une publication unique, une page, une archive, un r\u00e9sultat de recherche ou un autre type de contenu.<\/p>\n\n\n\n Ce n\u2019est qu\u2019une fois cette \u00e9tape compl\u00e9t\u00e9e que la s\u00e9lection du mod\u00e8le commence.<\/p>\n\n\n\n C\u2019est l\u00e0 que les th\u00e8mes de bloc et classiques commencent \u00e0 diff\u00e9rer structurellement. Nous aborderons donc d\u00e9sormais les r\u00e9sultats s\u00e9par\u00e9ment.<\/p>\n\n\n\n WordPress \u00e9value la hi\u00e9rarchie des mod\u00e8les et s\u00e9lectionne le fichier mod\u00e8le PHP appropri\u00e9 (tel que single.php<\/em>, page.php<\/em> ou archive.php<\/em>). Ce fichier alors contient une logique PHP qui produit directement du code HTML.<\/p>\n\n\n\n WordPress v\u00e9rifie s\u2019il existe un mod\u00e8le de bloc personnalis\u00e9 dans la base de donn\u00e9es. Si un tel mod\u00e8le existe, il alors est prioritaire. Si ce n\u2019est pas le cas, WordPress revient plut\u00f4t au fichier mod\u00e8le de bloc inclus dans le th\u00e8me, comme single.html ou index.html.<\/p>\n\n\n\n Le mod\u00e8le s\u00e9lectionn\u00e9 est ensuite trait\u00e9 par le syst\u00e8me de rendu en bloc.<\/p>\n\n\n\n La pr\u00e9sentation est construite \u00e0 l\u2019aide de mod\u00e8les PHP. Ces mod\u00e8les combinent le balisage, la logique et les appels de fonction pour produire une sortie HTML.<\/p>\n\n\n\n La pr\u00e9sentation est assembl\u00e9e \u00e0 partir de mod\u00e8les de bloc, d\u2019\u00e9l\u00e9ments de mod\u00e8le et de contenu de publication. Le balisage des blocs est analys\u00e9, et chaque bloc est rendu en HTML avant la g\u00e9n\u00e9ration du r\u00e9sultat final.<\/p>\n\n\n\n Le contenu de la publication est principalement stock\u00e9 en tant que code HTML dans la base de donn\u00e9es. Lors du traitement de la requ\u00eate, WordPress applique des filtres, des shortcodes et d\u2019autres traitements avant le rendu.<\/p>\n\n\n\n Le contenu du bloc est stock\u00e9 en tant que code HTML avec des m\u00e9tadonn\u00e9es de bloc incorpor\u00e9es. Par exemple, elles peuvent ressembler \u00e0 ceci\u00a0:<\/p>\n\n\n\n Lorsque WordPress traite votre contenu, il analyse la structure en blocs, comprend les attributs et l\u2019imbrication. Il applique des attributs et des styles au niveau du bloc tels que l\u2019espacement, l\u2019alignement et la typographie avant de g\u00e9n\u00e9rer le code HTML final.<\/p>\n\n\n\n Le rendu dynamique existe \u00e0 la fois dans les th\u00e8mes classiques et par blocs. De nombreux th\u00e8mes classiques s\u2019appuient sur des requ\u00eates personnalis\u00e9es, des widgets ou des shortcodes qui g\u00e9n\u00e8rent une sortie \u00e0 l\u2019ex\u00e9cution.<\/p>\n\n\n\n Dans les architectures bas\u00e9es sur des blocs, le comportement dynamique est formalis\u00e9 par des blocs dynamiques. <\/p>\n\n\n\n Par exemple, un bloc de boucle de recherche g\u00e9n\u00e8re son balisage pendant la requ\u00eate en utilisant PHP plut\u00f4t que de stocker du code HTML statique dans la base de donn\u00e9es.<\/p>\n\n\n\n Lorsque la mise en cache d\u2019une page compl\u00e8te est contourn\u00e9e, ce flux de rendu se produit \u00e0 chaque requ\u00eate. Il peut alors ralentir le chargement votre site.<\/p>\n\n\n\n Pour les th\u00e8mes classiques, le style est g\u00e9n\u00e9ralement fourni via des fichiers CSS statiques mis en file d\u2019attente par le th\u00e8me.<\/p>\n\n\n\n Pour les th\u00e8mes de bloc, les styles globaux d\u00e9finis dans theme.json<\/em> et les m\u00e9tadonn\u00e9es de bloc permettent \u00e0 WordPress de g\u00e9n\u00e9rer automatiquement des feuilles de style coh\u00e9rentes.<\/p>\n\n\n\n Cela r\u00e9duit le besoin de grandes feuilles de style faites \u00e0 la main, en plus de centraliser la configuration du design.<\/p>\n\n\n\n Apr\u00e8s le traitement des mod\u00e8les, du contenu, des blocs et des styles, WordPress produit la r\u00e9ponse HTML finale.<\/p>\n\n\n\n Le serveur envoie alors la charge utile au navigateur. Si elle est configur\u00e9e, la r\u00e9ponse peut \u00eatre mise en cache pour de futures requ\u00eates.<\/p>\n\n\n\n Le cycle de vie des requ\u00eates que vous venez de parcourir s\u2019applique aux th\u00e8mes classiques et en blocs. WordPress r\u00e9sout encore les requ\u00eates, s\u00e9lectionne les mod\u00e8les, ex\u00e9cute PHP et renvoie le code HTML.<\/p>\n\n\n\n Ce qui change avec les th\u00e8mes en blocs, ce n\u2019est pas la base. C’est plut\u00f4t l\u2019endroit o\u00f9 le travail se fait et quand il ne peut pas \u00eatre ignor\u00e9.<\/p>\n\n\n\n Tout d\u2019abord, les mod\u00e8les peuvent vivre dans la base de donn\u00e9es. Lorsqu\u2019un utilisateur modifie un mod\u00e8le dans l\u2019\u00e9diteur de site, WordPress stocke cette version et lui donne la priorit\u00e9 sur le fichier du r\u00e9pertoire du th\u00e8me. <\/p>\n\n\n\n Cela ajoute de la flexibilit\u00e9, mais cela signifie aussi que les d\u00e9ploiements et l\u2019invalidation du cache doivent tenir compte des mod\u00e8les stock\u00e9s dans la base de donn\u00e9es.<\/p>\n\n\n\n Deuxi\u00e8mement, les blocs dynamiques rendent le rendu \u00e0 l\u2019ex\u00e9cution plus visible. Les th\u00e8mes classiques peuvent g\u00e9n\u00e9rer une sortie dynamique via des requ\u00eates personnalis\u00e9es, des widgets ou des shortcodes.<\/p>\n\n\n\n Les th\u00e8mes de bloc formalisent ce mod\u00e8le \u00e0 travers des blocs dynamiques, tels que le bloc Boucle de requ\u00eate<\/em>. Lorsque la mise en cache de page compl\u00e8te est contourn\u00e9e, ces blocs ex\u00e9cutent PHP pendant la requ\u00eate.<\/p>\n\n\n\n Troisi\u00e8mement, les flux de travail des \u00e9diteurs d\u00e9pendent fortement des points de terminaison REST. L\u2019enregistrement de mod\u00e8les, la mise \u00e0 jour de styles globaux, l\u2019aper\u00e7u des modifications et l\u2019interaction avec des motifs g\u00e9n\u00e8rent des requ\u00eates non mises en cache. <\/p>\n\n\n\n Ces chemins d\u00e9pendent directement de l\u2019ex\u00e9cution PHP, des performances de la base de donn\u00e9es et de la mise en cache des objets.<\/p>\n\n\n\n Enfin, les styles globaux d\u00e9finis dans theme.json<\/em> centralisent les d\u00e9cisions de design. Lorsque vous changez vos styles ou vos structures de mod\u00e8le, la coordination du cache devient plus importante afin de garantir que les visiteurs et les \u00e9diteurs voient imm\u00e9diatement les sorties mises \u00e0 jour.<\/p>\n\n\n\n Aucun de ces changements ne n\u00e9cessite un type d\u2019h\u00e9bergement diff\u00e9rent. Ils rendent toutefois certaines faiblesses d\u2019infrastructure plus visibles, en particulier dans les sc\u00e9narios sans cache et connect\u00e9s.<\/p>\n\n\n\n Dans cet esprit, la prochaine \u00e9tape consiste donc \u00e0 examiner ce qu\u2019un environnement d\u2019h\u00e9bergement bien configur\u00e9 doit g\u00e9rer dans une configuration bas\u00e9e sur des blocs.<\/p>\n\n\n\n Les th\u00e8mes de bloc n\u2019introduisent pas de nouvelles exigences d\u2019h\u00e9bergement. Ils rendent toutefois plus important le fait de corriger les th\u00e8mes existants.<\/p>\n\n\n\n Un environnement bien configur\u00e9 doit prendre en compte les chemins mis en cache et non mis en cache. C’est particuli\u00e8rement important pour les \u00e9diteurs et les utilisateurs connect\u00e9s.<\/p>\n\n\n\n La mise en cache pleine page reste la couche de performance la plus efficace pour le trafic anonyme. Les pages publiques doivent \u00eatre mises en cache de mani\u00e8re agressive, tandis que les aper\u00e7us, les sessions connect\u00e9es et les points de terminaison sp\u00e9cifiques sont automatiquement ignor\u00e9s.<\/p>\n\n\n\n La mise en cache des objets joue \u00e9galement un r\u00f4le important. En stockant des r\u00e9sultats de requ\u00eates r\u00e9p\u00e9t\u00e9s et des structures de donn\u00e9es calcul\u00e9es en m\u00e9moire, un cache d\u2019objet r\u00e9duit la charge de la base de donn\u00e9es et am\u00e9liore \u00e0 la fois la r\u00e9activit\u00e9 du frontend et du backend.<\/p>\n\n\n\n L\u2019invalidation du cache doit toutefois \u00eatre coordonn\u00e9e. Lorsque le contenu, les mod\u00e8les ou les styles globaux sont mis \u00e0 jour, les pages associ\u00e9es doivent s\u2019actualiser rapidement. <\/p>\n\n\n\n Une mauvaise coordination du cache peut entra\u00eener des pr\u00e9sentations obsol\u00e8tes, des styles incoh\u00e9rents ou un comportement d\u2019aper\u00e7u d\u00e9routant.<\/p>\n\n\n\n Un CDN compl\u00e8te cette configuration en mettant en cache des ressources statiques telles que des images, des polices et des scripts \u00e0 proximit\u00e9 des visiteurs.<\/p>\n\n\n\n La mise en cache ne concerne pas une seule couche, mais la fa\u00e7on dont ces couches fonctionnent ensemble.<\/p>\n\n\n\n Lorsque la mise en cache pleine page est contourn\u00e9e, WordPress ex\u00e9cute PHP pour r\u00e9soudre les requ\u00eates, rendre les mod\u00e8les et traiter les blocs dynamiques.<\/p>\n\n\n\n Cela rend la planification de la capacit\u00e9 PHP importante. L\u2019environnement doit fournir suffisamment de threads PHP pour g\u00e9rer la simultan\u00e9it\u00e9 attendue sans accumulation de files d\u2019attente. Les limites de m\u00e9moire doivent \u00eatre configur\u00e9es pour \u00e9viter tout \u00e9change sous charge.<\/p>\n\n\n\n Le cache doit \u00eatre activ\u00e9 et correctement dimensionn\u00e9 afin que le bytecode PHP n\u2019ait pas besoin d\u2019\u00eatre recompil\u00e9 \u00e0 plusieurs reprises. Lors des d\u00e9ploiements, le cache doit \u00eatre actualis\u00e9 afin que le code mis \u00e0 jour s\u2019ex\u00e9cute imm\u00e9diatement.<\/p>\n\n\n\n Ces pratiques s\u2019appliquent \u00e0 tous les sites WordPress, mais les workflows bas\u00e9s sur des blocs peuvent rendre les probl\u00e8mes de performance plus visibles lorsque le rendu est dynamique.<\/p>\n\n\n\n Les mod\u00e8les de bloc personnalis\u00e9s dans l\u2019\u00e9diteur de site sont stock\u00e9s dans la base de donn\u00e9es. Le contenu du bloc inclut des m\u00e9tadonn\u00e9es structur\u00e9es que WordPress analyse avant de les afficher. <\/p>\n\n\n\n Bien que ce traitement soit efficace, il d\u00e9pend toujours de la r\u00e9activit\u00e9 de la base de donn\u00e9es lorsque la mise en cache est contourn\u00e9e.<\/p>\n\n\n\n Un cache d\u2019objet persistant r\u00e9duit les requ\u00eates r\u00e9p\u00e9t\u00e9es et aide \u00e0 stabiliser les performances pour les visiteurs du front-end et les \u00e9diteurs travaillant dans le tableau de bord.<\/p>\n\n\n\n \u00c0 mesure que l\u2019activit\u00e9 augmente dans les chemins d\u2019ex\u00e9cution, la visibilit\u00e9 devient plus importante. Les h\u00f4tes et les propri\u00e9taires de sites doivent surveiller :<\/p>\n\n\n\n Les th\u00e8mes de bloc ne n\u00e9cessitent pas d\u2019infrastructure sp\u00e9cialis\u00e9e. Ils facilitent la visibilit\u00e9 lorsque l\u2019infrastructure est faiblement configur\u00e9e.<\/p>\n\n\n\n Les th\u00e8mes de bloc ne changent pas ce dont WordPress a besoin pour l\u2019h\u00e9bergement. Ils le rendent plus clair lorsque ces besoins ne sont pas satisfaits.<\/p>\n\n\n\n Lorsque les mod\u00e8les sont pr\u00e9sents dans la base de donn\u00e9es, que les blocs dynamiques sont rendus \u00e0 l\u2019ex\u00e9cution et que les \u00e9diteurs s\u2019appuient sur des requ\u00eates REST non mises en cache, l\u2019infrastructure n\u2019est plus invisible. Soit il prend en charge le flux de travail en douceur, soit il se met en travers.<\/p>\n\n\n\n C\u2019est l\u00e0 que l\u2019h\u00e9bergement optimis\u00e9 pour WordPress fait la diff\u00e9rence.<\/p>\n\n\n\n Chez Ex2, l\u2019ensemble de la pile est con\u00e7u sp\u00e9cifiquement pour le fonctionnement actuel de WordPress, de la mise en cache coordonn\u00e9e et de la mise en cache d\u2019objets persistants aux performances PHP ajust\u00e9es et \u00e0 la livraison CDN globale sur une infrastructure cloud puissante. <\/p>\n\n\n\n L\u2019objectif est de s\u2019assurer que les visiteurs et les \u00e9diteurs b\u00e9n\u00e9ficient de performances constantes, m\u00eame lorsque le rendu est dynamique.<\/p>\n\n\n\n WordPress bas\u00e9 sur des blocs n\u2019est pas plus lourd. Il est plus transparent. Et lorsque la base est solide, cette transparence joue en votre faveur.<\/p>\n\n\n\n Les th\u00e8mes de blocs WordPress vous offrent une foule de nouvelles possibilit\u00e9s de design pour la mise en page de votre site. Ils ont toutefois un impact important qui peut affecter ses performances et son bon fonctionnement. <\/p>\n\n\n\n Les besoins des sites WordPress ont ainsi augment\u00e9 au cours des derni\u00e8res ann\u00e9es. Vous devez d\u00e9sormais, plus que jamais, vous assurer de choisir un h\u00e9bergement performant et bien optimis\u00e9. Il vous faut choisir une infrastructure adapt\u00e9e, si vous voulez atteindre vos objectifs.<\/p>\n\n\n\n Nous esp\u00e9rons que cet article vous a plu et vous a \u00e9clair\u00e9 sur la fa\u00e7on dont les th\u00e8mes de blocs impactent WordPress. Si c\u2019est le cas, nous vous invitons \u00e0 consulter nos autres\u00a0articles et tutoriels<\/a>.<\/p>\n\n\n\nQue se passe-t-il lorsqu\u2019une page WordPress est demand\u00e9e?<\/h2>\n\n\n\n
Le navigateur envoie la requ\u00eate<\/h3>\n\n\n\n
V\u00e9rification du cache<\/h3>\n\n\n\n
WordPress s\u2019active<\/h3>\n\n\n\n
R\u00e9solution de la requ\u00eate principale<\/h3>\n\n\n\n
R\u00e9solution du mod\u00e8le: Th\u00e8mes de blocs vs. classiques<\/h3>\n\n\n\n
Th\u00e8mes classiques<\/h4>\n\n\n\n
Th\u00e8mes de blocs<\/h4>\n\n\n\n
Assemblage de pr\u00e9sentation: Th\u00e8mes de blocs vs. classiques<\/h3>\n\n\n\n
Th\u00e8mes classiques<\/h4>\n\n\n\n
Th\u00e8mes de blocs<\/h4>\n\n\n\n
Structure du contenu: Th\u00e8mes de blocs vs. classiques<\/h3>\n\n\n\n
Th\u00e8mes classiques<\/h4>\n\n\n\n
Th\u00e8mes de blocs<\/h4>\n\n\n\n
<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n\n\n\nRendu dynamique<\/h3>\n\n\n\n
Style<\/h3>\n\n\n\n
R\u00e9sultat final<\/h3>\n\n\n\n
O\u00f9 les th\u00e8mes de bloc d\u00e9placent-ils la charge?<\/h2>\n\n\n\n
Les principaux impacts des th\u00e8mes de blocs<\/h3>\n\n\n\n
Consid\u00e9rations relatives \u00e0 l\u2019h\u00e9bergement pour les sites bas\u00e9s sur des th\u00e8mes de blocs<\/h2>\n\n\n\n
Mise en cache coordonn\u00e9e entre les couches<\/h3>\n\n\n\n
Capacit\u00e9 PHP et performances d\u2019ex\u00e9cution<\/h3>\n\n\n\n
Mise en cache de la base de donn\u00e9es et des objets<\/h3>\n\n\n\n
Observabilit\u00e9 et suivi<\/h3>\n\n\n\n
\n
Utiliser WordPress de la mani\u00e8re dont il fonctionne aujourd\u2019hui<\/h2>\n\n\n\n
Pour conclure sur l’impact des th\u00e8mes de blocs sur l’h\u00e9bergement WordPress<\/h2>\n\n\n\n