[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é
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.jsonet 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.
