Next.js 16.3 sur Vercel : assets immuables, routing 2x plus rapide et nouvelle observabilité PPR

Next.js 16.3 et Vercel : ce qui est propre au framework, ce qui ne l'est pas

Après notre article sur Next.js 16.3, Vercel a publié son propre post pour détailler comment sa plateforme a été adaptée à cette version. Pour une agence, ce texte est presque plus utile que l'annonce officielle du framework : il permet de trier ce qui est un vrai gain Next.js — donc disponible peu importe l'hébergeur — de ce qui est un bonus propre à l'infrastructure Vercel.

C'est une distinction qui compte concrètement si vos projets tournent sur un VPS Docker plutôt que sur la plateforme de l'éditeur du framework.

Les chiffres annoncés

Sur les applications ayant migré de la 16.2 à la 16.3 :

• Moins de requêtes de prefetch : −45 % en moyenne, jusqu'à −70 % sur certains projets
• Assets statiques moins coûteux : −17 % de requêtes CDN, −24 % de bytes transférés, jusqu'à −60 % de TTFB global sur les projets déployés fréquemment
• Routing ~2x plus rapide en p99 sur les gros sites, avec ~10x moins de cache miss côté metadata

Ce qui vient du framework — portable, peu importe l'hébergeur

La baisse des requêtes de prefetch (−45 %) est un comportement de Next.js lui-même : le framework regroupe désormais les petits payloads de prefetch avant de les envoyer, comme on l'a détaillé dans notre article sur la 16.3. Ce gain-là s'applique sur n'importe quel hébergeur qui sert correctement une app Next.js — OVH, Hostinger, un VPS Docker, peu importe.

Ce qui vient de la plateforme Vercel — spécifique à leur CDN

Les deux autres chiffres sont d'une autre nature : ils dépendent de l'infrastructure Vercel, pas du code Next.js.

Les assets statiques immuables s'appuient sur le CDN de Vercel, qui reconnaît le préfixe /_next/static/immutable/* et réutilise ces fichiers d'un déploiement à l'autre, sans passer par le système de Skew Protection basé sur des query params (?dpl=). Résultat : moins de requêtes CDN redondantes, un cache navigateur qui survit aux redéploiements, et des déploiements jusqu'à 30 % plus rapides puisque les assets inchangés sautent le re-upload. Sur un hébergement générique (Nginx + Docker par exemple), ce mécanisme n'existe pas nativement — il faudrait le recréer à la main via des règles de cache-control et un système de content-addressing des assets.

Le gain de routing (~2x plus rapide au p99, ~10x moins de cache miss) vient d'une réécriture de la couche de résolution de métadonnées côté CDN Vercel : au lieu d'une entrée de cache par segment, les métadonnées sont désormais regroupées en shards au format JSONL, ce qui améliore le taux de hit sans ralentir la recherche dans un shard. C'est un changement d'infrastructure pure — il bénéficie à tous les frameworks qui passent par la Build Output API de Vercel, mais reste propre à leur plateforme. Sur un déploiement self-hosted classique avec next start, ce goulot d'étranglement spécifique n'existe pas de la même façon, mais vous n'avez pas non plus ce niveau d'edge caching par défaut.

Ce que ça implique pour vos choix d'hébergement

Ce n'est pas un argument pour migrer vers Vercel, c'est un rappel utile pour évaluer objectivement leur communication. Une partie réelle des chiffres avancés n'est pas transférable à un déploiement self-hosted, aussi bien configuré soit-il. Si un client vous demande "pourquoi pas Vercel plutôt que notre VPS actuel", ces chiffres sont un bon point de départ pour la discussion — à condition de préciser lesquels s'appliquent réellement à son cas d'usage.

À l'inverse, sur les projets où l'infrastructure Vercel n'est pas envisagée (souveraineté des données, budget, ou simplement préférence pour un stack maîtrisé de bout en bout), le vrai gain de la 16.3 reste celui qu'on a couvert dans notre premier article : la mémoire en dev, les builds plus rapides, et le prefetching plus léger. Tout ça est indépendant de l'hébergeur.

Observabilité : utile en reporting client, si vous êtes chez Vercel

Vercel ajoute une page d'observabilité dédiée au Partial Prerendering (PPR), qui distingue visuellement les requêtes servant du contenu statique, dynamique, ou un mix des deux. L'observabilité ISR est également enrichie (raisons de revalidation, taux d'écriture), et le filtrage des requêtes de prefetch devient possible dans les Runtime Logs.

Pour une agence qui héberge chez eux et doit justifier des choix d'architecture face à un client technique, ce sont des outils de reporting concrets, plus faciles à montrer qu'à expliquer à l'oral. Mais ils ne se substituent à rien côté self-hosted : si vous gérez votre propre stack d'observabilité (Metabase, Grafana, logs custom), il faudra continuer à instrumenter vous-même ces métriques.