# get_dynamic_block_names() liste les blocs réellement dynamiques d’un site

> Quels blocs d'un site interrogent la base de données à chaque affichage ? Une fonction native répond en une ligne, avant de brancher une page complète derrière un cache serveur.

- Auteur : WordPress Développement
- Publié le : 2021-08-05
- Mis à jour le : 2021-08-05
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/get-dynamic-block-names-lister-blocs-dynamiques/

## L’essentiel

- Retourne uniquement les noms des blocs avec render_callback
- Utile avant de brancher un cache de page complet
- Ne dit rien du coût réel de chaque bloc, seulement de sa nature

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

> L'essentiel à retenir : Retourne uniquement les noms des blocs avec render_callback ; Utile avant de brancher un cache de page complet ; Ne dit rien du coût réel de chaque bloc, seulement de sa nature

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.