Les thèmes de blocs impactent votre hébergement WordPress

L’hébergement WordPress vous fournit un environnement optimisé pour la façon dont WordPress se comporte sous charge, comment il gère le cache et comment il exécute PHP. L’arrivée récente des thèmes de blocs ne change pas les fondamentaux de l’hébergement, mais elle change parfois les endroits où les goulots d’étranglement apparaissent.

C’est là que le rôle de l’hébergeur devient plus clair. L’infrastructure à elle seule ne rend pas un site rapide, même quand elle inclut une pile technologique complète, comme celle des hébergements WordPress d’Ex2.

Une configuration mal réglée montrera des lacunes évidentes dans les workflows WordPress modernes. Cela se verra particulièrement lorsque des blocs dynamiques, l’éditeur de site, des aperçus et des sessions connectées sont impliqués.

Pour comprendre pourquoi, nous examinerons d’abord ce qui se passe réellement lors d’une requête de page. Nous verrons ensuite comment les décisions 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?

Pour commencer, examinons tout d’abord une requête simple qui renvoie un code de réponse HTTP de succès (200 OK).

Le navigateur envoie la requête

Le processus commence quand un internaute 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 alors une recherche DNS. Il ouvre ensuite une connexion TCP afin de négocier une session TLS sécurisée.

Avant même que WordPress ne soit impliqué, la requête passe par le serveur web et toutes les couches configurées. Celles-ci incluent notamment les pare-feu ou les proxys inversés.

Vérification du cache

Le serveur vérifie si une version valide de la page demandée est en cache.

Si un une version HTML pleine page valide est disponible dans le cache, WordPress ne s’exécute pas. C’est alors la réponse mise en cache qui est renvoyée immédiatement.

Si aucune entrée de cache n’existe, ou si la mise en cache est intentionnellement contournée, la requête continue plutôt vers WordPress.

WordPress s’active

WordPress charge les fichiers principaux de son noyau, les plugins actifs et le thème actif. Il initialise des hooks et se prépare à résoudre la requête.

À ce stade, WordPress ne livre pas encore le résultat final. Il identifie et récupère plutôt le contenu demandé.

Résolution de la requête principale

En utilisant des règles de réécriture et des 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 une publication unique, une page, une archive, un résultat de recherche ou un autre type de contenu.

Ce n’est qu’une fois cette étape complétée que la sélection du modèle commence.

Résolution du modèle: Thèmes de blocs vs. classiques

C’est là que les thèmes de bloc et classiques commencent à différer structurellement. Nous aborderons donc désormais les résultats séparément.

Thèmes classiques

WordPress évalue la hiérarchie des modèles et sélectionne le fichier modèle PHP approprié (tel que single.php, page.php ou archive.php). Ce fichier alors contient une logique PHP qui produit directement du code HTML.

Thèmes de blocs

WordPress vérifie s’il existe un modèle de bloc personnalisé dans la base de données. Si un tel modèle existe, il alors est prioritaire. Si ce n’est pas le cas, WordPress revient plutôt au fichier modèle de bloc inclus dans le thème, comme single.html ou index.html.

Le modèle sélectionné est ensuite traité par le système de rendu en bloc.

Assemblage de présentation: Thèmes de blocs vs. classiques

Thèmes classiques

La présentation est construite à l’aide de modèles PHP. Ces modèles combinent le balisage, la logique et les appels de fonction pour produire une sortie HTML.

Thèmes de blocs

La présentation est assemblée à partir de modèles de bloc, d’éléments de modèle et de contenu de publication. Le balisage des blocs est analysé, et chaque bloc est rendu en HTML avant la génération du résultat final.

Structure du contenu: Thèmes de blocs vs. classiques

Thèmes classiques

Le contenu de la publication est principalement stocké en tant que code HTML dans la base de données. Lors du traitement de la requête, WordPress applique des filtres, des shortcodes et d’autres traitements avant le rendu.

Thèmes de blocs

Le contenu du bloc est stocké en tant que code HTML avec des métadonnées de bloc incorporées. Par exemple, elles peuvent ressembler à ceci :

<!-- wp:image {"id":123} -->

<img src="logo.png">

<!-- /wp:image -->

Lorsque WordPress traite votre contenu, il analyse la structure en blocs, comprend les attributs et l’imbrication. Il applique des attributs et des styles au niveau du bloc tels que l’espacement, l’alignement et la typographie avant de générer le code HTML final.

Rendu dynamique

Le rendu dynamique existe à la fois dans les thèmes classiques et par blocs. De nombreux thèmes classiques s’appuient sur des requêtes personnalisées, des widgets ou des shortcodes qui génèrent une sortie à l’exécution.

Dans les architectures basées sur des blocs, le comportement dynamique est formalisé par des blocs dynamiques.

Par exemple, un bloc de boucle de recherche génère son balisage pendant la requête en utilisant PHP plutôt que de stocker du code HTML statique dans la base de données.

Lorsque la mise en cache d’une page complète est contournée, ce flux de rendu se produit à chaque requête. Il peut alors ralentir le chargement votre site.

Style

Pour les thèmes classiques, le style est généralement fourni via des fichiers CSS statiques mis en file d’attente par le thème.

Pour les thèmes de bloc, les styles globaux définis dans theme.json et les métadonnées de bloc permettent à WordPress de générer automatiquement des feuilles de style cohérentes.

Cela réduit le besoin de grandes feuilles de style faites à la main, en plus de centraliser la configuration du design.

Résultat final

Après le traitement des modèles, du contenu, des blocs et des styles, WordPress produit la réponse HTML finale.

Le serveur envoie alors la charge utile au navigateur. Si elle est configurée, la réponse peut être mise en cache pour de futures requêtes.

Où les thèmes de bloc déplacent-ils la charge?

Le cycle de vie des requêtes que vous venez de parcourir s’applique aux thèmes classiques et en blocs. WordPress résout encore les requêtes, sélectionne les modèles, exécute PHP et renvoie le code HTML.

Ce qui change avec les thèmes en blocs, ce n’est pas la base. C’est plutôt l’endroit où le travail se fait et quand il ne peut pas être ignoré.

Les principaux impacts des thèmes de blocs

Tout d’abord, les modèles peuvent vivre 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 du répertoire du thème.

Cela ajoute de la flexibilité, mais cela signifie aussi 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 une sortie dynamique via des requêtes personnalisées, des widgets ou des shortcodes.

Les thèmes de bloc formalisent ce modèle à travers des blocs dynamiques, tels que le bloc Boucle de requête. Lorsque la mise en cache de page complète est contournée, ces blocs exécutent PHP pendant la requête.

Troisièmement, les flux de travail des éditeurs dépendent fortement des points de terminaison REST. L’enregistrement de modèles, la mise à jour de styles globaux, l’aperçu des modifications et l’interaction avec des motifs 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 design. Lorsque vous changez vos styles ou vos structures de modèle, la coordination du cache devient plus importante afin de garantir que les visiteurs et les éditeurs voient immédiatement les sorties mises à jour.

Aucun de ces changements ne nécessite un type d’hébergement différent. Ils rendent toutefois certaines faiblesses d’infrastructure plus visibles, en particulier dans les scénarios sans cache et connectés.

Dans cet esprit, la prochaine étape consiste donc à examiner ce qu’un environnement d’hébergement bien configuré doit gérer dans une configuration basée sur des blocs.

Considérations relatives à l’hébergement pour les sites basés sur des thèmes de blocs

Les thèmes de bloc n’introduisent pas de nouvelles exigences d’hébergement. Ils rendent toutefois plus important le fait de corriger les thèmes existants.

Un environnement bien configuré doit prendre en compte les chemins mis en cache et non mis en cache. C’est particulièrement important pour les éditeurs et les utilisateurs connectés.

Mise en cache coordonnée entre les couches

La mise en cache pleine page reste la couche de performance la plus efficace pour le trafic anonyme. Les pages publiques doivent être mises en cache de manière agressive, tandis que les aperçus, les sessions connectées et les points de terminaison spécifiques sont automatiquement ignorés.

La mise en cache des objets joue également un rôle important. En stockant des résultats de requêtes répétés et des structures de données calculées en mémoire, un cache d’objet réduit la charge de la base de données et améliore à la fois la réactivité du frontend et du backend.

L’invalidation du cache doit toutefois ê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 présentations obsolètes, des styles incohérents ou un comportement d’aperçu déroutant.

Un CDN complète cette configuration en mettant en cache des ressources statiques telles que des images, des polices et des scripts à proximité des visiteurs.

La mise en cache ne concerne pas une seule couche, mais la façon 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 PHP pour résoudre les requêtes, rendre 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 simultanéité attendue sans accumulation de files d’attente. Les limites de mémoire doivent être configurées pour éviter tout échange sous charge.

Le cache doit être activé et correctement dimensionné afin que le bytecode PHP n’ait pas besoin d’être recompilé à plusieurs reprises. Lors des déploiements, le cache 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 performance plus visibles lorsque le rendu est dynamique.

Mise en cache de la base de données et des objets

Les modèles de bloc personnalisés dans l’éditeur de site sont stockés dans la base de données. Le contenu du bloc inclut des métadonnées structurées que WordPress analyse avant de les afficher.

Bien que ce traitement soit efficace, il dépend toujours de la réactivité de la base de données lorsque la mise en cache est contournée.

Un cache d’objet persistant réduit les requêtes répétées et aide à stabiliser les performances pour les visiteurs du front-end et les éditeurs travaillant dans le tableau de bord.

Observabilité et suivi

À mesure que l’activité augmente dans les chemins d’exécution, la visibilité devient plus importante. Les hôtes et les propriétaires de sites doivent surveiller :

• Rapports de réussite du cache
• Utilisation du worker PHP et longueur de la file d’attente
• Performance des requêtes de base de données
• Temps de réponse de l’API REST
• Délai avant le premier octet pour les requêtes mises en cache et non mises en cache

Les thèmes de bloc ne nécessitent pas d’infrastructure spécialisée. Ils facilitent la visibilité lorsque l’infrastructure est faiblement configurée.

Utiliser WordPress de la manière dont il fonctionne aujourd’hui

Les thèmes de bloc ne changent pas ce dont WordPress a besoin pour l’hébergement. Ils le rendent plus clair lorsque ces besoins ne sont pas satisfaits.

Lorsque les modèles sont présents dans la base de données, que les blocs dynamiques sont rendus à 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 il prend en charge le flux de travail en douceur, soit il se met en travers.

C’est là que l’hébergement optimisé pour WordPress fait la différence.

Chez Ex2, l’ensemble de la pile est conçu spécifiquement 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 ajustées et à la livraison CDN globale sur une infrastructure cloud puissante.

L’objectif est de s’assurer que les visiteurs et les éditeurs bénéficient de performances constantes, même lorsque le rendu est dynamique.

WordPress basé sur des blocs n’est pas plus lourd. Il est plus transparent. Et lorsque la base est solide, cette transparence joue en votre faveur.

Pour conclure sur l’impact des thèmes de blocs sur l’hébergement WordPress

Les thèmes de blocs WordPress vous offrent une foule de nouvelles possibilités 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.

Les besoins des sites WordPress ont ainsi augmenté au cours des dernières années. Vous devez désormais, plus que jamais, vous assurer de choisir un hébergement performant et bien optimisé. Il vous faut choisir une infrastructure adaptée, si vous voulez atteindre vos objectifs.

Nous espérons que cet article vous a plu et vous a éclairé sur la façon dont les thèmes de blocs impactent WordPress. Si c’est le cas, nous vous invitons à consulter nos autres articles et tutoriels.

Notre base de connaissance contient aussi sans doute des réponses à toutes vos questions en liens avec vos projets web