Quels blocs, parmi la trentaine enregistrés sur un site, exécutent réellement du PHP à chaque chargement de page, plutôt que de se contenter de restituer un fragment HTML statique stocké en base ? Cette question se pose systématiquement avant de brancher un cache de page complet : un bloc dynamique mal identifié peut afficher un contenu périmé pendant des heures si le cache ne sait pas l’exclure ou l’invalider correctement.
La fonction native get_dynamic_block_names() répond directement à cette question, sans avoir à parcourir manuellement chaque fichier block.json du site pour vérifier la présence d’un render_callback.
Ce que retourne exactement la fonction
get_dynamic_block_names() interroge le registre global des blocs (WP_Block_Type_Registry) et retourne un tableau simple contenant uniquement les noms des blocs dont la propriété render_callback est définie, qu’ils soient déclarés via block.json ou directement en PHP :
$blocs_dynamiques = get_dynamic_block_names();
print_r( $blocs_dynamiques );
// [
// 'core/latest-posts',
// 'core/calendar',
// 'core/rss',
// 'mon-extension/avis-clients',
// ]
Un bloc statique, dont le rendu est entièrement figé dans le contenu de l’article (comme core/paragraph ou core/image sans réglage particulier), n’apparaît jamais dans cette liste : son HTML est déjà présent dans post_content, sans exécution PHP supplémentaire au moment de l’affichage.
Un audit rapide avant migration de cache
Avant de mettre en place un cache de page complet (via un plugin de cache ou une configuration serveur), un audit simple consiste à croiser cette liste avec les blocs réellement utilisés sur le site :
function auditer_blocs_dynamiques_utilises() {
$blocs_dynamiques = get_dynamic_block_names();
$articles = get_posts( [ 'numberposts' => -1, 'post_type' => 'any' ] );
$rapport = [];
foreach ( $articles as $article ) {
foreach ( $blocs_dynamiques as $nom ) {
if ( has_block( $nom, $article ) ) {
$rapport[ $nom ][] = $article->ID;
}
}
}
return $rapport;
}
Ce rapport permet de savoir précisément quelles pages contiennent un bloc dynamique, avant de décider d’une durée de cache adaptée, ou d’une exclusion ciblée pour les pages concernées.
Ce que la fonction ne dit pas
- Elle ne mesure aucun temps d’exécution : un bloc dynamique peut être trivial (afficher la date du jour) ou coûteux (une requête SQL complexe sur plusieurs tables).
- Elle ne distingue pas les blocs dynamiques natifs de WordPress des blocs dynamiques ajoutés par des extensions tierces.
- Elle ne reflète que les blocs enregistrés au moment de son appel : un bloc enregistré plus tard dans le cycle de chargement (via un hook tardif) peut ne pas encore figurer dans le registre.
Compléter l’audit avec une mesure réelle
Une fois la liste des blocs dynamiques obtenue, l’étape suivante consiste à mesurer le temps réellement passé dans chaque render_callback, par exemple avec un chronométrage simple autour de l’appel :
add_filter( 'render_block', function( $contenu, $bloc ) {
static $chronos = [];
if ( in_array( $bloc['blockName'], get_dynamic_block_names(), true ) ) {
// horodatage avant/après pour un diagnostic ponctuel, à retirer en production
}
return $contenu;
}, 10, 2 );
Ce genre de mesure, réalisée temporairement sur un environnement de préproduction, complète l’audit purement structurel fourni par get_dynamic_block_names().
Un usage annexe : documenter un site avant transmission
Au-delà de la performance, cette fonction sert aussi à documenter un site avant de le transmettre à une autre équipe : la liste des blocs dynamiques donne une vue rapide des points d’attention à surveiller lors d’une montée de version de WordPress, puisque ce sont ces blocs qui dépendent le plus étroitement du code PHP du thème ou des extensions.
Sur nos audits avant migration de cache, cette fonction fait partie des trois premières commandes exécutées via WP-CLI, avant même de regarder la configuration du serveur.
En résumé
get_dynamic_block_names() offre un point de départ fiable pour tout audit lié à la performance ou au cache d’un site construit avec l’éditeur de blocs. Elle ne remplace pas une mesure réelle du temps d’exécution, mais elle évite de partir à l’aveugle en identifiant d’emblée les blocs qui méritent une attention particulière.
