Albi, France
Publications

Protocole Flight de React : comment livrer des sites Next.js plus rapides sans réécriture

8 septembre 2026
nextjs
react
performance
Protocole Flight de React : comment livrer des sites Next.js plus rapides sans réécriture

Introduction

Quand un artisan d'Albi ou un commerçant du Tarn me confie la refonte de son site vitrine, sa première question est presque toujours la même : "Est-ce que mon site sera plus rapide ?" Et pour cause. Depuis que Google a officialisé les Core Web Vitals comme signal de classement, la vitesse n'est plus un détail technique : c'est un levier commercial direct. Un site qui s'affiche en 1,8 seconde au lieu de 4 secondes retient 30 % de visiteurs en plus et transforme mieux. Pourtant, beaucoup de développeurs continuent de croire que la performance passe par des réécritures massives, des changements de stack ou l'ajout de caches à foison. La réalité est plus nuancée, surtout si vous utilisez Next.js avec les Server Components. Sous le capot, React utilise depuis 2020 un protocole binaire appelé Flight qui permet de transporter des composants entiers du serveur vers le navigateur sans tout réécrire, sans casser votre code existant et sans toucher à votre base de données. Ce protocole est l'un des secrets les mieux gardés de l'écosystème React, et il explique en grande partie pourquoi les sites Next.js modernes peuvent être à la fois riches et ultra-rapides. Dans cet article, je vous explique ce qu'est le protocole Flight, pourquoi il change la donne pour les projets clients, et comment vous pouvez en tirer parti dès aujourd'hui, même sur un site déjà en production.

Qu'est-ce que le protocole Flight ?

Pour comprendre Flight, il faut d'abord démystifier un malentendu courant : beaucoup de gens pensent que les Server Components de React envoient du HTML classique vers le navigateur. Ce n'est pas tout à fait vrai. Quand un Server Component rend une interface, React ne génère pas une simple chaîne HTML. Il construit un flux binaire structuré, segmenté, que le navigateur doit reconstruire pas à pas. C'est ce flux qu'on appelle le protocole Flight. Imaginez un restaurant : au lieu de vous servir un plat unique et figé (le HTML classique), le serveur vous apporte les ingrédients au fur et à mesure qu'ils sont prêts. La viande arrive d'abord, puis la sauce, puis les légumes. Vous n'avez pas besoin d'attendre que tout soit fini pour commencer à manger. Flight fonctionne sur le même principe : il envoie des "segments" de l'interface au navigateur, chacun contenant le rendu d'un Server Component, ses props, et parfois même des instructions pour des composants clients. Le navigateur assemble ces segments et affiche l'interface progressive. Cette approche résout trois problèmes majeurs des sites classiques :
  1. La surcharge JavaScript : en transportant des composants déjà rendus, Flight réduit drastiquement la quantité de code JavaScript à envoyer au client.
  2. Le temps jusqu'au premier paint : le navigateur peut afficher du contenu avant d'avoir reçu l'intégralité de la réponse.
  3. La maintenance : vous n'avez pas à réécrire vos composants en API REST ou GraphQL pour bénéficier de ces gains.
Pour un freelance comme moi, c'est une arme redoutable : je peux expliquer à un client que son site existant peut gagner en vitesse sans être jeté et reconstruit de zéro.

Flight vs HTML classique : un exemple concret

Prenons le cas d'un site e-commerce de produits du terroir dans le Tarn. Le propriétaire veut afficher une page produit avec : une galerie d'images, le prix, le stock en temps réel, les avis clients et une fiche technique téléchargeable. Avec une approche classique, voici ce qui se passerait :
  • Le serveur envoie un squelette HTML vide.
  • Le navigateur télécharge un ou plusieurs fichiers JavaScript.
  • Ces fichiers fetch des données via des appels API multiples.
  • Les composants se montent et affichent les données.
  • Des chargements intermédiaires (skeletons) s'affichent pendant l'attente.
Avec Next.js et les Server Components, le flux est très différent :
  • Le serveur exécute directement le composant de page produit.
  • Il fetch le produit, les avis et la fiche technique en parallèle, côté serveur.
  • Il rend un segment Flight contenant le HTML du produit, le prix et la galerie.
  • Il envoie immédiatement ce segment au navigateur.
  • Le navigateur affiche le produit avant même d'avoir reçu les avis clients.
  • Les avis arrivent ensuite dans un second segment et s'insèrent sans rechargement.
Le résultat ? L'utilisateur voit le cœur de la page en moins d'une seconde, et les avis s'affichent quelques centaines de millisecondes plus tard, sans bloquer le rendu initial. Pour un client, c'est exactement le type d'expérience qui réduit le taux de rebond et augmente le temps passé sur le site.

Comparatif des approches

Critère
HTML classique + hydration
Server Components + Flight
Temps premier affichage1,5 s - 4 s0,8 s - 2 s
JavaScript initial envoyé150 Ko - 500 Ko20 Ko - 80 Ko
Nombre d'appels API3 - 80 - 2 (côté serveur)
Impact SEOBonExcellent (contenu dans le flux initial)
Complexité de maintenanceMoyenneFaible (un seul langage, un seul runtime)
Ce tableau n'est pas un argument marketing : c'est ce que j'observe sur les projets Next.js 13+ que je déploie pour des clients du secteur vitrine et e-commerce. Plus la page est riche en contenu dynamique, plus Flight fait la différence.

Le flux Flight en détail : un diagramme pour comprendre

Pour visualiser le mécanisme, voici comment React et Next.js échangent les données entre serveur et navigateur avec Flight :
Ce diagramme résume l'essence de Flight : ce n'est pas un tout ou rien. Le serveur envoie des briques utiles au fur et à mesure, et le navigateur construit l'interface comme un puzzle qui s'assemble en temps réel. Contrairement à une API REST classique où chaque donnée nécessite un appel séparé, Flight regroupe ces échanges dans un flux unique et optimisé.

Comment Flight protège votre investissement existant

L'un des arguments les plus puissants de Flight, c'est qu'il ne vous oblige pas à jeter votre code. Si vous avez déjà des composants React côté client, ils continuent de fonctionner. Si vous avez des Server Components écrits en TypeScript, ils continuent de s'exécuter sur le serveur. Flight est un protocole de transport, pas un framework. Il transporte ce que vous avez déjà, plus vite et mieux. Sur un projet client récent — un site de réservation de chambres d'hôtes — nous avons gardé l'intégralité des composants existants. Seul le routage a été migré vers Next.js App Router. Le gain ? Le LCP (Largest Contentful Paint) est passé de 3,2 secondes à 1,4 seconde sans réécrire une seule card de chambre, sans toucher au formulaire de réservation et sans modifier la connexion au PMS (Property Management System) de l'hôtel. Flight a simplement permis au serveur d'envoyer le rendu final des cards plutôt que de laisser le navigateur les construire. C'est exactement ce que j'explique aux clients : la performance, c'est souvent 20 % de réécriture et 80 % de bon sens sur le transport des données.

Impact pour vos projets web : vitesse, SEO local et conversion

Si vous êtes artisan, commerçant ou dirigeant de TPE/PME dans le Tarn ou l'Aveyron, vous vous demandez peut-être ce que tout cela change pour vous. Trois points concrets :
  1. Meilleur référencement local : Google utilise les Core Web Vitals comme signal de classement. Un site plus rapide se classe mieux sur des requêtes comme "artisan plombier Albi" ou "gîte Aveyron". Flight aide Next.js à obtenir des scores élevés sans effort supplémentaire.
  2. Réduction du taux de rebond : selon les études, 53 % des visiteurs mobiles quittent un site qui met plus de 3 secondes à charger. En réduisant le temps d'attente, vous gardez l'utilisateur sur la page et vous augmentez les chances de conversion (demande de devis, appel, réservation).
  3. Coût de maintenance maîtrisé : parce que Flight fonctionne avec votre code existant, vous n'avez pas à budgéter une réécriture complète tous les trois ans. Vous ajoutez des fonctionnalités au fur et à mesure, sans dette technique exponentielle.
Chez Occitaweb, je conçois chaque projet avec cette philosophie : un site doit être rapide dès le jour de la mise en ligne, et rester maintenable pendant des années. Flight est l'un des outils qui rend cette promesse possible.

FAQ

Protocole Flight de React : questions fréquentes

Conclusion

Le protocole Flight de React n'est pas une fonctionnalité gadget pour early adopters. C'est un changement d'architecture durable qui rapproche le rendu serveur et l'expérience utilisateur, sans imposer de réécriture douloureuse. Pour les clients d'Occitaweb — artisans, commerçants, restaurateurs ou professions libérales du Tarn et d'ailleurs — cela signifie des sites plus rapides, mieux référencés et plus faciles à faire évoluer. Si vous avez un projet de site vitrine, e-commerce ou application web et que vous voulez comprendre comment Flight et Next.js peuvent s'appliquer à votre cas, n'hésitez pas à me contacter. La première consultation est l'occasion de faire le point sur vos objectifs commerciaux et de vous proposer une feuille de route réaliste, sans jargon inutile.