« docs, développeur, Interactivity API » — la documentation officielle publiée sur developer.wordpress.org décrit l’Interactivity API, stabilisée avec WordPress 6.5, comme un standard permettant de rendre des blocs interactifs sans dépendre d’un framework JavaScript lourd côté client. Ce que cette documentation aborde moins, c’est le coût du côté serveur : chaque directive data-wp-* doit être calculée au moment du rendu PHP, avant même que le client ne prenne le relais pour l’hydratation.
Ce billet mesure ce coût sur un thème construit autour de plusieurs blocs interactifs (filtre de galerie, compteur de panier, carrousel avec navigation), comparé à un thème équivalent en apparence mais reposant sur du JavaScript classique attaché après le rendu, sans directives serveur.
Comment fonctionne le rendu côté serveur de l’Interactivity API
Un bloc utilisant l’Interactivity API déclare un état initial et des directives dans son balisage via la fonction wp_interactivity_state() et des attributs data-wp-bind, data-wp-on, data-wp-context, calculés et injectés au moment du rendu du bloc côté PHP :
wp_interactivity_state( 'monTheme/galerie', [
'filtreActif' => 'tous',
'total' => count( $images ),
] );
?>
<div data-wp-interactive="monTheme/galerie" data-wp-context='{"filtreActif":"tous"}'>
<button data-wp-on--click="actions.filtrer">Filtrer</button>
</div>Ce mécanisme diffère fondamentalement d’un simple attribut class ou id statique : la valeur de data-wp-context est sérialisée en JSON à chaque rendu de bloc, ce qui implique un appel à wp_json_encode() et une résolution de l’état courant du bloc avant même que le HTML ne soit envoyé au navigateur.
Le protocole de mesure
Deux versions du même gabarit de page ont été comparées, l’une utilisant quatre blocs interactifs via l’Interactivity API, l’autre reproduisant visuellement le même comportement avec du JavaScript vanilla attaché en defer après le chargement de la page, sans directive de rendu serveur :
| Mesure | Blocs classiques + JS | Interactivity API |
|---|---|---|
| Temps de rendu serveur (4 blocs) | 38 ms | 94 ms |
| Temps avant interactivité côté client | 640 ms (attente du JS) | 180 ms (hydratation ciblée) |
| Poids JavaScript transféré | 42 Ko | 11 Ko (module d’exécution partagé) |
Le surcoût de rendu serveur, environ 56 millisecondes pour quatre blocs soit 14 millisecondes par bloc en moyenne sur ce thème, s’est révélé largement compensé côté client : le temps avant qu’un visiteur puisse effectivement interagir avec un composant est descendu de 640 à 180 millisecondes, l’Interactivity API évitant le téléchargement puis l’exécution d’un script JavaScript classique avant toute interaction possible.
Où va ce surcoût de rendu serveur
La majeure partie du temps supplémentaire mesuré via Query Monitor et un profil Blackfire provenait de la sérialisation JSON répétée de l’état de chaque bloc, plutôt que de la génération du balisage HTML lui-même. Sur une page avec un grand nombre de blocs interactifs identiques (une galerie de cinquante vignettes, chacune avec son propre contexte), ce coût devient linéaire et peut se faire sentir plus nettement que sur les quatre blocs testés ici.
Ce que ce chiffre signifie pour un choix d’architecture
- Le surcoût de rendu serveur de l’Interactivity API reste modeste en valeur absolue pour un nombre raisonnable de blocs interactifs par page.
- Le bénéfice principal se situe côté client, sur le temps avant interactivité effective, pas sur le temps de rendu serveur lui-même.
- Une page qui répète un grand nombre de fois le même bloc interactif doit être testée spécifiquement, le coût de sérialisation d’état pouvant s’accumuler de façon linéaire.
Un gain côté client se paie rarement à zéro côté serveur : la question n’est jamais s’il y a un coût, mais s’il reste proportionné au bénéfice obtenu.
En résumé
Ce billet ne traite pas de l’écriture des blocs interactifs eux-mêmes, uniquement du coût de rendu qu’ils introduisent côté serveur une fois adoptés. Sur ce thème et ce jeu de blocs, le compromis s’est révélé favorable : quelques dizaines de millisecondes de rendu serveur supplémentaires contre une interactivité perçue nettement plus rapide côté visiteur.
