L’hébergement WordPress infogéré a pour but d’assurer le bon fonctionnement de WordPress. Il offre un environnement optimisé pour le comportement de WordPress sous charge, sa gestion de la mise en cache et l’exécution du PHP.
Les thèmes basés sur des blocs ne modifient pas les principes fondamentaux de l’hébergement, mais ils changent l’emplacement des goulots d’étranglement en matière de performances. C’est là que le rôle de l’hébergeur web prend tout son sens. L’infrastructure à elle seule ne rend pas un site rapide ; une infrastructure mal optimisée se révèle dans les flux de travail WordPress modernes, en particulier lorsque des blocs dynamiques, l’éditeur de site, les aperçus et les sessions connectées sont impliqués.
Pour comprendre pourquoi, il est utile d’examiner ce qui se passe réellement lors d’une requête de page et comment les choix d’hébergement affectent l’expérience utilisateur lorsqu’une architecture basée sur des blocs est utilisée.
Que se passe-t-il lorsqu’une page WordPress est demandée ?
Passons en revue une requête simple qui renvoie une réponse 200 OK.
1. Le navigateur envoie la requête
Un utilisateur saisit une URL ou clique sur un lien. Si l’adresse IP du serveur n’est pas déjà mise en cache, le navigateur effectue une recherche DNS. Il ouvre ensuite une connexion TCP et négocie une session TLS sécurisée.
Avant que WordPress n’intervienne, la requête transite par le serveur web et toutes les couches configurées, telles que les pare-feu ou les proxies inversés.
2. Vérification du cache
Le serveur vérifie si une version mise en cache valide de la page demandée existe.
Si un cache HTML de la page entière est disponible et valide, WordPress ne s’exécute pas. La réponse mise en cache est renvoyée immédiatement.
Si aucune entrée de cache n’existe, ou si la mise en cache est intentionnellement contournée pour les utilisateurs connectés, les aperçus ou des points de terminaison spécifiques, la requête est transmise à WordPress.
3. WordPress se lance
WordPress charge ses fichiers principaux, les extensions actives et le thème actif. Il initialise les hooks (crochets) et se prépare à traiter la requête.
À ce stade, WordPress ne génère pas encore de sortie. Il détermine quel contenu est demandé.
4. Traitement de la requête principale
À l’aide de règles de réécriture et de variables de requête, WordPress construit et exécute la requête principale de la base de données. Il détermine si la requête concerne un article unique, une page, une archive, un résultat de recherche ou un autre type de contenu.
Ce n’est qu’après cela que la sélection du modèle commence.
5. Résolution du modèle
C’est à ce stade que les thèmes de blocs et les thèmes classiques commencent à différer sur le plan structurel.
Thèmes classiques
WordPress évalue la hiérarchie des modèles et sélectionne le fichier de modèle PHP approprié, tel que single.php, page.php ou archive.php. Ce fichier contient une logique PHP qui génère directement du code HTML.
Thèmes de blocs
WordPress vérifie si un modèle de bloc personnalisé existe dans la base de données. Si c’est le cas, celui-ci est prioritaire. Sinon, WordPress se rabat sur le fichier de modèle de bloc inclus dans le thème, tel que single.html ou index.html.
Le modèle sélectionné est ensuite traité par le système de rendu des blocs.
6. Assemblage de la mise en page
Thèmes classiques
La mise en page est construite à l’aide de modèles PHP. Ces modèles combinent balisage, logique et appels de fonction pour produire un résultat HTML.
Thèmes de blocs
La mise en page est assemblée à partir de modèles de blocs, de parties de modèles et du contenu des articles. Le balisage des blocs est analysé, et chaque bloc est converti en HTML avant que le résultat final ne soit généré.
7. Structure du contenu
Thèmes classiques
Le contenu des articles est principalement stocké au format HTML dans la base de données. Lors de la sortie, WordPress applique des filtres, des codes courts et d’autres traitements avant le rendu.
Thèmes de blocs
Le contenu des blocs est stocké au format HTML avec des métadonnées de bloc intégrées, par exemple :
<!-- wp:image {"id":123} -->
<img src="logo.png">
<!-- /wp:image -->Lorsque WordPress traite ce contenu, il analyse la structure des blocs, interprète 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énérer le code HTML final.
8. Rendu dynamique
Le rendu dynamique existe à la fois dans les thèmes classiques et dans les thèmes basés sur les blocs. De nombreux thèmes classiques s’appuient sur des requêtes personnalisées, des widgets ou des codes courts qui génèrent un résultat lors de l’exécution.
Dans les architectures basées sur les blocs, le comportement dynamique est formalisé par le biais de blocs dynamiques. Par exemple, un bloc « Boucle de requête (Query Loop) » génère son balisage lors de la requête à l’aide de PHP plutôt que de stocker du code HTML statique dans la base de données.
Lorsque la mise en cache pleine page est contournée, ce flux de travail de rendu s’effectue à chaque requête.
9. Mise en forme
Pour les thèmes classiques, la mise en forme est généralement assurée par des fichiers CSS statiques mis en file d’attente par le thème.
Pour les thèmes basés sur des blocs, les styles globaux définis dans le fichier theme.json et les métadonnées des blocs permettent à WordPress de générer automatiquement un CSS cohérent. Cela réduit le besoin de feuilles de style volumineuses créées manuellement et centralise la configuration du design.
10. Résultat final
Une fois les modèles, le contenu, les blocs et les styles traités, WordPress produit la réponse HTML finale.
Le serveur envoie la charge utile au navigateur. Si cela est configuré, la réponse peut ensuite être mise en cache pour les requêtes futures.
Où les thèmes de blocs déplacent la charge
Le cycle de vie des requêtes que vous venez de parcourir s’applique aussi bien aux thèmes classiques qu’aux thèmes de blocs. WordPress continue de résoudre les requêtes, de sélectionner les modèles, d’exécuter le PHP et de renvoyer du code HTML.
Ce qui change avec les thèmes de blocs, ce n’est pas le fondement, mais l’endroit où le travail s’effectue et le moment où il ne peut être ignoré.
Premièrement, les modèles peuvent résider dans la base de données. Lorsqu’un utilisateur modifie un modèle dans l’éditeur de site, WordPress stocke cette version et lui donne la priorité sur le fichier présent dans le répertoire du thème. Cela apporte davantage de flexibilité, mais cela signifie également que les déploiements et l’invalidation du cache doivent tenir compte des modèles stockés dans la base de données.
Deuxièmement, les blocs dynamiques rendent le rendu à l’exécution plus visible. Les thèmes classiques peuvent générer un rendu dynamique via des requêtes personnalisées, des widgets ou des codes courts. Les thèmes de blocs formalisent ce modèle à travers des blocs dynamiques, tels que le bloc « Boucle de requête ». Lorsque la mise en cache pleine page est contournée, ces blocs exécutent du code PHP pendant la requête.
Troisièmement, les workflows de l’éditeur s’appuient fortement sur les points de terminaison REST. L’enregistrement des modèles, la mise à jour des styles globaux, la prévisualisation des modifications et l’interaction avec les modèles génèrent des requêtes non mises en cache. Ces chemins dépendent directement de l’exécution PHP, des performances de la base de données et de la mise en cache des objets.
Enfin, les styles globaux définis dans theme.json centralisent les décisions de conception. Lorsque les styles ou les structures des modèles changent, la coordination du cache devient plus importante pour garantir que les visiteurs et les éditeurs voient immédiatement le résultat mis à jour.
Aucun de ces changements ne nécessite un type d’hébergement différent. Ils rendent toutefois certaines faiblesses de l’infrastructure plus visibles, en particulier dans les scénarios non mis en cache et avec connexion.
Dans cette optique, l’étape suivante consiste à examiner ce qu’un environnement d’hébergement bien configuré doit prendre en charge dans une configuration basée sur les blocs.
Considérations relatives à l’hébergement pour les sites basés sur des blocs
Les thèmes basés sur des blocs n’introduisent pas de nouvelles exigences en matière d’hébergement. Ils rendent simplement les exigences existantes plus importantes à respecter.
Un environnement bien configuré doit prendre en compte à la fois les chemins mis en cache et ceux qui ne le sont pas, en particulier pour les éditeurs et les utilisateurs connectés.
Mise en cache coordonnée entre les couches
La mise en cache de pages entières reste la couche de performance la plus efficace pour le trafic anonyme. Les pages publiques doivent être mises en cache de manière intensive, tandis que les aperçus, les sessions connectées et certains points de terminaison spécifiques sont automatiquement contournés.
La mise en cache d’objets joue également un rôle significatif. En stockant en mémoire les résultats de requêtes répétitives et les structures de données calculées, un cache d’objets réduit la charge de la base de données et améliore la réactivité tant au niveau du frontend que du backend.
L’invalidation du cache doit être coordonnée. Lorsque le contenu, les modèles ou les styles globaux sont mis à jour, les pages associées doivent s’actualiser rapidement. Une mauvaise coordination du cache peut entraîner des mises en page obsolètes, des styles incohérents ou un comportement de prévisualisation prêtant à confusion.
Un CDN complète cette configuration en mettant en cache les ressources statiques telles que les images, les polices et les scripts à proximité des visiteurs.
La mise en cache ne se limite pas à une seule couche. Elle repose sur la manière dont ces couches fonctionnent ensemble.
Capacité PHP et performances d’exécution
Lorsque la mise en cache pleine page est contournée, WordPress exécute du code PHP pour résoudre les requêtes, afficher les modèles et traiter les blocs dynamiques.
Cela rend la planification de la capacité PHP importante. L’environnement doit fournir suffisamment de threads PHP pour gérer la concurrence attendue sans accumulation de files d’attente. Les limites de mémoire doivent être configurées pour éviter le swap en cas de charge.
OPcache doit être activé et correctement dimensionné afin que le bytecode PHP n’ait pas besoin d’être recompilé à plusieurs reprises. Lors des déploiements, OPcache doit être actualisé afin que le code mis à jour s’exécute immédiatement.
Ces pratiques s’appliquent à tous les sites WordPress, mais les workflows basés sur des blocs peuvent rendre les problèmes de performances plus perceptibles lorsque le rendu est dynamique.
Mise en cache de la base de données et des objets
Les modèles de blocs personnalisés dans l’éditeur de site sont stockés dans la base de données. Le contenu des blocs comprend des métadonnées structurées que WordPress analyse avant l’affichage. Bien que ce traitement soit efficace, il dépend néanmoins de la réactivité de la base de données lorsque la mise en cache est contournée.
Un cache d’objets persistant réduit les requêtes répétées et contribue à stabiliser les performances tant pour les visiteurs du frontend que pour les éditeurs travaillant dans le tableau de bord.
Observabilité et surveillance
À mesure que l’activité se déplace vers les chemins d’exécution, la visibilité devient plus importante. Les hébergeurs et les propriétaires de sites doivent surveiller :
- Les taux de réussite du cache
- L’utilisation des workers PHP et la longueur de la file d’attente
- Les performances des requêtes de base de données
- Les temps de réponse de l’API REST
- Le temps de réponse (Time to First Byte) pour les requêtes mises en cache et non mises en cache
Les thèmes basés sur des blocs ne nécessitent pas d’infrastructure spécialisée. Ils permettent toutefois de repérer plus facilement les cas où l’infrastructure est mal configurée.
Utilisation de WordPress tel qu’il fonctionne aujourd’hui
Les thèmes basés sur des blocs ne modifient pas les exigences de WordPress en matière d’hébergement. Ils permettent simplement de voir plus clairement quand ces exigences ne sont pas satisfaites.
Lorsque les modèles résident dans la base de données, que les blocs dynamiques s’affichent au moment de l’exécution et que les éditeurs s’appuient sur des requêtes REST non mises en cache, l’infrastructure n’est plus invisible. Soit elle soutient le flux de travail de manière fluide, soit elle constitue un obstacle.
C’est là que l’hébergement infogéré pour WordPress fait la différence.
Chez Kinsta, l’ensemble de la pile est spécialement conçu pour le fonctionnement actuel de WordPress, de la mise en cache coordonnée et de la mise en cache d’objets persistants aux performances PHP optimisées et à la diffusion CDN mondiale sur une infrastructure cloud puissante. L’objectif est de garantir aux visiteurs comme aux éditeurs des performances constantes, même lorsque le rendu s’effectue de manière dynamique.
WordPress basé sur les blocs n’est pas plus lourd. Il est plus transparent. Et lorsque les fondations sont solides, cette transparence joue en votre faveur.
Bud Kraus has been working with WordPress as an in-class and online instructor, site developer, and content creator since 2009. He has produced instructional videos and written many articles for WordPress businesses.
