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.cssLe plus simple, côté front, consiste à charger cette feuille de styles globalement dans le layout de l’application, une seule fois :
<link
rel="stylesheet"
href="https://exemple.fr/wp-includes/css/dist/block-library/style.min.css"
/>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
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.
