WordPress 6.2, sorti fin mars 2023, marque la fin de la phase bêta de l’éditeur de site (Site Editor), avec une interface repensée et surtout un important travail de fond sur les performances du rendu des blocs. Plutôt que de reprendre les annonces officielles telles quelles, nous avons voulu vérifier par nous-mêmes ce que ces optimisations changent réellement sur deux sites de test représentatifs.
Le protocole : un site utilisant un thème classique basé sur des templates PHP (Astra en version enfant) et un site utilisant Twenty Twenty-Three, thème bloc de référence pour cette version. Chaque site a été mesuré en WordPress 6.1 puis en 6.2, sans autre changement, avec dix passages sur trois pages types (accueil, article, archive) via WebPageTest en émulation 4G.
Ce que WordPress 6.2 change réellement dans le cœur
Plusieurs chantiers techniques expliquent les gains observés. Le rendu des blocs a été optimisé pour réduire le nombre d’appels à render_block() redondants, notamment pour les blocs imbriqués comme les groupes et les colonnes. Le mécanisme de style global (theme.json) génère désormais son CSS de façon plus efficace, avec une meilleure mise en cache des règles calculées pour éviter de reconstruire l’arbre de styles à chaque requête.
Le cœur a également amélioré la mise en cache des requêtes liées aux menus de navigation, un point sensible depuis l’introduction du bloc Navigation en 5.9, qui multipliait auparavant les requêtes à la base pour résoudre chaque élément de menu.
Nos mesures sur le thème bloc Twenty Twenty-Trois
Sur le site utilisant Twenty Twenty-Trois, le temps de génération serveur (Time to First Byte, sans cache de page) est passé d’une moyenne de 312 ms en 6.1 à 256 ms en 6.2, soit une réduction de 18 %. La page d’archive, plus riche en blocs imbriqués, a montré le gain le plus net, cohérent avec les optimisations annoncées sur le rendu des blocs de requête.
| Page | TTFB WordPress 6.1 | TTFB WordPress 6.2 | Gain |
|---|---|---|---|
| Accueil | 298 ms | 251 ms | 16 % |
| Article | 287 ms | 241 ms | 16 % |
| Archive (bloc Requête) | 352 ms | 276 ms | 22 % |
Nos mesures sur le thème classique
Sur le site en thème classique, les gains ont été nettement plus modestes : entre 3 et 6 % de réduction du TTFB selon les pages. C’est logique, puisque la majorité des optimisations de 6.2 ciblent le pipeline de rendu des blocs, peu sollicité par un thème qui génère l’essentiel de sa sortie via des templates PHP traditionnels et peu de contenu en blocs Gutenberg.
Ce constat rejoint une intuition qu’on avait déjà : les sites qui adoptent pleinement l’éditeur de site et les blocs natifs profitent proportionnellement plus des efforts de performance du cœur que les sites qui continuent à fonctionner en thème classique avec seulement quelques blocs dans le contenu éditorial.
Points de vigilance avant de migrer
- Vérifier la compatibilité des extensions qui manipulent le rendu des blocs via des filtres bas niveau, certaines ayant dû être mises à jour pour 6.2.
- Purger intégralement le cache de style global après la mise à jour, certains hébergeurs conservant un CSS généré par l’ancienne version.
- Refaire un tour complet de l’éditeur de site si le thème est basé sur des blocs, l’interface ayant changé significativement par rapport à la phase bêta de 6.1.
Notre verdict
WordPress 6.2 tient ses promesses de performance, mais de façon inégale selon l’architecture du thème. Sur un site en blocs natifs, un gain à deux chiffres sur le TTFB est réaliste et vérifiable. Sur un thème classique, la mise à jour reste recommandée pour la stabilité et la sécurité, mais il ne faut pas en attendre un effet mesurable sur les temps de réponse. La bascule progressive vers des thèmes bloc reste, de notre point de vue, le principal levier de performance à moyen terme pour qui veut profiter pleinement des efforts du cœur.
