Depuis 2022 et WordPress 5.9, il existe deux manières très différentes de construire un thème. Les thèmes classiques, ceux que WordPress utilise depuis vingt ans, sont des ensembles de fichiers PHP, comme header.php, single.php et footer.php, accompagnés de feuilles de style et de scripts. Les thèmes de blocs, eux, décrivent toute la structure du site, y compris l’en-tête, le pied de page et les modèles de pages, avec les mêmes blocs que ceux du contenu, dans des fichiers HTML, et configurent les couleurs, les polices et les espacements dans un fichier theme.json. C’est le modèle sur lequel repose l’éditeur de site, et celui sur lequel WordPress concentre son développement.
Le choix entre les deux modèles se discute généralement en termes de flexibilité, d’autonomie des rédacteurs et de compatibilité des plugins. Mais il a aussi des conséquences concrètes sur la performance : sur la quantité de CSS et de JavaScript qui arrive au navigateur, sur la manière dont ils sont chargés, sur le poids de la page. Dans cet article, nous regardons ce qui change vraiment, là où les thèmes de blocs ont un avantage structurel, là où ils peuvent au contraire alourdir la page, et comment évaluer un thème quel que soit son modèle.
Comment les styles des blocs sont chargés
La différence la plus importante concerne le CSS des blocs. WordPress inclut des dizaines de blocs, du paragraphe à la galerie, du tableau au calendrier, chacun avec ses propres styles. Pendant longtemps, tous ces styles étaient chargés dans une seule feuille de style, wp-block-library, sur chaque page, quels que soient les blocs réellement utilisés : une page avec seulement des paragraphes et des titres téléchargeait aussi les styles des galeries, des tableaux et des lecteurs audio.
Depuis la version 5.8, WordPress peut charger séparément les styles de chaque bloc, et uniquement pour les blocs présents sur la page. Dans les thèmes de blocs, ce comportement est activé par défaut, car WordPress connaît à l’avance tous les blocs qui composent la page, y compris ceux des modèles. Les styles des plus petits blocs sont en outre intégrés directement dans le HTML, jusqu’à un seuil de taille totale, ce qui évite des requêtes supplémentaires.
Les thèmes classiques peuvent eux aussi activer le chargement séparé avec le filtre should_load_separate_core_block_assets, mais avec une limite : comme l’en-tête et le pied de page sont générés par PHP, WordPress ne découvre les blocs qu’au fur et à mesure qu’il les rencontre, et certains styles peuvent se retrouver en bas du document. C’est pourquoi l’option est désactivée par défaut dans les thèmes classiques et doit être activée avec précaution, en vérifiant qu’aucun décalage de mise en page n’apparaît.
// Dans un thème classique : ne charger que les styles des blocs utilisés
add_filter( 'should_load_separate_core_block_assets', '__return_true' );
// Seuil pour intégrer les petits styles dans le HTML (octets)
add_filter(
'styles_inline_size_limit',
function () {
return 30000;
}
);theme.json et styles globaux
Dans les thèmes de blocs, les couleurs, les polices, les tailles de texte, les espacements et les styles de chaque bloc sont définis dans theme.json. WordPress les transforme en une feuille de style globale, générée automatiquement et insérée dans la page, qui définit un ensemble de propriétés personnalisées CSS et les règles qui les appliquent. C’est une approche ordonnée : les valeurs sont centralisées, le CSS généré est cohérent, et l’éditeur peut les modifier depuis l’éditeur de site sans toucher au code.
Elle a néanmoins un coût à surveiller. Chaque couleur de palette, chaque taille de texte, chaque dégradé et chaque espacement par défaut génère des propriétés personnalisées et des classes utilitaires, et la feuille de style globale peut atteindre plusieurs dizaines de kilo-octets, insérés dans chaque page. Les thèmes qui définissent de très grandes palettes, ou qui gardent actives les palettes par défaut de WordPress en plus des leurs, produisent un CSS global disproportionné. La solution est simple : désactiver les préréglages par défaut que vous n’utilisez pas et limiter les vôtres à ceux qui sont vraiment nécessaires.
{
"version": 3,
"settings": {
"color": {
"defaultPalette": false,
"defaultGradients": false,
"defaultDuotone": false
},
"typography": {
"defaultFontSizes": false,
"fluid": true
},
"spacing": {
"defaultSpacingSizes": false
}
}
}La typographie fluide, qui peut être activée dans theme.json, est un avantage indirect : les tailles de texte s’adaptent à la largeur de l’écran grâce à la fonction CSS clamp(), ce qui élimine de nombreuses règles propres à chaque appareil. Les polices aussi peuvent être déclarées dans theme.json et hébergées dans le thème, avec les règles @font-face générées automatiquement : une bonne base pour le travail de sous-ensemble et d’optimisation des polices.
JavaScript : moins que vous ne le pensez
Un thème de blocs bien conçu charge très peu de JavaScript côté public. Les modèles sont générés sur le serveur, les blocs du cœur produisent du HTML et du CSS, et le JavaScript n’arrive que pour les blocs qui en ont besoin, comme la navigation avec son menu mobile ou la recherche. Depuis la version 6.5, les blocs interactifs du cœur utilisent l’Interactivity API, un petit système fondé sur les modules JavaScript natifs, qui n’est chargé que si la page contient au moins un bloc qui l’exige.
Les thèmes classiques, à l’inverse, incluent souvent jQuery et une série de scripts qui leur sont propres, chargés sur chaque page : curseurs, animations, menus, lightboxes, souvent même lorsque la page ne les utilise pas. Ce n’est pas une caractéristique intrinsèque du modèle classique, mais une habitude répandue, héritée d’une époque où jQuery était la norme. Le résultat, dans la comparaison typique entre un thème classique riche en fonctionnalités et un thème de blocs minimaliste, est une différence de poids considérable.
Là où les thèmes de blocs peuvent alourdir la page
Ce serait une erreur de conclure qu’un thème de blocs est automatiquement rapide. Certaines caractéristiques du modèle peuvent produire des pages plus lourdes que nécessaire.
- Groupes imbriqués. Construire des mises en page complexes dans l’éditeur de site conduit facilement à des groupes dans des groupes, des colonnes dans des colonnes, chacun avec ses propres conteneurs : le même problème que les constructeurs de pages, sous une forme plus contenue, traité dans l’article sur le coût du DOM.
- Styles générés pour chaque élément. Lorsque le rédacteur personnalise les marges, les couleurs ou la mise en page d’un seul bloc, WordPress génère des classes et des règles propres à cette instance, insérées dans la page. De nombreuses personnalisations ponctuelles produisent beaucoup de CSS qui ne peut pas être réutilisé.
- Styles globaux volumineux. Comme on l’a vu plus haut, de nombreuses palettes et de nombreux préréglages gonflent le CSS inséré dans chaque page.
- Plugins de blocs. Les collections de blocs complémentaires chargent souvent leurs propres feuilles de style et scripts pour tous les blocs de la collection, sur toutes les pages, ce qui annule l’intérêt du chargement sélectif du cœur.
- Motifs lourds. Les motifs prêts à l’emploi, des sections préconçues à insérer en un clic, peuvent contenir de grandes images, des animations et des structures profondes qui se retrouvent dans la page sans que personne ne les réévalue.
Bonnes pratiques pour ceux qui travaillent dans l’éditeur de site
Avec un thème de blocs, une partie des choix qui influent sur la performance passe de la personne qui développe le thème à celle qui construit et met à jour les pages. Quelques habitudes aident à garder le site léger dans la durée. Privilégiez les styles globaux aux personnalisations bloc par bloc : si tous les boutons doivent avoir le même aspect, définissez-le une fois dans les styles du bloc Boutons, plutôt que de le répéter sur chaque instance. Utilisez des motifs synchronisés pour les sections récurrentes, au lieu de les copier et de les modifier page par page. Évitez les groupes imbriqués quand un seul groupe avec la bonne disposition suffit.
Pour les images, téléversez des fichiers de taille adaptée et laissez WordPress générer les variantes, plutôt que d’insérer d’énormes images redimensionnées par l’éditeur. Et avant d’installer une collection de blocs pour n’utiliser qu’un seul bloc, vérifiez quelles ressources elle charge et sur quelles pages : souvent, un motif construit avec les blocs du cœur obtient le même résultat sans rien ajouter.
Thèmes hybrides et thèmes classiques modernes
Entre les deux modèles, il existe un terrain intermédiaire. De nombreux thèmes classiques adoptent désormais theme.json pour gérer les couleurs, les polices et les réglages de l’éditeur, tout en gardant leurs modèles en PHP : ce sont les thèmes dits hybrides. Ils bénéficient des styles globaux et de la cohérence avec l’éditeur, et peuvent activer le chargement séparé des styles des blocs. Dans le même temps, il existe des thèmes classiques conçus avec un grand soin pour la performance, avec un CSS minimal, sans jQuery et des scripts chargés uniquement là où ils sont nécessaires, qui n’ont rien à envier à un bon thème de blocs.
Le type de thème compte donc moins que la qualité de sa construction. Le modèle de blocs offre quelques avantages structurels, comme le chargement sélectif des styles, la génération des modèles côté serveur et l’absence de dépendances historiques, qui facilitent l’obtention de bonnes performances. Mais il ne les garantit pas.
L’image LCP et les blocs du cœur
Un avantage moins évident des thèmes de blocs concerne le LCP. Les optimisations automatiques de WordPress, comme l’ajout de fetchpriority="high" à l’image principale et l’exclusion des premières images du lazy loading, fonctionnent mieux quand les images sont produites par les blocs et les fonctions du cœur : WordPress connaît la structure de la page et peut estimer avec une bonne précision quelle image sera l’élément LCP. Avec les thèmes et les constructeurs qui génèrent leur balisage d’image à leur manière, l’estimation est moins fiable et doit souvent être corrigée à la main.
Les images mises en avant, les couvertures et les images d’arrière-plan des blocs Couverture sont elles aussi gérées par le cœur avec des attributs de taille et des variantes adaptatives, ce qui réduit le risque d’images surdimensionnées et de décalages de mise en page.
Un exemple concret : ce site
Le site que vous lisez utilise un thème de blocs développé sur mesure. Les modèles de pages sont des fichiers HTML avec des blocs du cœur, les styles globaux sont définis dans theme.json avec un minimum de préréglages, les styles des blocs ne sont chargés que lorsqu’ils sont nécessaires et les feuilles de style propres à certaines sections, comme le blog, ne sont chargées que sur les pages qui les utilisent. Le JavaScript côté public est réduit au minimum, au point que même la table des matières des articles est générée sur le serveur, et les polices sont hébergées localement et réduites aux caractères nécessaires. Le résultat est une page avec peu de requêtes, un CSS contenu et aucun script bloquant le rendu, sans renoncer à un éditeur visuel pour le contenu.
Passer à un thème de blocs ?
Pour un site existant, changer de thème est un projet qui a des coûts et des risques, et la performance n’en est qu’un des facteurs. Cela vaut la peine d’y réfléchir quand le thème actuel est daté, lourd et difficile à optimiser, quand une refonte visuelle est de toute façon prévue, ou quand le site est déjà construit en grande partie avec des blocs dans le contenu. Dans bien d’autres cas, travailler sur le thème existant, par exemple activer le chargement séparé des styles, supprimer jQuery et les scripts inutiles et adopter theme.json, apporte l’essentiel des bénéfices pour un coût bien moindre.
Pour un nouveau site, en revanche, un thème de blocs minimaliste est aujourd’hui un excellent point de départ : aligné sur la direction que prend WordPress, léger par construction et avec moins de dépendances à gérer dans le temps.
Comment évaluer un thème
Quel que soit le modèle, quelques vérifications rapides en disent long sur la qualité d’un thème du point de vue de la performance. Sur une page d’exemple avec un contenu réaliste, dans le panneau Réseau des DevTools : combien de feuilles de style et de scripts sont chargés, combien ils pèsent, si jQuery est présent, s’il y a dans le head des scripts qui bloquent le rendu. Dans la console : le nombre d’éléments de la page avec document.querySelectorAll('*').length. Dans PageSpeed Insights : l’élément LCP, la présence de CSS et de JavaScript inutilisés, les avertissements sur la taille du DOM.
La comparaison doit toujours se faire avec le même contenu et sans plugins supplémentaires, pour isoler l’apport du thème. Et elle doit être refaite après avoir ajouté les plugins que le site utilisera réellement : un thème léger ne suffit pas si chaque plugin ajoute ses propres styles et scripts à toutes les pages.
En résumé
Les thèmes de blocs présentent quelques avantages structurels pour la performance : ils ne chargent que les styles des blocs présents, génèrent les modèles sur le serveur, utilisent très peu de JavaScript et s’intègrent mieux aux optimisations d’images automatiques de WordPress. Ils peuvent toutefois alourdir la page à cause de styles globaux volumineux, d’imbrications profondes, de personnalisations ponctuelles et de plugins de blocs négligés.
La qualité de construction compte plus que le modèle : un thème classique bien fait peut être plus léger qu’un thème de blocs négligé. Pour les nouveaux sites, un thème de blocs minimaliste est le choix le plus naturel ; pour les sites existants, il vaut mieux commencer par appliquer au thème actuel les bonnes pratiques du modèle de blocs, et n’envisager le changement que lorsque les bénéfices justifient le projet.
