Tous les articles
Carnet de bord

Next.js 16.3 : ce qui change vraiment pour votre site

Roméo

Roméo · Fondateur

8 min de lecture

Next.js 16.3 : ce qui change vraiment pour votre site#

Next.js 16.3 est sorti lundi. C'est le socle sur lequel on code la plupart des boutiques et des tableaux de bord qu'on livre.

Normalement, une mise à jour de framework ne regarde que les développeurs. Celle-là mérite dix minutes de votre attention, parce qu'une bonne partie des gains arrive chez vous sans qu'une ligne de votre code ne bouge. Le reste demande du travail, et on va vous dire lequel.

Ce qui arrive sans rien changer#

Votre serveur encaisse 22 % de requêtes en plus#

Pendant qu'il fabrique vos pages, Next.js passait son temps à convertir des flux de données d'un format à un autre. Cette conversion a sauté. À machine égale, sans toucher au code, l'équipe Next.js mesure jusqu'à 22 % de requêtes traitées en plus sous charge.

Traduit dans votre quotidien : le matin où votre newsletter part, où un article vous cite, où votre promotion démarre, votre site tient plus longtemps avant de fléchir. C'est exactement le genre de marge qui décide si un pic de trafic devient un bon souvenir ou une capture d'écran d'erreur.

Moins de données transférées, une facture qui suit#

Deux changements travaillent ensemble. Les préchargements de petite taille sont désormais regroupés au lieu de partir un par un, et les fichiers qui ne changent jamais sont réutilisés d'une mise en ligne à l'autre au lieu d'être renvoyés.

Sur les applications déjà passées en 16.3, Vercel mesure 45 % de requêtes de préchargement en moins, 17 % de requêtes en moins sur son réseau de diffusion et 24 % de données transférées en moins pour les fichiers statiques.

Pour vous, ça donne deux choses concrètes : une facture d'hébergement qui baisse, et des pages qui apparaissent plus vite chez un visiteur en 4G moyenne dans le train. Le deuxième point compte plus que le premier.

Un bloc qui plante n'emporte plus la page#

Jusqu'ici, une portion de page qui échouait pouvait faire tomber l'affichage entier. 16.3 permet de définir un encadré de secours qui propose de réessayer, et de ne recharger que la partie concernée.

Dit autrement : votre module « disponible en boutique » qui ne répond pas n'empêche plus d'afficher la fiche produit et son bouton d'achat. Le client voit un petit encart au lieu d'une page d'erreur, et il commande quand même.

Les sites multilingues perdent de la plomberie#

La langue de la page peut maintenant être lue depuis n'importe où dans le code, au lieu d'être passée de main en main jusqu'au dernier composant. Sur une boutique en trois langues comme celle qu'on monte en ce moment pour une boulangerie française de l'Illinois, ça retire des dizaines d'endroits où une erreur pouvait se glisser.

Moins de plomberie, moins de casse. C'est rarement spectaculaire et c'est toujours rentable.

Les gains qui sont pour nous, pas pour vous#

La grosse annonce de cette version, c'est la mémoire : le serveur de développement consomme jusqu'à 90 % de RAM en moins sur les longues sessions. S'y ajoutent des compilations jusqu'à 5,5 fois plus rapides sur certains projets grâce à un cache conservé sur le disque, et une vérification de types accélérée avec TypeScript 7.

Ces chiffres tournent partout en ce moment. Soyons clairs : ils ne changent rien à votre site. Ils changent nos machines et nos journées, donc un peu nos délais, et c'est tout.

On préfère vous le dire plutôt que de vous vendre 90 % de quelque chose que vous ne verrez jamais.

Ce qui demande un vrai chantier : les navigations instantanées#

Voilà la vraie nouveauté de la version, et la seule qui ne s'obtient pas gratuitement.

Aujourd'hui, quand un visiteur clique sur un lien de votre site, il attend le serveur avant de voir quoi que ce soit bouger. Une seconde de rien. Sur un site vitrine, personne ne le remarque. Sur un tableau de bord, un catalogue de 700 produits ou un configurateur, c'est la sensation qui fait dire « c'est lent » alors que tout va bien techniquement.

Next.js 16.3 sait maintenant extraire de chaque page la partie affichable sans attendre les données, la charger d'avance, et la poser à l'écran dès le clic. Les données arrivent derrière, dans un cadre déjà dessiné. La sensation devient celle d'une application, pas d'un site.

Trois choses à savoir avant de vous emballer :

  1. Ça s'active avec deux réglages, mais ça se gagne avec une migration. Sur une boutique déjà en production, il faut revoir la façon dont chaque page réclame ses données.
  2. L'outillage fourni est sérieux. Un panneau signale les navigations qui ne sont pas instantanées, un inspecteur permet de voir exactement ce que le visiteur a sous les yeux pendant le chargement, et un utilitaire de test empêche qu'une évolution future casse le travail sans que personne ne s'en aperçoive.
  3. Ces comportements deviendront la norme dans une version majeure à venir. Ce n'est pas une option de plus, c'est la direction du framework.

Notre position : on l'active là où ça se voit, et on la laisse de côté sur un site de six pages où elle ne rapporterait rien. Sur un projet en production, ça se prépare, ça se teste, et ça se déploie un mardi matin.

Si vous ne retenez qu'une chose : la mise à jour, c'est une commande et une série de tests. Les navigations instantanées, c'est un chantier, et il est optionnel. Ne laissez pas le second retarder le premier.

Un chiffre à ne pas mal lire#

Vous verrez passer « jusqu'à 60 % de temps de réponse en moins ». Ce chiffre ne vient pas du framework, il vient de la plateforme d'hébergement Vercel, il concerne les fichiers statiques, et il ne s'applique qu'aux projets remis en ligne souvent.

Même chose pour la résolution des routes environ deux fois plus rapide : c'est un gain de plateforme, mesuré sur de gros sites.

Si votre site est hébergé ailleurs, vous récupérez tous les gains du framework et aucun de ceux-là. La règle chez nous est simple : quand un chiffre vient de l'hébergeur et pas du code, on le dit.

Faut-il mettre à jour maintenant ?#

Votre situationCe qu'on ferait
Un site en production, du trafic régulier, rien qui coinceLa mise à jour maintenant, sans toucher aux navigations instantanées
Un site qui plie à chaque pic de traficLa mise à jour en priorité, les 22 % vous concernent directement
Un tableau de bord ou un catalogue que vos clients trouvent lent au clicLa mise à jour, puis un vrai chantier navigations instantanées
Un projet qui démarreOn part directement en 16.3, réglages compris, c'est le bon moment
Une application restée sur une version antérieure à Next.js 16La montée de version d'abord, le reste ensuite
Un site sur Shopify ou WordPressRien à faire, ça ne vous concerne pas

Ce qu'on en fait chez nous#

On passe nos projets en cours cette semaine. Pour les clients dont on a construit la boutique, la mise à jour prend une matinée sur un projet déjà en Next.js 16, tests de non-régression compris.

C'est aussi ça, choisir des fondations : le jour où l'écosystème avance, vous avancez avec lui, sans redévelopper quoi que ce soit. Une boutique en ligne n'est pas une affiche qu'on colle et qu'on oublie, c'est une structure que vous habitez pendant des années.

Vous ne savez pas sur quelle version tourne votre site, ni ce que vous laissez sur la table ? Dites-nous en deux mots ce que vous avez en tête, on regarde et on vous répond franchement, y compris si la réponse est « ne touchez à rien ».

Parlons de votre projet

Questions fréquentes#

Partager

Commentaires

Aucun commentaire pour l'instant. Lancez la discussion.