Vérifier le streaming dans le navigateur

Une page peut afficher un état d’attente sans transmettre progressivement son contenu. Pour vérifier que le catalogue répond avant la fin du chargement du détail, observez ce qui arrive réellement dans le navigateur et dans la réponse réseau.

À la leçon précédente, vous avez placé une frontière Suspense autour du rendu asynchrone du détail et prévu un repli accessible. Ici, vous ne modifiez pas cette structure : vous vérifiez si le serveur envoie effectivement une première partie de la page avant que le détail soit prêt, puis si le contenu final arrive ensuite.

Préparer une observation fiable

Faites l’essai sur la route déjà utilisée pour la référence Lighthouse, `/randonnees/cretes-du-jura`. Pour éviter de tirer des conclusions d’un serveur de développement, construisez et lancez l’application en mode production dans un terminal, puis ouvrez la route dans le navigateur. Utilisez les scripts Next.js habituels du projet ; ne remplacez pas les commandes existantes de `package.json`.

npm run build
npm run start

Le build de production se termine, puis le serveur démarre. Gardez ce terminal ouvert pendant les vérifications.

Dans les outils de développement du navigateur, ouvrez l’onglet Réseau, activez la conservation du journal, puis rechargez la route. Sélectionnez la requête de type document correspondant à cette page et observez sa durée, son contenu et le moment où la réponse commence à arriver. Une limitation réseau peut rendre l’attente plus visible, mais gardez les mêmes conditions entre les essais.

Lire l’ordre d’arrivée des fragments

Le streaming HTML désigne l’envoi d’une réponse en plusieurs fragments au fur et à mesure qu’ils sont prêts, plutôt que l’attente de la page complète avant le premier octet utile. Dans le navigateur, vérifiez que la structure générale de la page ou son contenu non suspendu apparaît alors que le détail est encore en attente. Le fragment associé au détail doit ensuite compléter la page ; l’ordre observé est plus important qu’un libellé technique précis dans le HTML.

La chronologie du waterfall aide à relier ces événements : repérez le début de la réponse du document, puis comparez-le à l’apparition du contenu final dans l’onglet Éléments. Selon la version de Next.js et du navigateur, des marqueurs de transport ou des scripts internes peuvent participer à la mise à jour de l’arbre affiché. Ne prenez pas leur texte brut pour le contenu destiné au visiteur : validez aussi le résultat visuel et le statut de chargement.

Confirmer la réponse sans interface graphique

Vous pouvez compléter l’inspection avec `curl` en désactivant l’affichage tamponné côté client. Cette commande ne reconstitue pas à elle seule l’expérience du navigateur, mais elle permet de voir si les octets de la réponse sont livrés au fil de leur arrivée plutôt qu’affichés uniquement à la fin.

curl --no-buffer --include http://localhost:3000/randonnees/cretes-du-jura

Les en-têtes HTTP et le corps HTML s’affichent à mesure que curl reçoit la réponse. Selon le rythme du serveur et les tampons réseau, plusieurs fragments peuvent apparaître rapprochés ou être regroupés.

Une absence de fragments visiblement séparés ne prouve pas que Suspense est mal placé. Le serveur, un proxy, un CDN ou le protocole peuvent regrouper les données en transit ; à l’inverse, une réponse qui semble progressive en développement peut différer en production. Répétez l’essai, comparez l’affichage avec la chronologie et vérifiez que le détail finit bien par apparaître sans rechargement manuel.

À retenir

• Vérifiez la route en production, dans les mêmes conditions de mesure que votre référence.
• Confirmez que le contenu non suspendu arrive avant le détail, puis que celui-ci apparaît sans intervention.
• Croisez l’affichage de la page, la chronologie du document dans le waterfall et, si utile, l’observation avec curl.
• Interprétez prudemment les fragments : la mise en tampon réseau peut masquer leur arrivée progressive.

Vous pourrez ensuite examiner quelles parties de l’interface doivent rester rendues côté serveur afin de limiter le JavaScript envoyé au navigateur.