# should_load_separate_core_block_assets : alléger le CSS chargé par page

> Un site qui n'utilise que quatre blocs natifs charge malgré tout le CSS de la centaine de blocs du cœur sur chaque page. Un filtre inverse ce comportement, bloc par bloc réellement utilisé.

- Auteur : WordPress Développement
- Publié le : 2022-04-30
- Mis à jour le : 2022-04-30
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/should-load-separate-core-block-assets-alleger-css/

## L’essentiel

- Active un chargement du CSS bloc par bloc, uniquement si présent
- Réduit le poids CSS transféré sur les pages sobres en blocs
- Peut augmenter le nombre de requêtes sur des pages très riches en blocs

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

> L'essentiel à retenir : Active un chargement du CSS bloc par bloc, uniquement si présent ; Réduit le poids CSS transféré sur les pages sobres en blocs ; Peut augmenter le nombre de requêtes sur des pages très riches en blocs

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é `style` distincte dans `block.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.