{"id":82890,"date":"2026-03-27T10:27:30","date_gmt":"2026-03-27T09:27:30","guid":{"rendered":"https:\/\/kinsta.com\/fr\/?p=82890&preview=true&preview_id=82890"},"modified":"2026-03-30T09:41:42","modified_gmt":"2026-03-30T08:41:42","slug":"themes-blocs-hebergement-wordpress","status":"publish","type":"post","link":"https:\/\/kinsta.com\/fr\/blog\/themes-blocs-hebergement-wordpress\/","title":{"rendered":"Comment les th\u00e8mes modernes bas\u00e9s sur des blocs transforment l’h\u00e9bergement WordPress"},"content":{"rendered":"

L’h\u00e9bergement WordPress infog\u00e9r\u00e9 a pour but d’assurer le bon fonctionnement de WordPress. Il offre un environnement optimis\u00e9 pour le comportement de WordPress sous charge, sa gestion de la mise en cache<\/a> et l’ex\u00e9cution du PHP.<\/p>\n

Les th\u00e8mes bas\u00e9s sur des blocs<\/a> ne modifient pas les principes fondamentaux de l’h\u00e9bergement, mais ils changent l’emplacement des goulots d’\u00e9tranglement en mati\u00e8re de performances. C’est l\u00e0 que le r\u00f4le de l’h\u00e9bergeur web prend tout son sens. L’infrastructure \u00e0 elle seule ne rend pas un site rapide ; une infrastructure mal optimis\u00e9e se r\u00e9v\u00e8le dans les flux de travail WordPress modernes, en particulier lorsque des blocs dynamiques, l’\u00e9diteur de site<\/a>, les aper\u00e7us et les sessions connect\u00e9es sont impliqu\u00e9s.<\/p>\n

Pour comprendre pourquoi, il est utile d’examiner ce qui se passe r\u00e9ellement lors d’une requ\u00eate de page et comment les choix d’h\u00e9bergement affectent l’exp\u00e9rience utilisateur lorsqu’une architecture bas\u00e9e sur des blocs est utilis\u00e9e.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Que se passe-t-il lorsqu\u2019une page WordPress est demand\u00e9e ?<\/h2>\n

Passons en revue une requ\u00eate simple qui renvoie une r\u00e9ponse 200 OK<\/a>.<\/p>\n

1. Le navigateur envoie la requ\u00eate<\/h3>\n

Un utilisateur 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 une recherche DNS<\/a>. Il ouvre ensuite une connexion TCP et n\u00e9gocie une session TLS<\/a> s\u00e9curis\u00e9e.<\/p>\n

Avant que WordPress n\u2019intervienne, la requ\u00eate transite par le serveur web et toutes les couches configur\u00e9es, telles que les pare-feu ou les proxies invers\u00e9s.<\/p>\n

2. V\u00e9rification du cache<\/h3>\n

Le serveur v\u00e9rifie si une version mise en cache valide de la page demand\u00e9e existe.<\/p>\n

Si un cache HTML de la page enti\u00e8re<\/a> est disponible et valide, WordPress ne s\u2019ex\u00e9cute pas. La r\u00e9ponse mise en cache est renvoy\u00e9e imm\u00e9diatement.<\/p>\n

Si aucune entr\u00e9e de cache n\u2019existe, ou si la mise en cache est intentionnellement contourn\u00e9e pour les utilisateurs connect\u00e9s, les aper\u00e7us ou des points de terminaison sp\u00e9cifiques, la requ\u00eate est transmise \u00e0 WordPress.<\/p>\n

3. WordPress se lance<\/h3>\n

WordPress charge ses fichiers principaux, les extensions actives et le th\u00e8me actif. Il initialise les hooks (crochets) et se pr\u00e9pare \u00e0 traiter la requ\u00eate.<\/p>\n

\u00c0 ce stade, WordPress ne g\u00e9n\u00e8re pas encore de sortie. Il d\u00e9termine quel contenu est demand\u00e9.<\/p>\n

4. Traitement de la requ\u00eate principale<\/h3>\n

\u00c0 l’aide de r\u00e8gles de r\u00e9\u00e9criture et de variables de requ\u00eate, WordPress construit et ex\u00e9cute la requ\u00eate principale de la base de donn\u00e9es. Il d\u00e9termine si la requ\u00eate concerne un article unique, une page, une archive, un r\u00e9sultat de recherche ou un autre type de contenu.<\/p>\n

Ce n’est qu’apr\u00e8s cela que la s\u00e9lection du mod\u00e8le commence.<\/p>\n

5. R\u00e9solution du mod\u00e8le<\/h3>\n

C’est \u00e0 ce stade que les th\u00e8mes de blocs et les th\u00e8mes classiques commencent \u00e0 diff\u00e9rer sur le plan structurel.<\/p>\n

Th\u00e8mes classiques<\/h4>\n

WordPress \u00e9value la hi\u00e9rarchie des mod\u00e8les et s\u00e9lectionne le fichier de mod\u00e8le PHP appropri\u00e9, tel que single.php, page.php ou archive.php. Ce fichier contient une logique PHP qui g\u00e9n\u00e8re directement du code HTML.<\/p>\n

Th\u00e8mes de blocs<\/h4>\n

WordPress v\u00e9rifie si un mod\u00e8le de bloc personnalis\u00e9 existe dans la base de donn\u00e9es. Si c’est le cas, celui-ci est prioritaire. Sinon, WordPress se rabat sur le fichier de mod\u00e8le de bloc inclus dans le th\u00e8me, tel que single.html ou index.html.<\/p>\n

Le mod\u00e8le s\u00e9lectionn\u00e9 est ensuite trait\u00e9 par le syst\u00e8me de rendu des blocs.<\/p>\n

6. Assemblage de la mise en page<\/h3>\n

Th\u00e8mes classiques<\/h4>\n

La mise en page est construite \u00e0 l’aide de mod\u00e8les PHP. Ces mod\u00e8les combinent balisage, logique et appels de fonction pour produire un r\u00e9sultat HTML.<\/p>\n

Th\u00e8mes de blocs<\/h4>\n

La mise en page est assembl\u00e9e \u00e0 partir de mod\u00e8les de blocs, de parties de mod\u00e8les et du contenu des articles. Le balisage des blocs est analys\u00e9, et chaque bloc est converti en HTML avant que le r\u00e9sultat final ne soit g\u00e9n\u00e9r\u00e9.<\/p>\n

7. Structure du contenu<\/h3>\n

Th\u00e8mes classiques<\/h4>\n

Le contenu des articles est principalement stock\u00e9 au format HTML dans la base de donn\u00e9es. Lors de la sortie, WordPress applique des filtres, des codes courts et d’autres traitements avant le rendu.<\/p>\n

Th\u00e8mes de blocs<\/h4>\n

Le contenu des blocs est stock\u00e9 au format HTML avec des m\u00e9tadonn\u00e9es de bloc int\u00e9gr\u00e9es, par exemple :<\/p>\n

<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n
Lorsque WordPress traite ce contenu, il analyse la structure des blocs, interpr\u00e8te les attributs et l’imbrication, puis applique les attributs et les styles au niveau des blocs, tels que l’espacement, l’alignement et la typographie, avant de g\u00e9n\u00e9rer le code HTML final.<\/p>\n
8. Rendu dynamique<\/h3>\n
Le rendu dynamique existe \u00e0 la fois dans les th\u00e8mes classiques et dans les th\u00e8mes bas\u00e9s sur les blocs. De nombreux th\u00e8mes classiques s\u2019appuient sur des requ\u00eates personnalis\u00e9es, des widgets ou des codes courts qui g\u00e9n\u00e8rent un r\u00e9sultat lors de l\u2019ex\u00e9cution.<\/p>\n
Dans les architectures bas\u00e9es sur les blocs, le comportement dynamique est formalis\u00e9 par le biais de blocs dynamiques. Par exemple, un bloc \u00ab Boucle de requ\u00eate (Query Loop) \u00bb g\u00e9n\u00e8re son balisage lors de la requ\u00eate \u00e0 l\u2019aide de PHP plut\u00f4t que de stocker du code HTML statique dans la base de donn\u00e9es.<\/p>\n
Lorsque la mise en cache pleine page est contourn\u00e9e, ce flux de travail de rendu s\u2019effectue \u00e0 chaque requ\u00eate.<\/p>\n
9. Mise en forme<\/h3>\n
Pour les th\u00e8mes classiques, la mise en forme est g\u00e9n\u00e9ralement assur\u00e9e par des fichiers CSS statiques<\/a> mis en file d\u2019attente par le th\u00e8me.<\/p>\n
Pour les th\u00e8mes bas\u00e9s sur des blocs, les styles globaux d\u00e9finis dans le fichier theme.json<\/code> et les m\u00e9tadonn\u00e9es des blocs permettent \u00e0 WordPress de g\u00e9n\u00e9rer automatiquement un CSS coh\u00e9rent. Cela r\u00e9duit le besoin de feuilles de style volumineuses cr\u00e9\u00e9es manuellement et centralise la configuration du design.<\/p>\n
10. R\u00e9sultat final<\/h3>\n
Une fois les mod\u00e8les, le contenu, les blocs et les styles trait\u00e9s, WordPress produit la r\u00e9ponse HTML finale.<\/p>\n
Le serveur envoie la charge utile au navigateur. Si cela est configur\u00e9, la r\u00e9ponse peut ensuite \u00eatre mise en cache pour les requ\u00eates futures.<\/p>\n
O\u00f9 les th\u00e8mes de blocs d\u00e9placent la charge<\/h2>\n
Le cycle de vie des requ\u00eates que vous venez de parcourir s\u2019applique aussi bien aux th\u00e8mes classiques qu\u2019aux th\u00e8mes de blocs<\/a>. WordPress continue de r\u00e9soudre les requ\u00eates, de s\u00e9lectionner les mod\u00e8les, d\u2019ex\u00e9cuter le PHP et de renvoyer du code HTML.<\/p>\n
Ce qui change avec les th\u00e8mes de blocs, ce n\u2019est pas le fondement, mais l\u2019endroit o\u00f9 le travail s\u2019effectue et le moment o\u00f9 il ne peut \u00eatre ignor\u00e9.<\/p>\n
Premi\u00e8rement, les mod\u00e8les<\/a> peuvent r\u00e9sider 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 pr\u00e9sent dans le r\u00e9pertoire du th\u00e8me. Cela apporte davantage de flexibilit\u00e9, mais cela signifie \u00e9galement 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
Deuxi\u00e8mement, les blocs dynamiques<\/a> rendent le rendu \u00e0 l’ex\u00e9cution plus visible. Les th\u00e8mes classiques peuvent g\u00e9n\u00e9rer un rendu dynamique via des requ\u00eates personnalis\u00e9es, des widgets ou des codes courts. Les th\u00e8mes de blocs formalisent ce mod\u00e8le \u00e0 travers des blocs dynamiques, tels que le bloc \u00ab Boucle de requ\u00eate \u00bb. Lorsque la mise en cache pleine page est contourn\u00e9e, ces blocs ex\u00e9cutent du code PHP pendant la requ\u00eate.<\/p>\n
Troisi\u00e8mement, les workflows de l\u2019\u00e9diteur s\u2019appuient fortement sur les points de terminaison REST. L\u2019enregistrement des mod\u00e8les, la mise \u00e0 jour des styles globaux, la pr\u00e9visualisation des modifications et l\u2019interaction avec les mod\u00e8les g\u00e9n\u00e8rent des requ\u00eates non mises en cache. 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
Enfin, les styles globaux d\u00e9finis dans theme.json<\/a><\/code> centralisent les d\u00e9cisions de conception. Lorsque les styles ou les structures des mod\u00e8les changent, la coordination du cache devient plus importante pour garantir que les visiteurs et les \u00e9diteurs voient imm\u00e9diatement le r\u00e9sultat mis \u00e0 jour.<\/p>\n
Aucun de ces changements ne n\u00e9cessite un type d\u2019h\u00e9bergement diff\u00e9rent. Ils rendent toutefois certaines faiblesses de l\u2019infrastructure plus visibles, en particulier dans les sc\u00e9narios non mis en cache et avec connexion.
\nDans cette optique, l\u2019\u00e9tape suivante consiste \u00e0 examiner ce qu\u2019un environnement d\u2019h\u00e9bergement bien configur\u00e9 doit prendre en charge dans une configuration bas\u00e9e sur les blocs.<\/p>\n
Consid\u00e9rations relatives \u00e0 l\u2019h\u00e9bergement pour les sites bas\u00e9s sur des blocs<\/h2>\n
Les th\u00e8mes bas\u00e9s sur des blocs n\u2019introduisent pas de nouvelles exigences en mati\u00e8re d\u2019h\u00e9bergement. Ils rendent simplement les exigences existantes plus importantes \u00e0 respecter.<\/p>\n
Un environnement bien configur\u00e9 doit prendre en compte \u00e0 la fois les chemins mis en cache et ceux qui ne le sont pas, en particulier pour les \u00e9diteurs et les utilisateurs connect\u00e9s.<\/p>\n
Mise en cache coordonn\u00e9e entre les couches<\/h3>\n
La mise en cache de pages enti\u00e8res<\/a> reste la couche de performance la plus efficace pour le trafic anonyme. Les pages publiques doivent \u00eatre mises en cache de mani\u00e8re intensive, tandis que les aper\u00e7us, les sessions connect\u00e9es et certains points de terminaison sp\u00e9cifiques sont automatiquement contourn\u00e9s.
\nLa mise en cache d’objets<\/a> joue \u00e9galement un r\u00f4le significatif. En stockant en m\u00e9moire les r\u00e9sultats de requ\u00eates r\u00e9p\u00e9titives et les structures de donn\u00e9es calcul\u00e9es, un cache d’objets r\u00e9duit la charge de la base de donn\u00e9es et am\u00e9liore la r\u00e9activit\u00e9 tant au niveau du frontend que du backend.<\/p>\n
L’invalidation du cache doit \u00eatre coordonn\u00e9e. Lorsque le contenu, les mod\u00e8les ou les styles globaux sont mis \u00e0 jour, les pages associ\u00e9es doivent s’actualiser rapidement. Une mauvaise coordination du cache peut entra\u00eener des mises en page obsol\u00e8tes, des styles incoh\u00e9rents ou un comportement de pr\u00e9visualisation pr\u00eatant \u00e0 confusion.<\/p>\n
Un CDN compl\u00e8te cette configuration en mettant en cache les ressources statiques telles que les images, les polices et les scripts \u00e0 proximit\u00e9 des visiteurs.<\/p>\n
La mise en cache<\/a> ne se limite pas \u00e0 une seule couche. Elle repose sur la mani\u00e8re dont ces couches fonctionnent ensemble.<\/p>\n
Capacit\u00e9 PHP et performances d’ex\u00e9cution<\/h3>\n
Lorsque la mise en cache pleine page est contourn\u00e9e, WordPress ex\u00e9cute du code PHP pour r\u00e9soudre les requ\u00eates, afficher les mod\u00e8les et traiter les blocs dynamiques.<\/p>\n
Cela rend la planification de la capacit\u00e9 PHP importante. L\u2019environnement doit fournir suffisamment de threads PHP<\/a> pour g\u00e9rer la concurrence attendue sans accumulation de files d\u2019attente. Les limites de m\u00e9moire<\/a> doivent \u00eatre configur\u00e9es pour \u00e9viter le swap en cas de charge.<\/p>\n
OPcache 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, OPcache doit \u00eatre actualis\u00e9 afin que le code mis \u00e0 jour s\u2019ex\u00e9cute imm\u00e9diatement.<\/p>\n
Ces pratiques s\u2019appliquent \u00e0 tous les sites WordPress, mais les workflows bas\u00e9s sur des blocs peuvent rendre les probl\u00e8mes de performances plus perceptibles lorsque le rendu est dynamique.<\/p>\n
Mise en cache de la base de donn\u00e9es et des objets<\/h3>\n
Les mod\u00e8les de blocs personnalis\u00e9s dans l\u2019\u00e9diteur de site sont stock\u00e9s dans la base de donn\u00e9es. Le contenu des blocs comprend des m\u00e9tadonn\u00e9es structur\u00e9es que WordPress analyse avant l\u2019affichage. Bien que ce traitement soit efficace, il d\u00e9pend n\u00e9anmoins de la r\u00e9activit\u00e9 de la base de donn\u00e9es lorsque la mise en cache est contourn\u00e9e.<\/p>\n
Un cache d\u2019objets persistant r\u00e9duit les requ\u00eates r\u00e9p\u00e9t\u00e9es et contribue \u00e0 stabiliser les performances tant pour les visiteurs du frontend que pour les \u00e9diteurs travaillant dans le tableau de bord.<\/p>\n
Observabilit\u00e9 et surveillance<\/h3>\n
\u00c0 mesure que l’activit\u00e9 se d\u00e9place vers les chemins d’ex\u00e9cution, la visibilit\u00e9 devient plus importante. Les h\u00e9bergeurs et les propri\u00e9taires de sites doivent surveiller :<\/p>\n