- Desde Next.js 15.1.8, cambió la forma de procesar los metadatos, lo que provoca problemas graves en entornos de despliegue que no sean Vercel
- Los metadatos ya no se renderizan directamente en el
head de HTML, sino que se envían por separado mediante un método llamado "metadata streaming"
- Si el motor de búsqueda no ejecuta JavaScript, los metadatos simplemente no se exponen, lo que daña de forma crítica el SEO
- Se manejan excepciones con detección de crawlers (
htmlLimitedBots), pero no es una solución perfecta
- Proveedores distintos de Vercel como Netlify, Cloudflare y AWS intentan compatibilidad con OpenNext, pero en la práctica Next.js está demasiado atado a la infraestructura de Vercel, por lo que portarlo es difícil y tiene muchos bugs
- Incluso en builds estáticos, los metadatos no se incluyen en el
head de HTML, y la estructura cambió para obligar a todos los entornos de despliegue a lidiar con una detección compleja de crawlers o con la ejecución de JS
- Problema de seguridad (vulnerabilidad crítica publicada en marzo de 2025)
- Si uno se queda en versiones antiguas para evitar metadata streaming, queda expuesto a vulnerabilidades graves de seguridad (el parche solo se ofreció en 15.2.3)
- Metadata streaming en realidad oculta problemas de rendimiento de la página y también impacta negativamente en el SEO
- Conclusión:
Next.js parece open source, pero en la práctica se ha convertido en un framework con una dependencia grave de Vercel, por lo que para proyectos nuevos conviene considerar otras opciones
Resumen general
- Desde la versión 15.1.8 de Next.js, aparecen problemas serios en el manejo de
metadata fuera de Vercel
- Esto profundiza la dependencia estructural de Next.js respecto a la infraestructura de Vercel, deteriora el SEO e incluso genera riesgos de seguridad
El inicio del problema: la introducción de metadata streaming
- En 2024, Vercel introdujo una función experimental llamada metadata streaming
- A diferencia del método anterior, los metadatos (tags como title, description, Open Graph, etc.) ya no se renderizan directamente en el `` de HTML, sino que se envían por separado después de la carga inicial de la página
- Esta función pasa a requerir ejecución de JavaScript
La explicación técnica de Vercel y los problemas reales
- El motivo de su adopción: resolver un cuello de botella computacional en la generación de metadatos
- Pero en la práctica, la mayoría de los metadatos son estáticos y pequeños (menos de 1KB)
- El costo de un round-trip al servidor es mayor que procesarlo inline
- Los metadatos dinámicos son casos excepcionales muy poco frecuentes
- La implementación de metadata streaming aumenta la complejidad y la confusión
Contexto del problema de rendimiento
- Algunos desarrolladores experimentaron problemas de rendimiento por demoras en la generación de metadatos, por ejemplo al integrar APIs externas
- Para resolver esto, Vercel desarrolló un enfoque de streaming
Crawlers de motores de búsqueda e impacto en SEO
- Los motores de búsqueda que no ejecutan JavaScript no pueden leer los metadatos
- Como resultado, esto tiene un impacto muy negativo en el SEO
- Como solución, Vercel ofrece la función htmlLimitedBots, que hace que el servidor detecte crawlers y omita el streaming para insertar los metadatos en HEAD
Limitaciones de otros proveedores cloud
- Netlify, Cloudflare y AWS también crearon un proyecto adaptador llamado OpenNext para compatibilidad con Next.js
- Pero como Next.js está demasiado acoplado a Vercel, portarlo requiere ingeniería inversa
- Por los problemas de calidad de OpenNext, en la práctica no funciona correctamente
Incluso los builds estáticos quedan incompletos
- Incluso en un build de sitio estático (Static Build), los metadatos ya no se incluyen en el
head de HTML
- Al empaquetarse junto con React Server Components, también requieren ejecución de JavaScript
- Surge así la situación absurda de tener que implementar por cuenta propia lógica de detección de crawlers solo para obtener metadatos HTML básicos
Vulnerabilidad grave de seguridad y problema de actualización
- El 21 de marzo de 2025 se publicó una vulnerabilidad crítica (nivel de seguridad 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927)
- Esta vulnerabilidad permite eludir la seguridad de autenticación del middleware mediante la manipulación de ciertos headers
- El parche se aplicó en Next.js 15.2.3, pero si uno se queda en 15.1.8 para evitar metadata streaming, queda muy expuesto en términos de seguridad
Consecuencias negativas de la adopción de streaming
- Metadata streaming oculta aún más los problemas de rendimiento
- Si hay retrasos en el procesamiento de metadatos de la página, el usuario real no los percibe
- Los crawlers de motores de búsqueda terminan aplicando penalizaciones de puntaje SEO por respuestas lentas
Conclusión
- Next.js se ha degradado en un vendor lock-in de Vercel disfrazado de framework open source
- Al elegir el stack tecnológico para proyectos futuros, es más sensato considerar otros frameworks en lugar de Next.js
5 comentarios
¿Entonces
remixsería la alternativa?Como se menciona en el texto, hay un bloqueo de proveedor excesivo, comportamientos demasiado tipo caja negra y APIs poco intuitivas. Además, del lado de React también están promocionando abiertamente este estilo de desarrollo con renderizado en el servidor como si fuera la forma estándar de desarrollar con React. Creo que para la mayoría de las apps, un SPA basado en Vite es más que suficiente.
Reconozco hasta cierto punto que ocurra el vendor lock-in, pero las opiniones sobre la tecnología de Next.js en sí, cuando uno las ve, parecen no pasar del nivel de "no quiero leer el artículo".
Llevaban tiempo aparentando ser abiertos mientras actuaban de forma cerrada, y al final prácticamente dejaron la puerta bajo llave.
Opiniones de Hacker News
Nunca recomendaría usar Next. La experiencia de desarrollo es terrible, el vendor lock-in es fuerte y, por sus convenciones raras no documentadas, se siente como si hubiera minas por todos lados a menos que hagas un SaaS B2B simple centrado en CRUD. En particular, tuve un caso donde la etiqueta
<Image />de Next bajó los FPS de una escena webgl en la misma página hasta 2Me pregunto cómo Vercel logró hervir lentamente a los usuarios comunes de React hacia el vendor lock-in. React era un proyecto de Meta que enfatizaba el open source, y yo esperaba que el open source sirviera para evitar el vendor lock-in, así que decepciona ver que en la práctica no fue así
Totalmente de acuerdo. Hace poco volví a usar Next después de mucho tiempo y la experiencia de desarrollo fue muy decepcionante. La documentación era ambigua y difícil de encontrar, y la app en sí se sentía lenta por defecto. Intenté desplegar en AWS con Docker y terminé enfrentando muchísimos problemas por culpa del Dockerfile de ejemplo que da Vercel
Me da curiosidad si analizaste directamente el problema de
<Image />o si solo supones que fue culpa de NextJs. Yo trabajo con la combinación de NextJs,<Image>y RTF, y nunca he tenido ese problemaLlevo 3 años usando Next.js en el trabajo y de verdad se siente doloroso. Lo hospedamos en Vercel, y la empresa adoptó casi todos los servicios de Vercel, así que he vivido el vendor lock-in en serio. Antes compartí una mala experiencia en un post de HN que hizo Dan sobre RSC, y sentí que sus observaciones eran exactas. Como cuando dijo: "RSC en sí ya es bastante sólido, pero los frameworks como Next.js todavía están algo verdes". En general, React ahora ya me parece por debajo del promedio, y Next.js más bien acelera su mala reputación. Mejor mantenerse lejos
Seguro Vercel arreglará este bug, pero ya estoy cansado de Next.js porque se le acumulan este tipo de problemas pequeños. Por ejemplo, en middleware la forma de identificar
prefetchlleva semanas, o quizá meses, rota. Este tipo de detalles se sigue acumulando y me genera mucha fatiga con Next.js. Aun así, sigo teniendo cariño por el ecosistema de JS en generalDejé Next.js y me fui a Astro. Quería volver a lo básico, pero me daba flojera configurar por mi cuenta rutas, plantillas, assets estáticos y el build. Astro se encarga de todo eso y además es SSR por defecto. Se siente como usar React/Vue como una capa de interactividad, tal como se pensó originalmente, y eso me hizo darme cuenta de lo innecesarios que pueden ser en realidad los frameworks de JS. Next cada vez tiene más elementos mágicos, las server actions se sienten raras y había demasiadas implementaciones "a la NextJS"
Ahora mismo uso Next.js tanto en el trabajo como en proyectos personales, pero antes era una herramienta divertida y productiva, y desde la transición de
pagesal app router me decepciona la dirección que tomóDesde la versión 15.1.8 algunas librerías1 se rompieron, así que hubo que bajar a la versión vulnerable que menciona el autor
De acuerdo. En adelante pienso usar Next.js solo para sitios estáticos o SPA precompiladas
Next ya está para el chiste. Como Remix se convirtió, de una forma difícil de entender, en react-router, siento que ya casi no quedan buenos frameworks de React. Al final regresé a la combinación de plain vite con tanstack router
Me sorprende que una publicación tan crítica siga en Hacker News. Una vez publiqué que algo se implementaba más fácil con Remix, y varios empleados de Vercel me mandaron mensajes para pedirme que lo bajara o para proponer una reunión. Me contactaron al mismo tiempo por varias cuentas de redes sociales
Me da curiosidad si quieres decir que ya no usas Remix desde el cambio de marca, o si quieres decir que ya no es un framework. RR7 (React Router 7) también funciona perfectamente como framework1. Fui backend por 15 años y hace poco me pasé a full-stack; un buen amigo me recomendó RR7 y me sorprende todos los días
Probé TanStack Router en un proyecto nuevo y me gustó tanto que también agregué TanStack Query y TanStack Form
Me gustaría saber cuál alternativa te parece la mejor y por qué usas Vite. Yo uso Next en proyectos pequeños porque siempre escuché que su mayor ventaja era el SEO. Si al final solo generas archivos estáticos y los subes a S3, me pregunto si eso no es suficiente
Me da curiosidad qué problema hay exactamente con que Remix se haya vuelto react-router. A mí me parece que solo fue un rebranding
Llevo años insistiendo en que hay que ser mucho más cuidadosos con React, Next, Svelte y demás cuando están impulsados por empresas como Vercel. Su objetivo es ser como Heroku, pero de una forma mucho más agresiva, empujando al lock-in total de todo el stack: lenguaje, runtime y máquina. Otras empresas también tienen problemas. Por ejemplo, la herramienta CLI de despliegue de Cloudflare solo soporta macOS 13.5+ (poco más de 2 años), y no está claro por qué. Da tristeza que un sistema operativo de hace 2 años ya se trate como algo viejo. Puedes intentar usar una versión anterior de wrangler, pero la documentación y las funciones no coinciden y de todos modos parece que eso irá a peor. Algún día incluso podrían romper la compatibilidad. En cambio, otras herramientas como vim, neovim, emacs, etc. todavía funcionan en OS X mucho más viejos. Creo que eso pasa porque estas herramientas abiertas no tienen incentivos de lock-in
Next y RSC son de lo más frustrante con lo que me he topado en frontend. El frontend ya era suficientemente problemático, y encima le agregas la "magia" de Next y el vendor lock-in de Vercel. En el equipo esperamos esta semana cambiar a tanstack router y vite para intentar hacer un CSA normal
Todo el mundo debería hablar más del hecho de que, en modo desarrollo de Next.js, compilar rutas tarda 10 segundos. El compilador de Rust parece estar en una esquina fumándose un cigarro
Es inutilizable. El peor devx que he vivido. La última vez que odié tanto un stack fue cuando ayudé con un sitio de Sharepoint
Ahora hasta JS, que supuestamente es un lenguaje de scripting simple, pasa por múltiples etapas de build/compilación y termina tardando más que un compilador de C++. Ya estamos en un punto donde hasta meter Clang en el navegador sonaría como mejor experiencia. En mi empresa también usamos PHP y pasa algo parecido. Se suponía que, por ser un lenguaje de scripting, iba a ser simple, pero por límites de rendimiento del propio PHP tuvimos que agregar generación previa de código y una etapa separada de build con Composer. Pero ese build hecho por desarrolladores de PHP también es lento. Supongo que porque no lo hicieron los creadores de GCC
Curiosamente, la opción
next dev —-turbotampoco es más rápida en el codebase de nuestra empresaEl compilador de Rust de verdad compila cosas; me pregunto si el compilador de Next.js realmente está haciendo algo así de complejo
Me da pena el estado actual de Next.js. Lo sigo usando, pero al grado de tener que hacer mi propio fork y parchearlo.
next.config.jses una vía de escape complicada para cambiar el comportamiento por defecto, y creo que esas opciones deberían haberse ofrecido como puntos de extensión desde el principio, no escondidas detrás defeature flag. Ahora mismo ya se siente como un framework de calificación D, casi spaghetti codeSi no fuera NextJS, ¿qué combinación recomendarían para un stack completo? Soy desarrollador backend con 15 años de experiencia, pero en frontend no tocaba nada desde AngularJS. Hace poco quise construir una app full-stack para un proyecto personal y, al buscar, tanto Gemini como la documentación oficial me recomendaron NextJS. Todavía estoy a tiempo de cambiar y me gustaría aprender alternativas. Pienso operar todo yo mismo en un VPS con Docker, así que evito Vercel y Netlify
Si no necesitas server rendering, te recomiendo React sin framework junto con Vite1. Durante el desarrollo corres Vite, y el build de producción solo genera archivos HTML + JS, así que basta con subirlos a un hosting estático como S3. Llevo más de 10 años así y sin problemas. Para el backend usa lo que te resulte cómodo; yo últimamente uso mucho PostgREST2. Para llamar la API desde el cliente recomiendo react-query3
Me da curiosidad qué tipo de proyecto estás desarrollando. Yo estoy haciendo una webapp SaaS bastante típica y la combinación de React/Refine.dev/Vite me ha funcionado muy bien. Gracias a Refine.dev puedo enfocarme en desarrollar funcionalidades sin preocuparme por las páginas CRUD
Creo que este tema se está exagerando. Para quien entiende cómo funciona el streaming en React, es sentido común que no puedes streamear HTML línea por línea. No deberías bloquear el first paint por culpa de metadata; hablo del HTML, no del JS. Tiene sentido hacer excepciones con ciertos user agents en este comportamiento. Para la mayor parte del tráfico, lo importante es mostrar algo lo más rápido posible. Me pregunto cómo lo resolverían para usuarios en los que cargar la metadata tarda mucho