La préversion de Next.js 16.3 est disponible et introduit les « Instant Navigations » (navigation instantanée), permettant aux applications pilotées par le serveur d’offrir des transitions de page instantanées, à l’instar des SPA. Cette version inaugure également le préchargement partiel, qui récupère et met en cache des structures de page réutilisables par route, réduisant ainsi les requêtes réseau redondantes.Next.js est un framework open source de développement web full-stack créé par la société privée Vercel, qui permet de développer des applications web basées sur React avec rendu côté serveur et rendu statique. La documentation de React mentionne Next.js parmi les « chaînes d’outils recommandées », le conseillant aux développeurs lorsqu’ils « créent un site web avec rendu côté serveur à l’aide de Node.js ». Alors que les applications React traditionnelles ne peuvent afficher leur contenu que côté client dans le navigateur, Next.js étend cette fonctionnalité aux applications rendues côté serveur.
La préversion de Next.js 16.3 est disponible et introduit les « Instant Navigations » (navigation instantanée), permettant aux applications pilotées par le serveur d’offrir des transitions de page instantanées, à l’instar des SPA. Cette version inaugure également le préchargement partiel, qui récupère et met en cache des structures de page réutilisables par route, réduisant ainsi les requêtes réseau redondantes. Les développeurs doivent activer l’indicateur « Cache Components » pour utiliser ces fonctionnalités et peuvent choisir entre le streaming, la mise en cache ou le blocage des récupérations de données côté serveur pour chaque navigation.
En février, un ingénieur et un modèle d'IA ont reconstruit de zéro le framework Next.js avec l'IA en une semaine. Le résultat, vinext (prononcé « vee-next »), est un remplacement direct de Next.js, construit sur Vite, qui se déploie sur Cloudflare Workers à l'aide d'une seule commande. Lors des premiers benchmarks, il construit des applications de production jusqu'à 4 fois plus rapidement et produit des bundles clients jusqu'à 57 % plus petits.
Voici l'annonce de la préversion Next.js 16.3 :
Présentation de Next.js 16.3 : Navigations instantanées
Next.js 16.3 est sur le point d’arriver, et il regorge d’une multitude d’améliorations : un meilleur rendu sous charge grâce aux flux natifs de Node.js, des temps de démarrage plus rapides en développement local, et une intégration plus poussée avec les workflows basés sur des agents.
Nous aborderons ces fonctionnalités dans les semaines à venir, alors que nous préparons une version stable. Mais aujourd’hui, nous souhaitons nous concentrer sur une nouvelle fonctionnalité que nous appelons « Navigations instantanées » : une suite d’outils qui apporte à Next.js la réactivité des SPA pilotées par le client, sans sacrifier les avantages liés à son modèle piloté par le serveur.
Voyons comment cette fonctionnalité répond à la critique de longue date (et justifiée !) selon laquelle les composants serveur peuvent donner l’impression que les applications sont peu réactives.
Navigations instantanées
L’une des frustrations les plus courantes que l’on entend à propos des applications Next.js est que les navigations semblent lentes.
Dans une application pilotée par le serveur, la navigation nécessite généralement un aller-retour réseau :
1. Vous cliquez sur un lien.
2. Il ne se passe rien.
3. Puis le serveur répond, et la page suivante s’affiche.
Ce n’est pas nécessairement un inconvénient, et cela peut très bien fonctionner pour les sites web axés sur le contenu, comme les journaux et les blogs. Mais cela donne à l’expérience un aspect « typique d’un site web ». Ce n’est pas assez réactif. Comparons cela à la façon dont les applications pilotées par le client gèrent la navigation :
1. Vous cliquez sur un lien.
2. Instantanément, vous voyez apparaître une ébauche de la page suivante (certaines données étant encore en cours de chargement).
3. Puis le serveur répond, et la page suivante s’affiche dans son intégralité.
C’est l’une des raisons courantes pour lesquelles de nombreux développeurs préfèrent créer des SPA (applications monopages). Même si le paradigme requête/réponse piloté par le serveur présente de nombreux avantages, les navigations instantanées restent plus agréables pour de nombreux types d’applications.
Nous corrigeons cela
Nous avons bien entendu vos retours à ce sujet.
Dans Next.js 16.3, nous proposons de nouveaux comportements optionnels qui vous permettent de profiter du meilleur des deux mondes : des applications pilotées par le serveur avec des navigations instantanées. Vous bénéficiez de tous les avantages d’un serveur, mais les navigations sont instantanées, comme dans une application monopage.
Voyons comment cela fonctionne.
Tout d’abord, activez « Cache Components »
Pour tester ces nouveaux comportements, activez l’option « Cache Components » :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | import type { NextConfig } from 'next'; const nextConfig: NextConfig = { cacheComponents: true, // ... }; export default nextConfig; |
Au cours de l’année écoulée, nous avons simplifié Next.js pour revenir à ses fondamentaux : dynamique par défaut, sans mise en cache cachée ou implicite. Ce drapeau active ces nouveaux comportements et deviendra la valeur par défaut dans une future version majeure de Next.js.
Stream, Cache ou Block
Désormais, lorsqu’une route attend des données sur le serveur, plusieurs options s’offrent à vous :
Que signifient ces options ?
Pour rendre la navigation instantanée, vous « transformez » une opération asynchrone en quelque chose qui peut être disponible immédiatement :
- Diffusion avec <Suspense>. L'utilisateur verra immédiatement un état de chargement (suivi de la diffusion progressive de l'interface utilisateur).
- Mise en cache avec 'use cache'. L'utilisateur verra immédiatement une interface utilisateur précédemment mise en cache (réutilisée entre les requêtes).
Dans les deux cas ci-dessus, la navigation donnera à l’utilisateur l’impression d’être une application monopage (SPA) et sera instantanée.
Cependant, vous pouvez parfois souhaiter que certaines navigations dépendent du serveur. Par exemple, un blog peut choisir de ne jamais afficher de fenêtre de chargement pour les articles. Dans ces cas-là, vous pouvez indiquer à Next.js que vous souhaitez que cette navigation soit bloquée :
| Code : | Sélectionner tout |
1 2 | // in page.tsx or layout.jsx export const instant = false; |
La boîte de dialogue d’erreur disparaîtra alors.
Remarquez comment cela vous donne le contrôle. Si vous souhaitez que votre application pilotée par le serveur réagisse instantanément aux clics sur les liens — sans attendre la réponse du réseau —, utilisez alors « Stream » ou « Cache ». Si vous souhaitez que certaines routes retardent les navigations, utilisez « Block ».
Pour en savoir plus sur l’intégration d’Instant Insights aux agents de codage, consultez Next.js 16.3 : Améliorations de l’IA.
Préserver l’instantanéité des navigations
Avec Instant Insights, nous avons fait des navigations lentes une erreur en phase de développement. Pour détecter plus facilement les régressions affectant vos routes instantanées après des modifications et des refactorisations, nous avons également fourni une aide au test instantané pour les tests Playwright :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | import { expect, test } from '@playwright/test'; import { instant } from '@next/playwright'; test('product title is available immediately', async ({ page }) => { await page.goto('/products/shoes'); // Assert what's visible without waiting for network await instant(page, async () => { await page.click('a[href="/products/hats"]'); await expect(page.locator('h1')).toContainText('Baseball Cap'); await expect(page.getByText('Checking inventory...')).toBeVisible(); }); await expect(page.getByText('12 in stock')).toBeVisible(); }); |
Cela vous permet (ou permet à votre agent) de vérifier de manière plus granulaire ce qui doit être instantanément visible après chaque clic sur un lien.
Nous explorons également des moyens de faire remonter les erreurs que vous constatez en développement pendant le processus de compilation, afin que toute régression dans vos routes instantanées soit détectée dès la compilation.
Repenser le préchargement
Pour que les navigations soient véritablement instantanées (à l’instar des SPA), nous avons dû combler deux lacunes distinctes :
- Le client doit communiquer avec le serveur. Cela peut être lent s’il y a une latence élevée entre eux.
- De plus, le serveur doit générer une réponse. Cela peut être lent si le code du serveur est lent.
En diffusant la réponse en continu ou en la mettant en cache, nous éliminons la deuxième lacune : le serveur lui-même ne bloque pas. Mais il subsiste un écart entre le client et le serveur. Comment Next.js pouvait-il « connaître » la réponse instantanément au moment où l’utilisateur cliquait ?
Auparavant, Next.js résolvait ce problème en envoyant une requête de préchargement au serveur pour chaque lien présent dans la fenêtre d’affichage. Si vous avez prêté attention à l’onglet « Réseau » en mode production, vous avez peut-être remarqué une rafale de requêtes lors du défilement :
Vous avez été nombreux à nous dire que cela semblait ridicule, et franchement, nous sommes d’accord.
Nous avons réfléchi à la manière dont les applications monopages résolvent ce problème. Une application monopage est capable de répondre instantanément à chaque navigation, car elle regroupe tout le code nécessaire à l’affichage de la page suivante et l’envoie au client. Elle peut encore avoir besoin de données supplémentaires — ce qui explique qu’un clic n’affiche pas immédiatement la page complète — mais cela suffit pour afficher une « coque » de la page.
Nous avons donc décidé d’emprunter cette astuce aux applications monopages. Au lieu de précharger une page par lien, Next.js va désormais précharger une coque réutilisable par route. Ces coques seront ensuite mises en cache côté client afin de n’être récupérées qu’une seule fois.
Par exemple, si vous aviez une barre latérale comportant vingt liens de chat, Next.js envoyait auparavant une requête de préchargement distincte pour chaque lien. Cependant, avec ce nouveau comportement, il n’effectuera qu’un seul préchargement par route : une structure pour la route /chat/[id], une structure pour la route /dashboard, et ainsi de suite. Conceptuellement, cela s’apparente à la manière dont les applications monopages téléchargent le code grâce au fractionnement du code par route.
Comme les shells sont réutilisés d’un lien à l’autre, ils constituent également la base de la navigation hors ligne. Dans une prochaine version, nous explorerons comment les routes préchargées pourraient rester navigables en cas de coupure momentanée du réseau.
Activation du Partial Prefetching (préchargement partiel)
Pour tester ce nouveau comportement de préchargement, que nous appelons « préchargement partiel », activez-le dans votre configuration Next.js :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | import type { NextConfig } from 'next'; const nextConfig: NextConfig = { cacheComponents: true, partialPrefetching: true, // ... }; export default nextConfig; |
Comme pour cacheComponents, nous prévoyons de faire de partialPrefetching le comportement par défaut dans une future version majeure.
Inspection du shell de chargement
Pour rendre cela plus concret, nous avons ajouté un nouvel « Navigation Inspector » aux DevTools de Next.js.
Il vous permet de mettre en pause chaque navigation au niveau de la coque afin de voir ce qui est préchargé pour chaque route :
Ensuite, lorsque vous cliquez sur « Reprendre », la navigation affiche la page complète. Cela vous permet de voir, pendant le développement, quelle partie de votre route peut s’afficher instantanément, et laquelle ne peut s’afficher qu’après la connexion au réseau.
Comme auparavant, le préchargement proprement dit n’est activé qu’en production.
Préchargement au-delà d’un simple « shell »
Avec l’option préchargement partiel activée, nous avons réduit le volume de données préchargées...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.