Next.js 15.1+ est pratiquement inutilisable hors de l’environnement Vercel

• À partir de Next.js 15.1.8, la manière de traiter les métadonnées a changé, provoquant de graves problèmes dans les environnements de déploiement autres que Vercel
  • Les métadonnées ne sont plus rendues directement dans le head HTML, mais envoyées séparément via un mécanisme appelé « metadata streaming »
• Si les moteurs de recherche n’exécutent pas JavaScript, les métadonnées ne sont tout simplement pas exposées, ce qui détruit gravement le SEO
  • Un traitement d’exception existe via la détection de crawlers (htmlLimitedBots), mais il n’est pas parfait
• Les environnements non-Vercel comme Netlify, Cloudflare ou AWS tentent d’assurer la compatibilité via OpenNext, mais en pratique Next.js est trop fortement lié à l’infrastructure de Vercel, ce qui rend le portage difficile et très bogué
• Même les builds statiques n’incluent pas les métadonnées dans le head HTML, et tous les environnements de déploiement se retrouvent contraints à gérer une détection complexe des crawlers et/ou l’exécution de JS
• Problème de sécurité (faille critique rendue publique en mars 2025)
  • S’en tenir à une ancienne version pour éviter le metadata streaming expose à une grave vulnérabilité de sécurité (le correctif n’est disponible qu’à partir de la 15.2.3)
• Le metadata streaming masque en réalité des problèmes de performance de page et a aussi un impact négatif sur le SEO
• Conclusion :
  Next.js donne l’apparence de l’open source, mais est devenu dans les faits un framework avec une dépendance très forte à Vercel ; pour les nouveaux projets, mieux vaut envisager d’autres options

---

Vue d’ensemble

• À partir de la version 15.1.8 de Next.js, de graves problèmes apparaissent dans la gestion des métadonnées hors de Vercel
• Cela entraîne un renforcement structurel de la dépendance à l’infrastructure Vercel, une dégradation du référencement naturel (SEO), et même des risques de sécurité

Début du problème : l’introduction du metadata streaming

• En 2024, Vercel a introduit une fonctionnalité expérimentale appelée metadata streaming
• Contrairement à l’approche précédente, les métadonnées (balises comme title, description, Open Graph, etc.) ne sont plus rendues directement dans le `` HTML, mais envoyées séparément après le chargement initial de la page
• Cette fonctionnalité nécessite donc l’exécution de JavaScript

Explication technique de Vercel et problèmes concrets

• Motif de l’introduction : résoudre un goulot d’étranglement de calcul lors de la génération des métadonnées
• Mais en pratique, les métadonnées sont le plus souvent statiques et très légères (moins de 1 Ko)
• Le coût d’un aller-retour serveur est supérieur à un traitement inline
• Les métadonnées dynamiques ne représentent que quelques cas exceptionnels
• La complexité de mise en œuvre du metadata streaming ne fait qu’ajouter de la confusion

Contexte des problèmes de performance

• Certains développeurs ont rencontré des problèmes de performance liés à la latence de génération des métadonnées, par exemple lors d’intégrations avec des API externes
• Pour y répondre, Vercel a développé une approche par streaming

Crawlers des moteurs de recherche et impact SEO

• Les moteurs de recherche qui n’exécutent pas JavaScript ne peuvent pas lire les métadonnées
• Cela a donc un effet très négatif sur le SEO
• Comme solution, Vercel fournit la fonctionnalité htmlLimitedBots, qui permet au serveur, lorsqu’il détecte un crawler, d’ignorer le streaming et d’injecter les métadonnées dans le HEAD

Limites des autres fournisseurs cloud

• Netlify, Cloudflare et AWS ont aussi créé un projet d’adaptateur appelé OpenNext pour assurer la compatibilité avec Next.js
• Mais comme Next.js est trop étroitement dépendant de Vercel, le portage nécessite de la rétro-ingénierie
• En raison de problèmes de qualité d’OpenNext, l’ensemble ne fonctionne pas correctement en pratique

Même les builds statiques sont incomplets

• Même en build de site statique (Static Build), les métadonnées ne sont plus incluses dans le head HTML
• Comme elles sont regroupées avec les React Server Components, l’exécution de JavaScript est nécessaire
• On se retrouve même à devoir implémenter soi-même une logique de détection de crawler juste pour obtenir des métadonnées HTML de base

Grave vulnérabilité de sécurité et problème de mise à jour

• Le 21 mars 2025, une vulnérabilité critique (score de sécurité 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) a été rendue publique
• Cette faille permet de contourner la sécurité d’authentification du middleware via la manipulation de certains headers
• Le correctif a été appliqué dans Next.js 15.2.3, mais rester en 15.1.8 pour éviter le metadata streaming rend le système très vulnérable

Conséquences négatives de l’introduction du streaming

• Le metadata streaming masque encore davantage des problèmes de performance cachés
• En cas de latence dans le traitement des métadonnées de page, les utilisateurs réels ne s’en rendent pas compte
• Les crawlers des moteurs de recherche, eux, peuvent infliger une pénalité SEO en raison de réponses trop lentes

Conclusion

• Next.js s’est transformé en vendor lock-in Vercel déguisé en framework open source
• Pour le choix de la stack technique d’un prochain projet, il est plus judicieux d’envisager d’autres frameworks que Next.js

[kansm]

Remix devient alors une alternative, non ?

[bth15923]

Comme mentionné dans le corps de l’article, il y a un verrouillage fournisseur excessif, des comportements beaucoup trop opaques, et des API peu intuitives. En plus, du côté de React aussi, ils font ouvertement la promotion de ce type de développement avec rendu côté serveur comme si c’était la méthode de développement standard de React. Je pense que, pour la plupart des applications, une SPA basée sur Vite suffit largement.

[pcj9024]

J’admets qu’un certain niveau de vendor lock-in puisse se produire, mais à regarder les avis sur la technologie Next.js elle-même, on a juste l’impression qu’ils ne dépassent pas le niveau de « je n’ai pas envie de lire l’article ».

[ndrgrd]

Depuis le début, ils faisaient semblant de rester ouverts tout en avançant de façon fermée, et au final ils ont presque complètement verrouillé la porte.

[GN⁺]

Avis sur Hacker News

• Je ne recommanderais absolument pas d’utiliser Next. L’expérience développeur est horrible, le vendor lock-in est fort, et à cause de conventions étranges non documentées, on a l’impression qu’à moins de faire un simple SaaS B2B centré sur du CRUD, il y a des mines partout. J’ai notamment vu un cas où la balise Next <Image /> faisait tomber les FPS d’une scène WebGL sur la même page jusqu’à 2

  • Je me demande comment Vercel a réussi à faire entrer lentement les utilisateurs React dans un vendor lock-in. React était un projet porté par Meta avec un fort accent sur l’open source, et j’espérais que l’open source servirait justement à éviter ce genre de dépendance, donc c’est décevant de voir que ce n’est pas le cas

  • Entièrement d’accord. J’ai réutilisé Next récemment après longtemps, et l’expérience de développement a été très décevante. La documentation était floue et difficile à trouver, et l’application donnait globalement une impression de lenteur par défaut. En essayant de déployer sur AWS avec Docker, j’ai eu d’innombrables difficultés à cause du Dockerfile d’exemple fourni par Vercel

  • Je me demande si vous avez analysé directement le problème de <Image /> ou si vous supposez simplement que c’est un problème de NextJs. Je travaille avec la combinaison NextJs, <Image> et RTF, mais je n’ai jamais rencontré ce genre de souci

• J’utilise Next.js au travail depuis 3 ans, et c’est vraiment douloureux. On l’héberge sur Vercel, et l’entreprise a adopté presque tous les services de Vercel, donc on vit un vrai vendor lock-in. J’avais partagé une mauvaise expérience sur un post HN que Dan avait publié au sujet de RSC, et j’ai trouvé ses remarques très justes. Quand il dit que « RSC en lui-même est désormais assez solide, mais que des frameworks comme Next.js restent encore assez rugueux », ça résume bien la situation. Globalement, React est désormais lui aussi en dessous de la moyenne, et Next.js semble même accélérer sa mauvaise réputation. Le mieux est de rester à distance

• Vercel finira probablement par corriger ce bug, mais j’en ai désormais assez de tous ces petits problèmes qui s’accumulent dans Next.js. Par exemple, la manière d’identifier le prefetch dans le middleware est cassée depuis des semaines, voire des mois. Ce sont ce genre de petits soucis répétés qui finissent par fatiguer avec Next.js. Cela dit, j’aime toujours l’écosystème JS dans son ensemble

  • J’ai quitté Next.js pour Astro. Je voulais revenir à quelque chose de plus fondamental, mais configurer moi-même les routes, les templates, les assets statiques et le build était pénible. Astro gère tout ça, avec SSR par défaut. On a l’impression d’ajouter React/Vue comme couche d’interactivité, comme c’était prévu à l’origine, et ça m’a fait réaliser à quel point les frameworks JS sont en réalité souvent superflus. Next accumule de plus en plus de magie, les server actions sont maladroites, et il y avait trop de choses implémentées « à la manière NextJS »

  • J’utilise actuellement Next.js pour le travail et pour des projets perso, mais c’est dommage de voir la direction prise après le passage de pages vers l’app router, alors qu’avant c’était un outil agréable et productif

  • Depuis la version 15.1.8, certaines bibliothèques1 sont cassées, ce qui oblige à revenir à la version vulnérable mentionnée par l’auteur

  • D’accord. À l’avenir, je compte n’utiliser Next.js que pour des sites statiques ou des SPA précompilées

• Next est en train de devenir une blague. Depuis que Remix s’est transformé, de façon incompréhensible, en react-router, j’ai l’impression qu’il reste très peu de frameworks React corrects. Au final, je suis revenu à une combinaison plain vite + tanstack router

  • Je suis surpris que ce genre de post critique reste visible sur Hacker News. Il y a quelque temps, j’avais publié un message disant que c’était plus simple à implémenter avec Remix, et plusieurs employés de Vercel m’avaient contacté pour me demander de le supprimer ou de faire une réunion. Ils m’ont approché simultanément via plusieurs comptes sur les réseaux sociaux

  • Je me demande si vous voulez dire que vous n’utilisez plus Remix depuis le changement de marque, ou que ce n’est plus un framework. RR7 (React Router 7) fonctionne tout à fait comme framework1. J’ai été développeur backend pendant 15 ans avant de passer récemment au full stack, et j’utilise RR7 sur la recommandation d’un bon ami : je suis impressionné chaque jour

  • J’ai essayé TanStack Router sur un nouveau projet et j’ai tellement aimé que j’ai aussi ajouté TanStack Query et TanStack Form

  • Je me demande quelle est la meilleure alternative, et pourquoi vous utilisez Vite. Pour mes petits projets, j’utilise Next, et j’ai entendu dire que son principal avantage était le SEO. Si on peut simplement générer des fichiers statiques et les envoyer sur S3, est-ce que ce n’est pas suffisant ?

  • Je me demande concrètement ce qui pose problème dans le passage de Remix à react-router. De mon point de vue, ça ressemble simplement à un rebranding

• Cela fait des années que j’insiste sur le fait qu’il faut être bien plus prudent avec React, Next, Svelte, etc. quand ces projets sont pilotés par des acteurs comme Vercel. Leur objectif est de faire comme Heroku, mais de manière bien plus agressive, en poussant à un verrouillage complet sur toute la stack, du langage au runtime jusqu’à la machine. D’autres entreprises posent aussi problème. Par exemple, l’outil CLI de déploiement de Cloudflare ne prend en charge que macOS 13.5+, soit un système vieux d’à peine plus de deux ans, sans qu’on sache vraiment pourquoi. C’est triste de voir qu’un OS sorti il y a deux ans est déjà traité comme obsolète. On peut encore essayer d’anciennes versions de wrangler, mais la documentation ne correspond pas aux fonctionnalités et la situation risque seulement d’empirer. La compatibilité pourrait aussi être coupée un jour. À l’inverse, d’autres outils comme vim, neovim ou emacs fonctionnent encore sur d’anciennes versions d’OS X. À mon avis, c’est parce que ces outils ouverts n’ont pas d’incitation au lock-in

• Next et RSC sont parmi les choses les plus frustrantes que j’aie eues à gérer côté frontend. Le frontend est déjà suffisamment pénible comme ça, et on y ajoute en plus la « magie » de Next puis un vendor lock-in vers Vercel. Dans l’équipe, on va passer cette semaine à tanstack router et vite pour essayer de faire une CSA classique, et j’ai hâte

  • Je me demande ce qui est si frustrant avec RSC. Dans mon expérience, ça fonctionne vraiment bien, et c’est encore la seule raison pour laquelle j’utilise Next.js

• Il faudrait vraiment que tout le monde parle davantage du fait qu’en mode développement, Next.js peut mettre 10 secondes à compiler une route. On dirait que le compilateur Rust est tranquillement en train de fumer une cigarette dans un coin

  • C’est inutilisable. La pire devx que j’aie connue. La dernière fois que j’ai détesté une stack à ce point, c’était quand j’aidais sur un site Sharepoint

  • Aujourd’hui, même JS, qui est pourtant un simple langage de script, passe par plusieurs étapes de build/compilation, et ça prend désormais plus de temps qu’un compilateur C++. À ce rythme, mettre Clang dans le navigateur offrirait presque une meilleure expérience. À titre d’exemple, dans l’entreprise on utilise aussi PHP, et on a le même problème. On pourrait croire qu’un langage de script reste simple, mais à cause des limites de performance de PHP lui-même, on doit ajouter une étape de génération préalable du code et une étape de build Composer séparée. Et ce build créé par des développeurs PHP est lui aussi lent. Sans doute parce qu’il n’a pas été conçu par les auteurs de GCC

  • Étrangement, même l’option next dev —-turbo n’est pas plus rapide sur le codebase de notre entreprise

  • Le compilateur Rust compile réellement des choses, alors je me demande si le compilateur de Next.js effectue vraiment un travail d’une complexité comparable

• L’état actuel de Next.js est regrettable. Je l’utilise encore, mais au point de devoir le forker et le patcher moi-même. next.config.js est une échappatoire pénible pour modifier le comportement par défaut, alors que ces options auraient dû être fournies comme de vrais points d’extension, et non cachées derrière des feature flags. Aujourd’hui, on est tout proche d’un framework spaghetti noté D

• Si ce n’est pas NextJS, quelle combinaison recommandez-vous pour une stack complète ? Je suis développeur backend depuis 15 ans, mais je n’avais plus touché au frontend depuis AngularJS. Récemment, pour un projet perso, j’ai voulu construire une application full stack, et en cherchant, aussi bien Gemini que la documentation officielle recommandaient tous NextJS. J’en suis encore au début, donc j’aimerais apprendre des alternatives. Je compte tout faire tourner moi-même dans Docker sur un VPS, donc j’évite Vercel et Netlify

  • Si vous n’avez pas besoin de rendu serveur, je recommande React sans framework avec Vite1. En développement, ça tourne avec Vite, et le build de production ne sort que des fichiers HTML + JS, qu’il suffit d’héberger sur un service statique comme S3. J’utilise ça depuis plus de 10 ans sans problème. Pour le backend, prenez ce qui vous convient ; en ce moment, moi j’utilise surtout PostgREST2. Pour les appels API côté client, je recommande react-query3

  • Je suis curieux de savoir quel type de projet vous développez. Je construis un SaaS web assez classique, et la combinaison React/Refine.dev/Vite fonctionne très bien. Grâce à Refine.dev, je peux me concentrer sur les fonctionnalités sans me soucier des pages CRUD

• Je trouve qu’on exagère avec ce problème. Pour quelqu’un qui comprend comment fonctionne le streaming dans React, il est évident qu’on ne peut pas streamer le HTML ligne par ligne. Le premier affichage ne doit pas être bloqué à cause des métadonnées, et cela vaut pour le HTML, pas seulement pour le JS. Il est donc raisonnable d’exclure certains user agents dans ce comportement. Sur la majorité du trafic, l’important est d’afficher le contenu le plus vite possible. Je me demande en revanche comment gérer le cas des utilisateurs pour qui le chargement des métadonnées prend longtemps