La préversion du framework open source de développement web full-stack Next.js 16.3 est disponible, et ajoute la navigation instantanée et le préchargement partiel 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 par défaut par Next.js.
Au lieu d’envoyer une requête de préchargement pour chaque lien, Next.js ne précharge désormais qu’un « shell » réutilisable par route distincte dans la fenêtre d’affichage (un pour la page « Chat », un pour la page « Paramètres », etc.), et les met en cache pendant toute la durée de la session.
Cependant, il arrive parfois que vous souhaitiez précharger davantage que la structure de base. Par exemple, vous pourriez vouloir qu’un en-tête de chat « s’affiche » instantanément sur une page de chat. Pour activer le préchargement par lien, vous pouvez ajouter <Link prefetch={true}> à certains liens.
Notez que même dans ce cas, Next.js ne tentera pas de rendre l’intégralité de la route jusqu’au plus profond. Au lieu de cela, il se contentera de rendre ce qui est disponible de manière synchrone ou marqué avec [B]'use cache'[/c]. Cela signifie que vous n’avez plus à faire un choix « tout ou rien » en matière de préchargement. Le shell instantané vous fournit la base, puis <Link prefetch={true}> associé à 'use cache' vous permet d’ajouter un préchargement supplémentaire par lien pouvant inclure davantage de contenu.
Afin de limiter les coûts, le préchargement par lien est restreint au contenu connu au moment de la compilation. Si la charge supplémentaire sur le serveur ne vous dérange pas, export const prefetch = 'allow-runtime' étend cette fonctionnalité au contenu mis en cache au moment de la requête.
Nous l’utilisons nous-mêmes
Nous avons adopté ces outils sur la version v0 avant même cette mise à jour. La version v0 propose de nombreuses fonctionnalités client avancées, mais la navigation ne donnait pas l’impression d’être instantanée depuis un certain temps.
Instant Insights nous a indiqué les routes qui ne s’affichaient pas instantanément. Voici comment la navigation s’est accélérée une fois que nous avons commencé à mettre en œuvre les corrections :
Nous partagerons les modèles spécifiques que nous avons retenus dans un prochain article. Nous continuons également à optimiser les améliorations de préchargement décrites plus haut ; nous nous attendons donc à ce que ces chiffres se rapprochent de zéro.
Une démo à explorer
Si vous souhaitez découvrir ces fonctionnalités dans une base de code open source plus concise, Next Beats est un lecteur de musique construit sur la préversion de Next.js 16.3, dont le code source est disponible sur GitHub. La fonctionnalité « Cache Components » est activée ; ainsi, « Stream » et « Cache » sont utilisés pour chaque route, ce qui permet à chaque navigation d’aboutir à un véritable shell plutôt qu’à un indicateur de chargement. Le préchargement partiel est activé, de sorte que chaque route précharge un seul shell réutilisable côté client. Il en résulte des navigations qui semblent instantanées, à l’instar d’une application monopage.
Récapitulatif
En résumé, nous avons travaillé pour permettre à votre application de bénéficier de navigations instantanées similaires à celles d’une SPA :
- Si vous diffusez avec <Suspense> ou Cache avec 'use cache', les navigations vers votre route seront instantanées.
- Si vous bloquez la fonctionnalité via export const instant = false, vous désactivez l’application des navigations instantanées vers cette route.
- Next.js génère automatiquement une coque réutilisable pour chaque route instantanée, et ne la précharge qu’une seule fois.
- Vous pouvez utiliser l’aide au test instant() pour éviter les régressions, et Navigation Inspector pour inspecter visuellement les coques.
- Vous pouvez activer une préchargement plus approfondi au niveau de chaque lien avec <Link prefetch> et 'use cache'.
Ces modifications sont activées via les indicateurs cacheComponents: true et partialPrefetching: true.
Grâce à ces modifications, nous rendons l’expérience de navigation au premier clic de Next.js aussi fluide que dans les applications monopages, sans pour autant renoncer aux avantages du modèle mental centré sur le serveur et aux performances globales qu’il permet.
Problèmes connus
La version Preview présente des problèmes connus sur lesquels nous travaillons activement. Ceux-ci seront corrigés avant la sortie de notre version stable.
- Dans certains cas, un blocage de route n’est pas signalé en tant qu’« Instant Insight ». Lorsque la prélecture partielle est activée, l’accès aux paramètres à l’intérieur d’un shell provoque le blocage d’une route, mais cela n’est pas signalé en tant qu’« Instant Insight ». L’Inspecteur de navigation et l’assistant de test instant() ne sont pas affectés.
- L’outil Instant Insights présente quelques problèmes sous Safari. En phase de développement, utilisez Chrome ou Firefox pour obtenir les meilleurs résultats.
Source : Annonce préversion Next.js 16.3
Et vous ?
Pensez-vous que cette annonce est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
Next.js 16.2 est lancé avec un rendu et un démarrage plus rapides, une page d'erreur repensée, une mise à jour majeure garantissant un taux de réussite de 100 % pour les agents IA Next.js 16.1, le framework open source de développement web full-stack, est désormais disponible avec la mise en cache du système de fichiers Turbopack, un analyseur de bundle Next.js et bien plus encore
Vous avez lu gratuitement 1 826 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.