340 millisecondes : c’est l’écart de temps de rendu serveur mesuré, cache désactivé, entre un thème classique optimisé et un thème bloc construit avec la même exigence, sur la page d’accueil d’un site à fort trafic reproduisant exactement le même jeu de contenus. Ce chiffre seul ne dit pas grand-chose sans le protocole qui l’entoure — et c’est justement l’objet de ce comparatif.
L’expérience a consisté à répliquer le même site — cent articles, huit catégories, une page d’accueil avec quinze blocs de contenu variés — sur deux architectures de thème distinctes : un thème classique basé sur des fichiers PHP avec get_template_part(), et un thème bloc entièrement construit avec theme.json et des templates .html. Ce comparatif ne traite pas la migration progressive de l’un vers l’autre, ni les architectures hybrides, abordées séparément.
Protocole de mesure
Les deux thèmes ont été installés sur la même instance serveur, avec la même configuration PHP 8.1, la même base de données MySQL peuplée à l’identique, et sans extension de cache de page active, afin d’isoler la performance de rendu propre à chaque architecture. Les mesures ont été prises avec curl -o /dev/null -s -w "%{time_total}" répété cinquante fois par page, moyenne et écart-type calculés ensuite.
| Métrique | Thème classique | Thème bloc |
|---|---|---|
| Temps de rendu serveur (accueil, moyenne) | 410 ms | 750 ms |
| Requêtes SQL par page (accueil) | 34 | 41 |
| Poids HTML généré | 68 Ko | 92 Ko |
| Poids CSS chargé (non minifié) | 44 Ko | 61 Ko |
| Temps de rendu page d’article | 280 ms | 340 ms |
Pourquoi le thème bloc rend plus lentement côté serveur
L’écart sur la page d’accueil s’explique principalement par le mécanisme de résolution des templates et le calcul des styles à la volée. Chaque bloc natif de l’éditeur passe par une couche de rendu supplémentaire — le moteur de style (« style engine ») qui génère le CSS spécifique à chaque instance de bloc à partir de ses attributs — quand un thème classique se contente d’inclure directement un fragment PHP statique via get_template_part( 'template-parts/bloc-accueil' ).
Ce coût n’est pas fixe : il croît avec le nombre de blocs imbriqués sur la page. Sur une page d’article simple, contenant peu de blocs, l’écart se réduit nettement (280 ms contre 340 ms), tandis qu’il se creuse sur une page d’accueil riche en motifs (« patterns ») imbriqués les uns dans les autres.
Le rôle décisif du cache, absent de ce protocole
Ce comparatif mesure volontairement le pire cas : aucun cache de page actif. En production, la quasi-totalité des sites à fort trafic servent leurs pages depuis un cache de page complet, ce qui ramène le temps de rendu serveur à quelques millisecondes pour les deux architectures, l’écart mesuré ci-dessus devenant alors non pertinent pour l’utilisateur final. Il reste pertinent uniquement pour les pages qui échappent structurellement au cache : panier, compte utilisateur, résultats de recherche personnalisés.
Ce que le poids CSS révèle sur la stratégie de chargement
L’écart de poids CSS (44 Ko contre 61 Ko) tient moins à l’architecture elle-même qu’à la configuration du chargement conditionnel par bloc. WordPress permet, depuis l’introduction du chargement CSS par bloc, de ne charger que le style des blocs réellement présents sur la page via wp_enqueue_block_style(). Sur ce test, le thème bloc chargeait encore un fichier de styles globaux englobant, en plus des styles conditionnels — une configuration perfectible qui explique une partie de l’écart, davantage qu’une limite intrinsèque de l’architecture bloc.
Ce qu’un audit plus poussé changerait probablement
En resserrant le chargement CSS conditionnel et en réduisant la profondeur d’imbrication des motifs de la page d’accueil, l’écart de poids CSS se réduirait sans doute significativement, sans toucher à l’architecture de fond. Ce point illustre une limite du comparatif brut de chiffres : il capture un instantané d’implémentation, pas une propriété physique immuable de chaque architecture.
Verdict argumenté
Sur ce jeu de mesures, le thème classique conserve un avantage net en rendu serveur brut, cache désactivé. Mais ce résultat ne doit pas être lu comme un argument définitif contre les thèmes blocs : sur un site à fort trafic correctement mis en cache — ce qui est la norme, pas l’exception, pour ce type de projet — l’écart mesuré ici s’efface presque entièrement derrière le temps de service du cache. Le critère de choix pertinent devient alors la vélocité éditoriale et la maintenabilité à long terme, pas la performance brute de rendu.
Un benchmark cache désactivé mesure une réalité de laboratoire ; le choix d’architecture d’un site à fort trafic se juge davantage sur son comportement en cache actif et sur sa maintenabilité dans le temps.
En résumé
Le thème classique rend plus vite côté serveur sur ce comparatif, avec un écart qui se creuse sur les pages riches en blocs imbriqués. Ce résultat mérite d’être relativisé par le rôle du cache en production et par la qualité d’implémentation du chargement CSS conditionnel, deux facteurs qui pèsent souvent davantage que le choix d’architecture lui-même sur l’expérience réelle des visiteurs.
