Le problème de l’hydratation complète

L'hydratation est le processus par lequel React prend le HTML généré par le serveur et lui associe des écouteurs d'événements JavaScript. Le serveur envoie le HTML initial, rapidement, puis le navigateur télécharge le paquet JavaScript et React « hydrate » le HTML statique pour le rendre interactif. Tant que l'hydratation n'est pas terminée, la page semble interactive, mais elle ne l'est pas.

Une application monopage traditionnelle envoie l'intégralité du paquet JavaScript au navigateur. React doit le télécharger, l'analyser, l'exécuter, puis associer des écouteurs d'événements à chaque composant de l'arbre. Pour les grandes applications, ce processus peut prendre plusieurs secondes sur des appareils mobiles de gamme intermédiaire.

Le temps avant interactivité mesure le délai avant que l'utilisateur puisse interagir avec la page. L'hydratation bloque directement le TTI : la page peut sembler prête, puisque le HTML généré par le serveur est visible, mais les boutons et les formulaires ne répondent pas tant que React n'a pas fini d'associer les écouteurs d'événements. Un TTI élevé correspond à une mauvaise expérience utilisateur.

Prenons l'exemple d'une page marketing : 80 % de son contenu est constitué de texte, d'images et d'en-têtes statiques qui ne changent jamais. Seuls 20 % concernent des composants interactifs comme un formulaire d'inscription à une lettre d'information ou un lecteur vidéo. L'hydratation traditionnelle d'une SPA s'exécute malgré tout sur 100 % de la page et traite inutilement les composants statiques.

Le profilage des performances dans Chrome DevTools révèle le coût de l'hydratation. Dans le diagramme en cascade du fil d'exécution principal, vous pouvez repérer la tâche « hydratation de React » sous la forme d'un long bloc d'exécution JavaScript après le premier rendu. Plus ce bloc est long, plus le fil principal est occupé et moins la page est réactive.

Plus l'arbre des composants React est grand, plus l'hydratation demande de travail. React doit parcourir chaque composant, comparer le HTML généré par le serveur avec ce que le composant produirait, puis associer les écouteurs d'événements. Une page complexe comportant des centaines de composants peut présenter une surcharge d'hydratation mesurable, même sur des appareils rapides.

React 18 a introduit l'hydratation concurrente, qui permet à React de diviser l'hydratation en blocs plus petits et de céder la main au navigateur entre chacun d'eux. Le navigateur ne semble ainsi pas complètement figé pendant l'hydratation des grands arbres. Toutefois, l'hydratation concurrente atténue l'impact sans éliminer le coût fondamental.

L'hydratation sélective, via Suspense, permet à React d'hydrater les composants par ordre de priorité : les interactions de l'utilisateur déclenchent l'hydratation immédiate du composant concerné. Cela améliore la réactivité, mais fonctionne toujours au sein d'un seul arbre React : tous les composants de l'arbre finissent par être hydratés.

L'idée fondamentale à l'origine de l'architecture en îlots est que la plupart des pages types n'ont tout simplement pas besoin de JavaScript. Les barres de navigation, les sections d'accroche, les liens du pied de page, le texte des articles de blog et les descriptions de produits sont uniquement destinés à la présentation. Les forcer à subir une hydratation est donc inutile par définition.

Les études menées par les équipes spécialisées dans les performances web montrent que le temps d'analyse et d'exécution de JavaScript constitue le coût dominant sur les appareils mobiles. Un paquet JavaScript de 300 ko nécessite 2 à 3 secondes pour être analysé sur un téléphone Android médian. Réduire la quantité de JavaScript envoyée au navigateur apporte des gains de performance disproportionnés par rapport à toute optimisation interne de React.

Chaque kilo-octet de JavaScript ajouté à une application React augmente le travail d'hydratation. Même si un composant est purement décoratif, il participe à l'hydratation dès lors qu'il se trouve dans l'arbre React. Ce « surcoût de l'hydratation » augmente avec la taille de l'application et rend progressivement plus difficile le maintien de bons TTI à mesure que les applications grandissent.

Quelle est la relation entre l'hydratation de React et le temps avant interactivité (TTI) ?

L'hydratation traditionnelle de React traite l'intégralité de l'arbre des composants, y compris le contenu statique qui n'a pas besoin de JavaScript. Elle bloque le temps avant interactivité et évolue mal avec la taille de l'application. Les améliorations de l'hydratation concurrente et sélective de React 18 atténuent l'impact sans éliminer le coût fondamental. L'idée fondamentale est que la plupart du contenu d'une page n'a tout simplement pas besoin de JavaScript, ce qui rend l'hydratation complète inutile.