# Le rendu serveur de l’Interactivity API : où se cache le vrai coût perf

> Trois ans après son arrivée, un audit chiffré du coût réel de l'hydratation et du state serveur de l'Interactivity API sur des pages à forte interactivité.

- Auteur : Clément Hadrot
- Publié le : 2026-04-01
- Mis à jour le : 2026-04-01
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/rendu-serveur-interactivity-api-cout-perf/

## L’essentiel

- L'hydratation initiale a un coût CPU mesurable, distinct du poids du JavaScript
- Le state sérialisé côté serveur grossit avec le nombre de blocs interactifs
- Le vrai goulot d'étranglement se déplace du réseau vers le rendu

L'Interactivity API, arrivée avec WordPress 6.5 en avril 2024, a changé la façon dont les blocs Gutenberg peuvent devenir interactifs côté client, avec une promesse centrale : un poids JavaScript très inférieur à ce qu'imposerait un framework front-end classique, grâce à un state partagé entre le rendu serveur et l'hydratation client. Trois ans après son introduction, avec un recul suffisant sur des projets en production, un audit a été mené sur un site d'inscription à des ateliers associatifs qui utilise intensivement cette API, pour chiffrer où se situe réellement le coût de performance de cette architecture, au-delà du discours initial centré sur le poids réduit du JavaScript.

## Ce que l'Interactivity API fait réellement

Contrairement à une hydratation classique où le client doit reconstruire l'intégralité de l'état de l'application avant de devenir interactif, l'Interactivity API sérialise le state directement dans le HTML généré côté serveur, sous forme d'un bloc `script type="application/json"` avec l'identifiant `wp-script-module-data-@wordpress/interactivity`. Le client n'a donc pas besoin de recalculer cet état : il le lit directement, ce qui réduit effectivement le travail JavaScript nécessaire à l'hydratation par rapport à un framework qui devrait tout recalculer côté client.

## Le protocole de mesure

Le site testé propose des pages d'inscription à des ateliers avec un nombre variable de blocs interactifs (compteur de places disponibles, formulaire d'inscription rapide, filtre de recherche par créneau), chacun utilisant l'Interactivity API. Trois versions de la même page ont été comparées : une version à 3 blocs interactifs, une à 15, et une à 40, avec mesure du temps entre le premier rendu visuel (LCP) et le moment où les interactions deviennent fonctionnelles (équivalent du Time to Interactive), via l'onglet Performance des DevTools Chrome.

> L'essentiel à retenir : L'hydratation initiale a un coût CPU mesurable, distinct du poids du JavaScript ; Le state sérialisé côté serveur grossit avec le nombre de blocs interactifs ; Le vrai goulot d'étranglement se déplace du réseau vers le rendu

## Résultats : le coût de l'hydratation grandit avec le nombre de blocs

| Nombre de blocs interactifs | Poids du state sérialisé (HTML) | Temps d'hydratation mesuré |
| --- | --- | --- |
| 3 blocs | 2,1 Ko | 38 ms |
| 15 blocs | 11 Ko | 96 ms |
| 40 blocs | 31 Ko | 210 ms |

Le résultat le plus notable n'est pas le poids du state sérialisé, qui reste modeste même à 40 blocs, mais le temps d'hydratation, qui croît de façon plus que proportionnelle au nombre de blocs : passer de 3 à 15 blocs (multiplication par 5) fait grimper le temps d'hydratation d'un facteur 2,5, mais passer de 15 à 40 blocs (multiplication par 2,7) fait grimper ce même temps d'un facteur supérieur à 2,1. Ce comportement s'explique par le coût du parcours et de l'attachement des directives (`data-wp-interactive`, `data-wp-bind`, etc.) sur chaque nœud du DOM concerné, un coût de traitement JavaScript qui grandit avec le nombre d'éléments interactifs, indépendamment du poids réseau du state lui-même.

## Où se déplace le goulot d'étranglement

Ce qui ressort de cet audit, c'est un déplacement du goulot d'étranglement plutôt qu'une suppression pure et simple : l'ancien modèle, avec un framework JavaScript classique côté client, souffrait principalement d'un excès de poids réseau (bibliothèque à télécharger, state à reconstruire). L'Interactivity API réduit fortement ce poids réseau, mais déplace une partie du coût vers le temps de traitement CPU nécessaire à l'attachement des directives sur le DOM, un coût qui n'apparaît pas dans une mesure de poids de page mais bien dans le profil d'exécution JavaScript.

## Un piège observé : des directives redondantes

Sur ce projet, une partie de la croissance non linéaire du temps d'hydratation venait d'un usage redondant de la directive `data-wp-bind` répétée sur des éléments imbriqués partageant le même state, plutôt que d'un unique niveau parent portant la directive et laissant la réactivité se propager. Simplifier cette structure sur les pages à 40 blocs a ramené le temps d'hydratation de 210 à 165 millisecondes, un gain de plus de 20 % sans réduire le nombre de blocs eux-mêmes.

```
<!-- Avant : directive répétée à chaque niveau, coûteux à parcourir -->
<div data-wp-interactive="atelier" data-wp-context='{"placesRestantes": 5}'>
  <span data-wp-bind--data-wp-context="context.placesRestantes">5</span>
  <span data-wp-bind--data-wp-context="context.placesRestantes">5</span>
</div>

<!-- Après : un seul contexte parent, propagation naturelle -->
<div data-wp-interactive="atelier" data-wp-context='{"placesRestantes": 5}'>
  <span data-wp-text="context.placesRestantes"></span>
</div>
```

## Notion : ce que ce coût implique en pratique

L'enseignement de cet audit n'est pas que l'Interactivity API serait mal conçue : sur un nombre raisonnable de blocs interactifs par page (moins d'une quinzaine, situation la plus courante), le coût d'hydratation reste largement sous la centaine de millisecondes et n'a pas d'impact perceptible pour un visiteur. Le piège se situe sur des pages à très forte densité d'interactivité, où le nombre de blocs justifierait presque une réflexion d'architecture (regrouper plutôt que multiplier les contextes interactifs) plutôt qu'un simple ajout de blocs les uns après les autres.

> Un state léger à transporter ne garantit pas un state léger à activer ; le réseau et le CPU ne partagent pas la même facture.

## Hors périmètre

Cet audit ne traite pas la sécurité du state sérialisé côté serveur (validation, exposition de données sensibles dans le HTML), sujet distinct déjà couvert ailleurs et qui mérite sa propre vigilance indépendamment des considérations de performance développées ici.

## En résumé

Trois ans après son arrivée, l'Interactivity API tient sa promesse de réduction du poids réseau, mais déplace une partie du coût vers le temps d'hydratation CPU, qui croît de façon non linéaire avec le nombre de blocs interactifs par page. Le bon réflexe reste de mesurer ce temps d'hydratation sur les pages les plus denses en interactivité plutôt que de se fier uniquement au poids apparent du state sérialisé.