Next.js 16.3 (preview) : ce que les navigations instantanées changent pour vos apps

Vous cliquez sur un lien dans une application web, et il ne se passe rien. Une fraction de seconde, parfois plus, pendant laquelle l’écran reste figé. Puis le serveur répond, et la page suivante apparaît d’un coup. Ce trou entre le clic et l’affichage est la critique de fond adressée depuis des années aux applications rendues côté serveur, et aux Server Components en particulier. C’est exactement ce que Next.js 16.3 tente d’effacer avec une nouveauté baptisée Instant Navigations, dévoilée le 25 juin 2026 par Vercel, l’éditeur du framework Next.js.

Avant d’aller plus loin, un point qui n’est pas négociable. Cette version est une preview, une release de pré-production publiée sur le tag npm @preview (on l’installe avec npm install next@preview), pas une version stable. Vercel écrit noir sur blanc qu’il s’agit d’une pré-production, que ses propres applications l’utilisent, mais qu’il faut faire preuve de discernement avant de la déployer auprès de vrais utilisateurs, et que des changements sont probables avant le stable. Celui-ci est annoncé pour les prochaines semaines. On regarde donc ici une direction de fond, à tester en condition de bac à sable, pas une brique à pousser en production cette semaine.

Le problème : le clic, puis le vide

Pour comprendre l’intérêt d’Instant Navigations, il faut revenir au ressenti utilisateur. Vercel décrit deux séquences. Dans une application pilotée par le serveur, on clique, rien ne se passe, puis le serveur répond et la page suivante apparaît. Dans une single-page app (SPA), une application qui charge tout côté navigateur, on clique et un squelette de la page suivante s’affiche instantanément, données encore en cours de chargement, puis le serveur répond et la page se révèle complètement. La différence ne tient pas à la vitesse réseau, elle tient à ce moment où l’interface accuse réception du clic.

Vercel présente Instant Navigations comme une suite d’outils qui apportent à Next.js la réactivité des SPA pilotées côté client, sans renoncer aux bénéfices de son modèle server-driven. L’éditeur prend soin de préciser que le modèle côté serveur n’est pas mauvais en soi, et que les SPA donnent simplement un meilleur ressenti dans certains cas. L’objectif n’est donc pas d’opposer les deux mondes, mais de récupérer le squelette immédiat au clic tout en gardant le rendu serveur.

La mécanique : un choix par route, pas un réglage global

Le point central, et le plus structurant pour une équipe, c’est que rien n’est imposé d’un bloc. Le prérequis est d’activer le flag Cache Components dans next.config.ts avec cacheComponents: true. Ce flag, introduit avec Next.js 16, débloque un comportement décrit par Vercel comme dynamique par défaut, sans cache caché ni implicite. L’éditeur précise qu’il deviendra le défaut d’une future version majeure du framework, mais aujourd’hui il reste à activer soi-même.

Une fois ce flag actif, dès qu’une route attend une donnée côté serveur (un await), le développeur choisit, route par route, entre trois comportements. Le premier, Stream, s’appuie sur <Suspense> : l’utilisateur voit instantanément un état de chargement, et le reste de l’interface arrive en streaming. Le deuxième, Cache, repose sur la directive 'use cache' : l’utilisateur voit immédiatement une interface déjà mise en cache, réutilisée d’une requête à l’autre. Stream et Cache rendent tous deux la navigation immédiate, façon SPA. Le troisième, Block, fait l’inverse de façon assumée : avec export const instant = false, on choisit de garder la navigation liée au serveur, et le dialogue d’erreur de navigation lente disparaît pour cette route.

L’exemple donné par Vercel parle de lui-même : un blog qui ne veut jamais afficher de squelette de chargement pour ses articles pose simplement export const instant = false sur la page ou le layout concerné. C’est là que la philosophie devient intéressante pour une équipe produit. On ne subit pas un comportement global, on décide là où l’instantanéité a du sens et là où elle n’en a pas. Cette logique du cache choisi explicitement, route par route, prolonge le modèle introduit avec Cache Components : fin du cache implicite, contrôle granulaire assumé.

Garder ces navigations rapides dans le temps

Une navigation rapide le jour de la livraison qui se dégrade trois sprints plus tard, tout le monde connaît le scénario. Vercel s’attaque au problème avec Instant Insights. En développement, une navigation lente devient une erreur, pas un simple avertissement qu’on ignore. Un nouveau panneau du même nom fait remonter automatiquement les routes qui ne sont plus instantanées. L’éditeur explore aussi un moyen de remonter ces erreurs au moment du build pour attraper les régressions, mais ce point est annoncé comme une exploration, pas comme une fonctionnalité déjà livrée. La nuance compte : on ne promet pas ce qui n’existe pas encore.

Côté tests automatisés, un helper instant() importé depuis @next/playwright permet d’écrire des assertions sur ce qui doit être visible immédiatement après un clic, sans attendre le réseau. Concrètement, on entoure un clic et ses vérifications d’un await instant(page, ...) : on vérifie que le titre et un état de chargement apparaissent tout de suite, avant même que la donnée finale (dans l’exemple de Vercel, un état de stock) ne se charge. Pour une équipe qui veut éviter les régressions de performance ressentie, c’est un garde-fou directement branché sur la chaîne de tests, et non un audit ponctuel qu’on oublie.

Chez Koul, ce genre d’arbitrage est exactement le travail qu’on fait avec les équipes : décider quelles routes méritent l’instantanéité, lesquelles restent liées au serveur, et comment verrouiller ce choix dans les tests pour qu’il tienne dans la durée. Une preview comme celle-ci ne se juge pas sur une démo, mais sur ce qu’elle implique de discipline une fois le projet vivant. C’est aussi pour ça qu’on aborde toute nouveauté de framework par un temps d’audit et d’étude de cadrage avant de toucher au code en production.

Repenser le prefetching autour d’un squelette par route

Le deuxième grand chantier d’Instant Navigations concerne le prefetching, c’est-à-dire le chargement anticipé des pages vers lesquelles l’utilisateur pourrait naviguer. Jusqu’à Next.js 16.2, le framework envoyait une requête de prefetch par lien visible à l’écran, y compris quand plusieurs liens pointaient vers la même route. Sur une page qui défile, cela produisait une avalanche de requêtes dans l’onglet réseau. Vercel donne l’exemple d’une barre latérale de vingt liens de conversation : vingt liens, vingt prefetch.

En 16.3, l’approche change. Next.js précharge un squelette réutilisable par route plutôt qu’un prefetch par lien. Ces squelettes sont mis en cache côté navigateur et récupérés une seule fois. Reprenons la barre latérale : au lieu de vingt requêtes, un seul squelette est chargé pour la route /chat/[id], un autre pour /dashboard, et ils sont réutilisés pour tous les liens qui mènent à la même route. Vercel rapproche explicitement cette logique du découpage de code par route que pratiquent déjà les SPA.

Ce comportement porte un nom, Partial Prefetching, et s’active dans next.config.ts avec partialPrefetching: true, en complément de cacheComponents: true. Comme Cache Components, Vercel prévoit d’en faire le comportement par défaut d’une future version majeure. L’éditeur présente aussi ces squelettes réutilisables comme la fondation d’une future navigation hors-ligne, à nouveau formulée comme une exploration à venir et non comme une promesse livrée.

Pour diagnostiquer tout cela, un nouvel outil rejoint les DevTools de Next.js : le Navigation Inspector. Il permet de mettre chaque navigation en pause au niveau du squelette pour voir ce qui est préchargé pour une route, puis d’appuyer sur Resume pour afficher la page complète. On visualise ainsi, en développement, quelle partie d’une route s’affiche instantanément et laquelle n’arrive qu’après l’aller-retour réseau. À noter, comme avant, le prefetch réel ne s’active qu’en production.

Enfin, le défaut réduit à un squelette par route n’est pas un choix tout-ou-rien. Pour précharger davantage sur certains liens, on opte avec <Link prefetch={true}>. Même dans ce cas, Next.js ne rend pas toute la route en profondeur : il va jusqu’à ce qui est disponible de façon synchrone ou marqué 'use cache'. Pour aller plus loin, export const prefetch = 'allow-runtime' étend le prefetch au contenu mis en cache au moment de la requête, au prix d’une charge serveur supplémentaire. Le prefetch par lien reste, par défaut, limité au contenu connu au build. On retrouve la même philosophie que pour les navigations : un défaut raisonnable, et un opt-in granulaire quand on en a besoin.

Les preuves d’usage, et leurs limites

Vercel avance deux éléments de preuve. D’abord son propre produit v0 (v0.app), un générateur d’interfaces riche côté client dont les navigations, de l’aveu de l’éditeur, ne donnaient pas un ressenti instantané depuis un moment. Instant Insights a permis de pointer les routes non instantanées, et les temps de navigation se sont améliorés au fil des correctifs. Vercel annonce un billet de suivi sur les patterns retenus et indique que ces temps devraient encore se rapprocher de zéro. Point d’honnêteté important : le billet montre un graphique de temps de navigation sans valeur exacte lisible ni méthodologie publique. On s’en tient donc au qualitatif, des navigations plus rapides après correctifs, sans citer de pourcentage ou de milliseconde qui n’existe pas dans la source.

Ensuite, une démo open-source nommée Next Beats (next-beats.dev), un lecteur de musique dont le code est publié sous licence MIT dans le dépôt vercel-labs/next-beats. Cache Components y est activé, Stream et Cache sont utilisés par route pour que chaque navigation atterrisse sur un vrai squelette plutôt qu’un spinner, et Partial Prefetching est actif pour un squelette réutilisable par route. Le résultat, selon la description officielle, ce sont des navigations qui se ressentent comme dans une SPA. C’est le meilleur bac à sable pour voir la nouveauté en conditions réelles avant de l’envisager sur un projet.

Une preview, avec ses zones d’ombre assumées

Il serait malhonnête de présenter cette version comme prête. Vercel liste lui-même des problèmes connus à corriger avant le stable. Quand Partial Prefetching est actif, accéder aux paramètres d’une route dans un squelette fait bloquer la route sans que Instant Insights ne la remonte (le Navigation Inspector et le helper instant() ne sont pas affectés). L’outillage Instant Insights connaît par ailleurs des soucis sous Safari, et Vercel recommande Chrome ou Firefox en développement. Ces réserves ne sont pas des détails : elles confirment que la preview est faite pour récolter du feedback, via une discussion GitHub dédiée ouverte par l’éditeur, avant un stable attendu dans les prochaines semaines.

Pour une équipe qui construit déjà sur Next.js 16, la lecture utile est double. La direction est claire et cohérente : récupérer le ressenti instantané des SPA en React sans renoncer au modèle serveur, avec un contrôle route par route, des diagnostics intégrés et un prefetching plus sobre. Mais la maturité, elle, n’y est pas encore. On installe la preview pour comprendre, on l’évalue sur une démo comme Next Beats ou un projet interne sans utilisateurs réels, et on attend le stable pour la prod. C’est précisément le genre de veille que notre agence intègre dans la maintenance et l’évolution des applications qu’elle suit : tester tôt, sans précipiter en production une brique annoncée comme changeante.

Pour aller plus loin

• Développement Next.js : concevoir et faire évoluer des applications sur le framework, en suivant ses nouveautés de près.
• Développement React : la bibliothèque sur laquelle repose Next.js, au cœur du ressenti côté navigateur.
• Audit et cadrage : la porte d’entrée pour évaluer une nouveauté technique avant de l’intégrer en production.
• Cloud et DevOps : l’infrastructure, le build et le déploiement qui encadrent une mise en production sereine.
• Maintenance et TMA : faire vivre une application dans la durée, mises à jour de framework comprises.

Sources

Toutes les sources de cet article proviennent du même éditeur, Vercel, qui édite Next.js : annonce officielle, documentation, dépôt de la démo et discussion de feedback relèvent d’une seule et même origine. Pour une annonce d’éditeur sur sa propre fonctionnalité en preview, cette source primaire fait référence, mais elle reste unique. À la date de rédaction (26 juin 2026, lendemain de l’annonce), aucune publication tech indépendante n’avait encore recoupé l’actualité ; chaque nom d’API, chaque flag et chaque comportement décrit ici est donc attribué explicitement à Vercel et a été vérifié directement sur l’annonce et la documentation officielles le 26 juin 2026. Le lecteur doit lire ce qui suit comme la présentation d’une preview par son éditeur, pas comme un retour d’expérience indépendant.

• Next.js 16.3: Instant Navigations, annonce officielle (Vercel)
• cacheComponents, documentation de configuration (Next.js)
• Prefetching, guide officiel (Next.js)
• vercel-labs/next-beats, démo open-source de la preview 16.3 (Vercel)
• Discussion de feedback de la preview 16.3 (#95130, dépôt officiel Next.js)
• Next.js 16, contexte de version : Cache Components et use cache (Vercel)