# Interactivity API côté serveur : le vrai coût de rendu mesuré

> Mesure du surcoût serveur introduit par l'hydratation de blocs interactifs sur un thème utilisant l'Interactivity API depuis sa stabilisation, comparé à un thème classique.

- Auteur : Clément Hadrot
- Publié le : 2024-08-10
- Mis à jour le : 2024-08-10
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/interactivity-api-cout-rendu-serveur-mesure/

## L’essentiel

- L'Interactivity API génère des directives data-wp-* traitées côté serveur avant l'hydratation client
- Le surcoût de rendu dépend du nombre de blocs interactifs présents sur la page
- Le gain en interactivité côté client a un prix mesurable côté serveur

« 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

> L'essentiel à retenir : L'Interactivity API génère des directives data-wp-* traitées côté serveur avant l'hydratation client ; Le surcoût de rendu dépend du nombre de blocs interactifs présents sur la page ; Le gain en interactivité côté client a un prix mesurable côté serveur

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.