Mesurer l’impact du streaming : FCP, TTI et LCP

FCP mesure le temps écoulé entre le début de la navigation et l'affichage à l'écran du premier élément de contenu (texte, image ou arrière-plan). La diffusion en flux améliore FCP en envoyant immédiatement la structure HTML initiale : le navigateur peut afficher la mise en page, la navigation et tout texte situé au-dessus de la ligne de flottaison dès l'arrivée des premiers fragments.

Avec un SSR synchrone (renderToString), le navigateur ne reçoit aucun HTML avant la fin du rendu complet. Avec la diffusion en flux, le navigateur reçoit la structure HTML initiale quelques millisecondes après la requête — la mise en page et le contenu statique apparaissent presque immédiatement, ce qui réduit considérablement FCP.

LCP mesure le moment où le plus grand élément visible dans la zone d'affichage est peint — généralement une image principale ou un grand titre. La diffusion en flux améliore LCP si l'élément LCP fait partie de la structure initiale, et non d'une limite Suspense, puisque la structure initiale est diffusée avant toute section dépendante des données.

Une optimisation clé consiste à concevoir votre page de manière que l'élément LCP — la section principale, le titre principal ou l'image mise en avant — se trouve en dehors de toute limite Suspense. Si l'élément LCP se trouve dans une limite Suspense en attente de données, la diffusion en flux ne peut pas améliorer LCP avant la résolution de ces données.

TTI mesure le moment où la page répond de manière fiable aux entrées utilisateur — sans tâche longue bloquant le fil d'exécution principal. La diffusion en flux, combinée à l'hydratation sélective, réduit TTI en répartissant le travail d'hydratation dans le temps plutôt qu'en exécutant une seule grande tâche d'hydratation synchrone après le téléchargement de tout le code JavaScript.

Le temps jusqu'au premier octet (TTFB) dépend de la latence du réseau et du temps de traitement du serveur avant l'envoi du premier octet. La diffusion en flux ne modifie pas TTFB — c'est là que le rendu en périphérie peut aider. Pour que la diffusion en flux améliore FCP, vous devez d'abord avoir un TTFB faible ; sinon, vous ne faites que diffuser depuis une origine lente.

La vue en pellicule de WebPageTest affiche une suite de captures d’écran prises toutes les 100 ms pendant le chargement de la page. Une page à rendu progressif montre la mise en place précoce de la mise en page, puis le remplissage progressif des sections. Une page sans rendu progressif affiche un écran vide, suivi d’une page entièrement rendue qui apparaît soudainement : la différence visuelle est nette.

Un banc de mesure pertinent compare la même page rendue de deux façons : avec le rendu en continu de Next.js RSC activé et avec un SSR synchrone traditionnel. Utilisez WebPageTest avec des conditions réseau fixes (par exemple, 3G rapide et ralentissement du CPU par 4), puis comparez les indicateurs FCP, LCP et TTI sur 3 exécutions afin d’obtenir une confiance statistique.

L’onglet Réseau de Chrome DevTools comporte un menu déroulant « Limitation » avec des préréglages tels que 3G rapide et 4G lente. La 3G rapide (1,6 Mbit/s, RTT de 150 ms) accentue la différence entre le rendu progressif et l’absence de rendu progressif, car elle amplifie le temps de téléchargement du document HTML complet et rend visibles les gains liés au téléchargement progressif.

Le délai entre une interaction et le prochain affichage (INP) mesure le temps écoulé entre une interaction de l’utilisateur et le prochain affichage. Il a remplacé FID en tant qu’indicateur essentiel du Web en 2024. Le rendu progressif réduit l’INP en donnant la priorité à l’hydratation des composants interactifs avec lesquels l’utilisateur est susceptible d’interagir en premier, ce qui réduit le temps de blocage avant que ces composants deviennent réactifs.

La configuration la plus efficace combine le rendu en périphérie (TTFB faible grâce à un point de présence proche), le rendu progressif (livraison progressive du HTML) et l’hydratation sélective (traitement progressif du JS). Ensemble, ces trois techniques réduisent au minimum tous les principaux indicateurs de performance pendant l’ensemble du cycle de chargement.

Le rendu progressif améliore principalement le FCP en livrant immédiatement l’enveloppe HTML, et améliore le LCP lorsque l’élément LCP se trouve dans cette enveloppe. Le TTI s’améliore grâce à l’hydratation sélective, qui répartit le travail du JS dans le temps. Le TTFB reste inchangé : utilisez le rendu en périphérie pour l’améliorer. Utilisez la vue en pellicule de WebPageTest et la limitation réseau de Chrome DevTools pour mesurer l’impact du rendu progressif, et optimisez l’INP comme principal indicateur d’interactivité des indicateurs essentiels du Web.