wp block list --allow-root | wc -l retournait 214 sur ce projet avant la migration, un chiffre qui donne la mesure du registre de blocs accumulé par cette agence sur plusieurs années de projets clients successifs. Chacun de ces 214 blocs appelait individuellement register_block_type() au chargement de chaque site, un coût cumulé devenu mesurable à l’ouverture de l’éditeur.
Ce retour d’expérience porte sur la migration de ce registre vers wp_register_block_metadata_collection(), introduite en 2024. Il ne couvre pas la création de nouveaux blocs ni la migration des attributs existants, qui restent strictement identiques avant et après cette migration.
Le diagnostic de départ
Avant migration, chaque bloc du registre déclarait son enregistrement individuellement, dans son propre fichier PHP, via un appel classique à register_block_type( __DIR__ ) lisant son block.json à chaque requête. Sur 214 blocs, cela représente 214 lectures de fichier et 214 décodages JSON à chaque chargement de l’éditeur, même quand la majorité des blocs n’est utilisée sur aucune page de la session en cours.
Ce qu’apporte la collection de métadonnées
La fonction wp_register_block_metadata_collection() permet de déclarer, en un seul appel, l’ensemble des métadonnées de blocs présentes dans un dossier, à partir d’un manifeste PHP unique généré à l’avance plutôt que lu dynamiquement à chaque requête. WordPress lit alors ce manifeste en une seule opération, au lieu de parcourir 214 fichiers block.json individuellement.
Générer le manifeste au moment du build
Plutôt que d’écrire le manifeste à la main, un script Node exécuté lors du build du registre parcourt chaque dossier de bloc et génère le fichier manifeste-blocs.php automatiquement :
const fs = require( 'fs' );
const path = require( 'path' );
const dossierBlocs = path.join( __dirname, 'blocs' );
const manifeste = {};
fs.readdirSync( dossierBlocs ).forEach( ( nom ) => {
const cheminJson = path.join( dossierBlocs, nom, 'block.json' );
if ( fs.existsSync( cheminJson ) ) {
manifeste[ nom ] = JSON.parse( fs.readFileSync( cheminJson, 'utf8' ) );
}
} );
const contenuPhp = '<?php return ' + phpSerialiseTableau( manifeste ) + ';';
fs.writeFileSync( path.join( __dirname, 'manifeste-blocs.php' ), contenuPhp );
L’appel côté PHP, désormais unique
Le registre de blocs de l’agence n’appelle plus 214 fois register_block_type(), mais une seule fois wp_register_block_metadata_collection(), pointant vers le dossier des blocs et le manifeste généré :
function agence_enregistrer_registre_blocs() {
wp_register_block_metadata_collection(
__DIR__ . '/blocs',
__DIR__ . '/manifeste-blocs.php'
);
$dossiers = glob( __DIR__ . '/blocs/*', GLOB_ONLYDIR );
foreach ( $dossiers as $dossier ) {
register_block_type( $dossier );
}
}
add_action( 'init', 'agence_enregistrer_registre_blocs' );
Le second appel à register_block_type() reste nécessaire pour chaque bloc, mais lit désormais ses métadonnées depuis le manifeste déjà chargé en mémoire, sans nouvelle lecture de fichier ni nouveau décodage JSON individuel.
Le gain mesuré
| Mesure | Avant migration | Après migration |
|---|---|---|
| Temps d’initialisation de l’éditeur | 1 320 ms | 680 ms |
| Lectures de fichier au chargement | 214 | 1 |
Ce qui a demandé le plus d’attention
Le point de vigilance principal n’était pas la migration elle-même, mécanique une fois le script de génération écrit, mais la synchronisation du manifeste avec chaque évolution ultérieure des blocs. Un développeur qui modifie un block.json sans relancer le script de build laisse le manifeste désynchronisé, ce qui a été résolu en intégrant la génération du manifeste directement dans la chaîne de build existante, plutôt que comme une étape manuelle séparée.
- Génération du manifeste intégrée au script de build existant, jamais en étape manuelle séparée.
- Aucun changement d’attribut ni de rendu sur les 214 blocs, migration strictement structurelle.
- Vérification post-migration par un script parcourant chaque page de test et comparant le rendu avant/après.
Un registre de blocs qui grossit sans jamais revisiter sa méthode d’enregistrement finit toujours par payer, en temps de chargement, la facture de sa propre croissance.
En résumé
Migrer un registre de 214 blocs vers wp_register_block_metadata_collection() a réduit de moitié le temps d’initialisation de l’éditeur, sans toucher au comportement des blocs eux-mêmes. Le coût de la migration tient essentiellement dans l’écriture du script de génération du manifeste, à intégrer une fois pour toutes dans la chaîne de build existante de l’agence.
