Une centaine : c’est approximativement le nombre de blocs natifs enregistrés par le cœur de WordPress, chacun avec son propre fragment de feuille de style. Par défaut, l’ensemble de ces styles est concaténé dans un unique fichier CSS chargé sur toutes les pages du site, qu’elles utilisent quatre blocs ou quarante. Sur un site éditorial sobre, qui n’emploie que des paragraphes, des titres, des images et des listes, ce comportement gonfle inutilement le poids transféré à chaque visiteur.
Le filtre should_load_separate_core_block_assets, introduit avec WordPress 5.8, inverse cette logique : il permet de ne charger que le CSS des blocs réellement présents sur la page affichée, chacun dans son propre fichier séparé.
Activer le chargement séparé
L’activation tient en une seule ligne, à placer dans le fichier functions.php du thème ou dans une extension dédiée aux réglages de performance :
add_filter( 'should_load_separate_core_block_assets', '__return_true' );
Une fois ce filtre actif, WordPress charge, pour chaque page affichée, uniquement les fichiers CSS correspondant aux blocs effectivement présents dans le contenu analysé, plutôt que le fichier global regroupant l’ensemble des blocs du cœur.
Ce que cela change concrètement côté réseau
Sur une page qui n’utilise que des paragraphes, des titres et une image, seuls trois petits fichiers CSS sont désormais chargés, plutôt qu’un fichier unique regroupant le style de la centaine de blocs natifs, y compris ceux jamais utilisés sur le site (calendrier, flux RSS, navigation de commentaires, etc.). Le gain de poids transféré peut être significatif sur un site dont les pages restent volontairement sobres en blocs.
Le revers de la médaille : plus de requêtes
Ce chargement séparé a un coût : chaque bloc utilisé génère sa propre requête CSS. Sur une page qui combine quinze blocs natifs différents, on multiplie donc le nombre de requêtes HTTP par rapport au fichier unique par défaut. Sur HTTP/2 ou HTTP/3, où le coût d’une requête supplémentaire reste faible grâce au multiplexage, cet inconvénient pèse peu. Sur un hébergement encore limité à HTTP/1.1, le compromis mérite d’être mesuré avant activation généralisée.
Mesurer avant de généraliser
// comparaison simple avant/après, via les outils de développement du navigateur
// onglet réseau, filtré sur les fichiers CSS, poids total transféré
Une mesure rapide consiste à comparer le poids total des fichiers CSS liés aux blocs, avec et sans le filtre actif, sur les deux ou trois gabarits de page les plus représentatifs du trafic réel du site (page d’accueil, article type, page de catégorie). Le gain n’est pas homogène : une page qui utilise énormément de blocs natifs différents profite moins de cette optimisation qu’une page qui n’en utilise que quelques-uns.
Vérifier la compatibilité avec le thème actif
- Un thème qui charge sa propre feuille de style globale surchargeant certains styles de blocs natifs doit être testé après activation, pour vérifier qu’aucune règle CSS attendue ne disparaît.
- Certains blocs personnalisés, mal déclarés sans clé
styledistincte dansblock.json, ne bénéficient pas de ce chargement séparé et continuent de charger leur CSS de façon globale. - Un cache de page complet (Varnish, cache serveur) doit être vidé après activation, pour éviter de servir un mélange d’anciennes et de nouvelles versions des fichiers CSS.
Un cas où l’inverse est préférable
Sur un site qui affiche systématiquement une grande variété de blocs natifs sur chacune de ses pages (un magazine qui combine galerie, citation, tableau, calendrier d’articles), le fichier CSS unique reste parfois plus performant : une seule requête, mise en cache une fois pour toutes les pages du site, peut se révéler plus efficace que de multiplier les petites requêtes séparées sur chaque page.
Sur nos audits de performance, ce filtre fait partie des premiers réglages testés sur un site éditorial classique, avant d’envisager des optimisations plus lourdes comme un cache de page complet.
En résumé
should_load_separate_core_block_assets n’est pas une optimisation universelle : elle profite nettement aux sites sobres en diversité de blocs, et beaucoup moins aux sites qui combinent systématiquement une grande variété de blocs natifs. Une mesure rapide sur les gabarits représentatifs du trafic réel du site permet de trancher, plutôt que d’activer ce filtre par principe.
