# Contenu Gutenberg en headless : récupérer le CSS des blocs côté front > Le HTML renvoyé par l'API REST contient les classes des blocs Gutenberg, mais pas leurs styles. Voici comment charger le bon CSS côté front. - Auteur : Clément Hadrot - Publié le : 2020-07-02 - Mis à jour le : 2020-07-02 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/contenu-gutenberg-headless-css-blocs-front/ ## L’essentiel - Le contenu brut inclut des classes attendant un CSS externe - Deux sources de styles à récupérer : blocs core et thème - Charger uniquement le CSS nécessaire, pas tout wp-block-library Un contenu Gutenberg récupéré depuis `/wp-json/wp/v2/posts` ressemble, une fois affiché brut dans un front React, à une suite de paragraphes sans mise en forme : les colonnes ne s'alignent pas, les citations n'ont pas de bordure, les boutons ressemblent à des liens ordinaires. La raison est simple : le champ `content.rendered` contient du HTML avec des classes comme `wp-block-columns` ou `wp-block-quote`, mais aucun style associé. Ces classes attendent une feuille de styles que WordPress charge normalement lui-même côté thème classique, absente d'un front découplé. Ce n'est pas un mapping bloc par composant (ce sujet mérite son propre article) : ici, il s'agit uniquement de faire en sorte que le HTML brut, affiché tel quel, ressemble à ce que l'éditeur montre. C'est souvent la première étape, la plus rapide, avant d'envisager une conversion en composants. ## Deux sources de CSS à identifier Le rendu visuel d'un contenu Gutenberg dépend de deux feuilles de styles distinctes, chargées séparément dans un thème WordPress classique : - **wp-block-library** : le CSS des blocs natifs (paragraphe, colonnes, citation, bouton, galerie…), fourni par le cœur WordPress lui-même, dans `wp-includes/css/dist/block-library/style.min.css`. - **Le CSS du thème** : les surcharges spécifiques au thème actif, qui personnalisent l'apparence des blocs (couleurs, typographie, espacements propres à l'identité visuelle du site). ## Récupérer le CSS des blocs natifs Le fichier `style.min.css` de `wp-block-library` est un fichier statique, accessible directement par son URL publique. Sur une installation WordPress 5.4, il se trouve à un chemin prévisible : ``` https://exemple.fr/wp-includes/css/dist/block-library/style.min.css ``` Le plus simple, côté front, consiste à charger cette feuille de styles globalement dans le layout de l'application, une seule fois : ``` ``` Sur un projet Gatsby que j'ai mené en 2020, j'ai préféré télécharger ce fichier au moment du build plutôt que de dépendre d'une requête externe à chaque chargement de page, pour éviter une dépendance réseau supplémentaire en production. ## Récupérer le CSS du thème actif > L'essentiel à retenir : Le contenu brut inclut des classes attendant un CSS externe ; Deux sources de styles à récupérer : blocs core et thème ; Charger uniquement le CSS nécessaire, pas tout wp-block-library Le CSS spécifique au thème est plus difficile à isoler, car il est généralement mélangé au reste des styles du thème (menu, en-tête, pied de page) dans un fichier `style.css` unique. Deux stratégies pratiques : ### Isoler les styles de blocs dans un fichier dédié Si vous maîtrisez le thème WordPress source, la solution la plus propre consiste à extraire les règles concernant les blocs dans un fichier séparé, par exemple `blocks.css`, chargé indépendamment du reste du thème : ``` wp_enqueue_style( 'monsite-blocks-front', get_template_directory_uri() . '/assets/blocks.css', array(), wp_get_theme()->get( 'Version' ) ); ``` Ce fichier peut ensuite être exposé publiquement (il n'a rien de sensible) et chargé côté front, exactement comme `wp-block-library`. ### Réutiliser theme.json si disponible Sur les projets encore sous WordPress 5.4-5.7, `theme.json` n'existe pas encore (il arrive avec WordPress 5.8). En attendant, les couleurs et typographies personnalisées passent le plus souvent par `add_theme_support( 'editor-color-palette', … )`, dont les valeurs peuvent être récupérées côté front via une route REST personnalisée, pour reconstruire une palette CSS cohérente sans dupliquer les valeurs à la main. ## Ne pas charger tout wp-block-library sans réflexion Le fichier complet de `wp-block-library` pèse plusieurs dizaines de kilo-octets, alors qu'un site n'utilise généralement qu'une poignée de blocs (paragraphe, titre, image, liste, citation). Sur un projet où la performance était critique, j'ai extrait uniquement les règles des blocs réellement utilisés, à partir du fichier source non minifié, pour réduire le poids du CSS chargé sur chaque page. | Approche | Poids CSS estimé | Effort | | --- | --- | --- | | Charger wp-block-library complet | ≈ 35 Ko minifié | Faible | | Extraire les blocs utilisés uniquement | ≈ 8-12 Ko | Moyen, à refaire si un nouveau bloc est utilisé | ## Cas particulier des galeries et colonnes Les blocs `wp-block-gallery` et `wp-block-columns` reposent sur Flexbox et CSS Grid pour leur mise en page. Sans le CSS correspondant, une galerie s'affiche comme une simple liste d'images empilées verticalement, ce qui casse visiblement la mise en page prévue par l'auteur dans l'éditeur. > Sur un front découplé, je considère le CSS des blocs comme une dépendance du contenu au même titre que les images : l'oublier ne casse rien techniquement, mais rend le rendu visuellement incohérent avec ce que l'auteur a construit dans l'éditeur. ## Pour aller plus loin Charger le CSS des blocs suffit pour un rendu fidèle rapide, mais reste une solution transitoire : elle affiche du HTML WordPress brut dans une application front, sans profiter des composants du framework utilisé. Le mapping des blocs Gutenberg vers de véritables composants React, Vue ou Svelte va plus loin, avec ses propres compromis à connaître.