Streaming SSR avec Next.js : impacts sur APIs Drupal, images et cache

1. Ce que le streaming SSR change concrètement

Dans le modèle SSR classique, Next.js attend la résolution de toutes les promesses de données avant d'émettre le premier octet HTML. Le temps de réponse perçu est celui du composant le plus lent.

Avec le streaming, le serveur envoie le shell HTML immédiatement : navigation, entête, squelettes de contenu. Puis, à mesure que les composants serveur résolvent leurs données, les blocs sont transmis via un flux HTTP et injectés côté client sans rechargement de page. Le First Byte arrive plus tôt, et l'utilisateur perçoit une page qui « arrive » progressivement.

Ce modèle s'appuie sur deux primitives Next.js :

• <Suspense> — délimite les zones à rendre en différé, avec un fallback affiché pendant le chargement.
• loading.tsx — définit un état intermédiaire au niveau d'un segment de route entier.

Conséquence directe : vos appels API ne peuvent plus se concentrer dans un getServerSideProps monolithique. Chaque composant serveur déclenche ses propres requêtes au moment de son rendu.

2. Impacts sur les APIs Drupal

De la requête monolithique aux requêtes granulaires

En SSR classique, une seule requête JSON:API avec include alimentait toute la page. Avec le streaming, chaque <Suspense> boundary peut déclencher ses propres requêtes — ce qui amplifie deux risques :

• Sur-sollicitation de Drupal. Un pic de requêtes parallèles frappe PHP-FPM simultanément, surtout pour les contenus non cachés.
• Waterfalls de composants. Si un composant B attend les données du composant A pour connaître les identifiants à requêter, les deux appels s'exécutent en séquence.

Recommandations : utilisez la déduplication automatique de Next.js (fetch identiques dans le même cycle sont dédupliqués), remontez les données partagées au layout parent, et préférez des routes API Next.js pour les agrégations complexes.

Gestion des erreurs partielles

En streaming, un composant peut échouer sans bloquer le reste de la page — à condition de poser des error.tsx précis. Sans boundary d'erreur dédié, l'échec remonte jusqu'au layout racine et effondre toute la page.

3. Images et transformations côté edge/CDN

Le composant <Image> en contexte streaming

Les images critiques (hero, au-dessus de la ligne de flottaison) ne doivent pas être derrière un <Suspense> — elles arrivent trop tard et provoquent un saut de mise en page (layout shift) visible. Intégrez-les dans le shell HTML initial et utilisez l'attribut priority pour déclencher un préchargement.

Image Styles Drupal vs Next.js Image Optimization

Les deux systèmes peuvent coexister, mais leur combinaison crée un cache à deux niveaux complexe. En streaming, si un dérivé Drupal n'est pas encore généré, Next.js reçoit une erreur transitoire. Recommandation : choisissez un seul niveau de transformation, configurez la génération des dérivés à la création du contenu (pas à la première visite), et vérifiez que vos headers Cache-Control incluent un s-maxage suffisant.

4. Effets sur le cache

Le cache HTTP fragmenté

Les CDN traditionnels bufferisent le flux complet avant de le servir depuis le cache — ce qui annule le gain de TTFB pour les visiteurs suivants. Configuration correcte : désactivez le cache CDN sur les routes streamées (ou configurez le no-buffering), cachez les données à la source (Drupal + Redis) et au niveau composant Next.js via next: { revalidate: N }.

Revalidation partielle avec les tags

Next.js permet d'invalider uniquement les composants qui consomment un nœud modifié via revalidateTag(). Pour en tirer parti avec Drupal, configurez un webhook de purge déclenché à chaque modification de contenu, couplé au module Drupal Purge.

5. Observabilité en contexte streaming

En streaming, une seule requête HTTP couvre plusieurs composants en parallèle. Sans tracing distribué, vous verrez une trace de plusieurs secondes sans détail interne.

• Activez OpenTelemetry dans Next.js (instrumentation.ts).
• Côté Drupal, activez les headers Server-Timing sur chaque réponse API.
• Loggez les temps de résolution de chaque fetch serveur pour identifier les composants lents.

6. Guide de tests pour éviter clignotements et incohérences

Le streaming introduit des bugs visuels spécifiques : transitions entre fallback et contenu final, sauts de layout, flashs de contenu non stylé.

• Throttlez votre réseau à 3G et observez l'ordre d'apparition des blocs.
• Vérifiez le Cumulative Layout Shift (CLS) sur les pages streamées — les images sans dimensions dans les zones Suspense en sont la cause principale.
• Simulez une erreur Drupal et vérifiez que chaque zone se dégrade sans effondrer la page entière.
• Testez la cohérence des données entre le shell HTML et les chunks streamés — une incohérence de session ou de langue produit des affichages contradictoires.
• Activez les React strict mode warnings pour détecter les effets non idempotents.

Ce qu'il faut retenir

Le streaming SSR améliore la perception de performance, pas nécessairement les métriques brutes. Son adoption est justifiée quand la page contient des blocs à latences disparates. Elle demande en échange une rigueur accrue sur la granularité des appels API Drupal, la stratégie de cache à chaque niveau de la pile, et la couverture de tests visuels.