# Réécrire un bloc React front en Interactivity API : notre retour chiffré > Poids JavaScript, score INP, temps de développement : les chiffres réels d'une migration d'un bloc front hydraté en React vers l'Interactivity API, sans enjoliver. - Auteur : Clément Hadrot - Publié le : 2025-12-18 - Mis à jour le : 2025-12-18 - Catégorie : Blocs Gutenberg - URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/migrer-bloc-react-vers-interactivity-api-retour-chiffre/ ## L’essentiel - Le poids JS front a été divisé par plus de quatre après migration - Le score INP s'est amélioré sur les pages à forte densité de blocs interactifs - Le temps de développement de la migration a dépassé l'estimation initiale de 30 % Un configurateur de devis en ligne, développé à l'origine en 2022 comme bloc Gutenberg avec hydratation React côté front (un composant React monté dans le DOM via `ReactDOM.render` au chargement de la page), commençait à peser lourd : environ 180 Ko de JavaScript uniquement pour ce bloc, sur des pages qui en contenaient parfois deux instances. Avec la stabilisation de l'Interactivity API en WordPress 6.5 et sa maturation continue depuis, l'équipe a décidé de mesurer sérieusement si une réécriture valait le coût, plutôt que de se fier à l'intuition que « l'Interactivity API est plus légère ». Ce retour d'expérience assume ses chiffres bruts, y compris ceux qui n'allaient pas dans le sens espéré au départ, notamment sur le temps de développement réel de la migration. ## Le point de départ : un bloc React classique Le bloc original chargeait React et ReactDOM en dépendances (partiellement externalisées par WordPress puisque déjà présentes pour l'éditeur, mais dupliquées côté front public qui n'a pas ces mêmes dépendances chargées par défaut), plus le code du composant lui-même, ses hooks d'état local, et une bibliothèque de gestion de formulaire tierce pour la validation des champs du devis. ``` // Ancienne approche, extrait simplifié import { createRoot } from 'react-dom/client'; import ConfigurateurDevis from './ConfigurateurDevis'; document.querySelectorAll( '.wp-block-agence-configurateur' ).forEach( ( conteneur ) => { const racine = createRoot( conteneur ); racine.render( ); } ); ``` ## La réécriture en Interactivity API La réécriture a remplacé l'ensemble du composant React par des directives déclaratives dans le rendu PHP du bloc (`data-wp-bind`, `data-wp-on`, `data-wp-each` pour les listes d'options répétées) et un store JavaScript unique définissant l'état, les actions et les callbacks, sans dépendance à React côté front. ``` import { store, getContext } from '@wordpress/interactivity'; store( 'agence/configurateur-devis', { state: { get totalEstime() { const context = getContext(); return context.optionsChoisies.reduce( ( total, option ) => total + option.prix, 0 ); }, }, actions: { basculerOption( evenement ) { const context = getContext(); const id = evenement.target.dataset.optionId; context.optionsChoisies = context.optionsChoisies.some( ( o ) => o.id === id ) ? context.optionsChoisies.filter( ( o ) => o.id !== id ) : [ ...context.optionsChoisies, trouverOption( id ) ]; }, }, } ); ``` La validation de formulaire, auparavant déléguée à une bibliothèque tierce complète, a été réécrite à la main pour les quelques règles réellement utilisées (champ requis, format numérique, plage de valeurs), ce qui a éliminé une dépendance de 45 Ko à elle seule. > L'essentiel à retenir : Le poids JS front a été divisé par plus de quatre après migration ; Le score INP s'est amélioré sur les pages à forte densité de blocs interactifs ; Le temps de développement de la migration a dépassé l'estimation initiale de 30 % ## Les chiffres de poids JavaScript | Mesure | Avant (React) | Après (Interactivity API) | | --- | --- | --- | | Poids JS front (non compressé) | 180 Ko | 42 Ko | | Poids JS front (gzippé) | 58 Ko | 13 Ko | | Dépendances tierces chargées | 3 (React, ReactDOM, lib. formulaire) | 0 | ## Impact mesuré sur l'INP L'Interaction to Next Paint, métrique qui a remplacé le First Input Delay dans les Core Web Vitals en mars 2024, mesure la réactivité perçue lors des interactions utilisateur. Sur les pages contenant deux instances du configurateur (donc auparavant deux montages React distincts), le p75 de l'INP mesuré via le CrUX (Chrome User Experience Report) est passé de 340 ms à 210 ms sur les huit semaines suivant la mise en production de la migration — une amélioration réelle, bien qu'inférieure au facteur de réduction du poids JS, ce qui rappelle que l'INP dépend de bien d'autres facteurs que le seul poids du bundle initial. ## Le temps de développement, sans enjoliver L'estimation initiale tablait sur cinq jours de développement pour la migration complète, en misant sur la simplicité apparente des directives déclaratives. Le temps réel constaté a été de sept jours, principalement à cause de deux difficultés sous-estimées : la réécriture de la logique de validation de formulaire sans bibliothèque tierce a pris plus de temps que prévu pour couvrir tous les cas limites déjà gérés automatiquement par l'ancienne bibliothèque, et la gestion de l'état dérivé (le total du devis recalculé dynamiquement) a nécessité plusieurs itérations pour bien distinguer ce qui relevait du `context` local et du `state` global du store. ### Ce qui n'a pas changé - L'expérience utilisateur finale reste identique visuellement et fonctionnellement : ce chantier était invisible pour les clients du site, un choix assumé de « dette technique traitée en coulisses ». - Le rendu côté éditeur (l'aperçu dans Gutenberg) n'a pas été touché par cette migration, qui ne concernait que le comportement front public du bloc. > Le conseil qu'on retient pour une prochaine migration similaire : chiffrer sérieusement le temps de réécriture des dépendances tierces qui semblaient anodines, en particulier une bibliothèque de validation de formulaire, presque toujours plus riche en cas limites gérés silencieusement qu'on ne l'imagine avant de devoir la remplacer soi-même. ## En résumé Cette migration a tenu ses promesses sur le poids JavaScript, divisé par plus de quatre, et a apporté un gain réel mais plus modeste sur l'INP mesuré en conditions réelles. Le temps de développement a dépassé l'estimation de 30 %, principalement à cause de la réécriture de la validation de formulaire — un coût à intégrer honnêtement dans toute décision de migration similaire, plutôt que de ne retenir que les gains de performance côté communication interne.