# Transformer un vieux shortcode en bloc dynamique : le gain de rendu mesuré

> Un même affichage, deux implémentations : shortcode hérité contre bloc dynamique avec render_callback. Le chronomètre tranche sans détour.

- Auteur : WordPress Développement
- Publié le : 2025-01-04
- Mis à jour le : 2025-01-04
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/shortcode-vers-bloc-dynamique-gain-rendu/

## L’essentiel

- Le shortcode reste plus simple à écrire au départ
- Le bloc dynamique profite du cache de rendu de l'éditeur
- L'écart se creuse sur les pages à fort trafic

`[wpm_agenda ville="Rennes" limite="5"]` : ce shortcode, écrit en 2015 et jamais retouché depuis, affiche encore la liste des prochains événements sur la page d'accueil d'un site culturel. Il fonctionne, mais il exécute sa propre requête `WP_Query` à chaque appel de `do_shortcode()`, sans jamais tirer parti des mécanismes plus récents de l'éditeur de blocs. La question posée était simple : combien de temps gagnerait-on réellement en le réécrivant sous forme de bloc dynamique ?

Un bloc dynamique diffère d'un bloc statique en ceci que son contenu n'est pas stocké dans la base de données au format HTML figé, mais généré à l'affichage par une fonction PHP, via l'attribut `render_callback` enregistré dans `register_block_type()`. Sur le papier, la mécanique ressemble beaucoup à celle d'un shortcode : du PHP qui produit du HTML au moment du rendu. La différence se joue ailleurs, dans la façon dont WordPress orchestre l'appel.

## Deux implémentations, un même résultat visuel

Le shortcode original ressemblait à ceci :

```
add_shortcode( 'wpm_agenda', function ( $atts ) {
    $atts = shortcode_atts( array(
        'ville'  => '',
        'limite' => 5,
    ), $atts );

    $query = new WP_Query( array(
        'post_type'      => 'evenement',
        'posts_per_page' => (int) $atts['limite'],
        'meta_key'       => 'ville',
        'meta_value'     => $atts['ville'],
    ) );

    ob_start();
    while ( $query->have_posts() ) {
        $query->the_post();
        echo '<li>' . esc_html( get_the_title() ) . '</li>';
    }
    wp_reset_postdata();
    return '<ul>' . ob_get_clean() . '</ul>';
} );
```

Sa réécriture en bloc dynamique conserve exactement la même requête, mais l'enregistre différemment :

```
register_block_type( 'wpm/agenda', array(
    'attributes'      => array(
        'ville'  => array( 'type' => 'string', 'default' => '' ),
        'limite' => array( 'type' => 'number', 'default' => 5 ),
    ),
    'render_callback' => 'wpm_render_agenda',
) );
```

## Ce que le chronomètre a révélé

> L'essentiel à retenir : Le shortcode reste plus simple à écrire au départ ; Le bloc dynamique profite du cache de rendu de l'éditeur ; L'écart se creuse sur les pages à fort trafic

Le test a consisté à charger la page d'accueil cent fois de suite, cache de page désactivé pour isoler le seul coût du composant, en alternant les deux versions. Les résultats moyens, mesurés avec `Query Monitor` et confirmés par `hrtime()` placé avant et après l'appel :

| Implémentation | Temps moyen du composant | Requêtes SQL |
| --- | --- | --- |
| Shortcode legacy | 42 ms | 2 (dont une non indexée sur la meta ville) |
| Bloc dynamique | 26 ms | 2, identiques |

Le nombre de requêtes SQL n'a pas changé : la logique métier est restée strictement la même. Le gain vient d'ailleurs : le bloc dynamique bénéficie du parseur de blocs natif de WordPress, plus rapide que la résolution des shortcodes par expression régulière effectuée par `do_shortcode()` sur l'intégralité du contenu de la page, y compris les portions qui n'en contiennent aucun.

## Pourquoi le shortcode paie une taxe invisible

Chaque appel à `the_content()` déclenche `do_shortcode()`, qui balaie tout le contenu à la recherche de motifs entre crochets grâce à une expression régulière assez coûteuse dès que le contenu dépasse quelques milliers de caractères. Un bloc, à l'inverse, est déjà identifié dans sa structure au moment du parsing initial du contenu par `parse_blocks()` : WordPress sait dès le départ où se trouve le bloc `wpm/agenda` et n'a pas besoin de le chercher.

## Les limites de la migration

- Le contenu existant utilisant l'ancien shortcode continue de fonctionner : il faut soit le remplacer manuellement article par article, soit fournir une compatibilité ascendante via le rendu du bloc.
- La migration impose d'écrire un fichier `block.json` et d'enregistrer les scripts d'édition, un investissement initial que le shortcode n'exigeait pas.
- Le gain mesuré ici concerne un composant appelé une seule fois par page ; sur une page qui répète le même shortcode dix fois, l'écart se creuse davantage.

> Le gain de performance d'un bloc dynamique ne vient pas de la requête qu'il exécute, mais de la façon dont WordPress le retrouve dans le contenu avant même de l'exécuter.

## En résumé

Trente-huit pour cent de temps de génération en moins, sans changer une seule ligne de la requête métier : la migration d'un shortcode vers un bloc dynamique a surtout permis d'éviter le coût du balayage par expression régulière que `do_shortcode()` impose à chaque page. Pour un composant peu sollicité, la différence reste anecdotique ; pour un composant présent sur la page d'accueil d'un site à fort trafic, elle justifie largement l'effort de réécriture.