Cada dos o tres años el debate vuelve a empezar. Alguien del equipo lee un hilo, ve un benchmark con barras verdes y llega el lunes con la propuesta de reescribir el frontend. En 2026 el trío que se repite en casi todas esas conversaciones es el mismo: Next.js, Nuxt y Astro. Los tres son excelentes, los tres están mantenidos por comunidades sólidas y los tres pueden construir prácticamente cualquier cosa. Y precisamente por eso elegir se ha vuelto más difícil, no más fácil.
La pregunta correcta casi nunca es cuál es el mejor framework frontend. La pregunta es qué problema tiene tu producto ahora mismo, cuánto JavaScript necesita ejecutar el navegador para resolverlo, qué stack domina el equipo que va a mantener el código dentro de tres años y cuánto va a costar la factura de infraestructura cuando el tráfico se multiplique. Un framework no es una decisión estética: es una decisión de arquitectura con consecuencias de contratación, de coste operativo y de posicionamiento.
En Keliam hemos migrado, auditado y rescatado proyectos construidos con los tres. Hemos visto webs corporativas con 400 KB de JavaScript para renderizar cuatro secciones estáticas, y hemos visto aplicaciones de negocio complejas intentando funcionar con una arquitectura pensada para blogs. Los dos errores tienen el mismo origen: elegir por moda en lugar de elegir por modelo de renderizado.
Esta guía es el marco de decisión que usamos internamente. No hay ganador absoluto ni tabla comparativa con estrellitas. Hay criterios, escenarios reales y una recomendación clara para cada tipo de proyecto, incluyendo el caso más frecuente en empresas medianas: que ya exista un CMS o un ecommerce en producción y la pregunta real sea si conviene desacoplar el frontend o no tocar nada.
1. El mapa de 2026: qué problema resuelve cada framework
Antes de comparar hay que entender de dónde viene cada proyecto, porque su historia explica sus decisiones de diseño. Los tres nacieron para resolver problemas distintos y, aunque han convergido en funcionalidades, siguen optimizando cosas diferentes.
1.1 Next.js: el estándar de facto del ecosistema React
Next.js es el framework de React con más adopción empresarial del mundo, y en 2026 esa posición se ha consolidado. El App Router y los React Server Components dejaron de ser una novedad experimental para convertirse en la forma normal de escribir aplicaciones: los componentes se ejecutan por defecto en el servidor, solo se envía al navegador el JavaScript de las partes marcadas explícitamente como cliente, y el streaming permite pintar la parte estática de la página mientras los datos lentos todavía están viajando.
Lo que Next.js hace mejor que nadie es el rango. Puedes construir una landing estática, un panel de administración con estado complejo, un checkout transaccional o una aplicación multi-tenant sin salir del framework. Esa versatilidad tiene un precio: la superficie conceptual es grande. Server Components, Client Components, Server Actions, capas de caché, revalidación, middleware, rutas dinámicas y segmentos paralelos son muchas piezas para un equipo que solo quiere publicar una web corporativa rápida.
El otro punto fuerte, y este pesa más de lo que la mayoría de CTOs admite, es el mercado laboral. Encontrar personas que sepan React y Next.js es sensiblemente más fácil que encontrar cualquier otro perfil frontend. Si tu plan a tres años incluye crecer el equipo o rotarlo, ese dato es parte de la decisión técnica.
1.2 Nuxt: la experiencia de desarrollo más pulida
Nuxt hace por Vue lo que Next hace por React, pero con una filosofía distinta: convención sobre configuración, y muchísima menos ceremonia. Los auto-imports, el enrutado por sistema de archivos, los composables y el sistema de módulos hacen que la velocidad para pasar de una idea a una página funcionando sea notablemente mayor. Su motor de servidor, Nitro, es una de las piezas más elegantes del ecosistema: el mismo código se despliega en un servidor Node tradicional, en un contenedor o en un entorno edge sin reescribir nada.
Nuxt es especialmente fuerte cuando el equipo es pequeño y el proyecto tiene que avanzar rápido con pocas manos. Vue tiene una curva de aprendizaje más suave que React para perfiles que vienen de HTML, CSS y JavaScript clásico, y eso reduce el tiempo de incorporación de gente nueva. Su punto débil es de mercado, no técnico: la comunidad hispanohablante empresarial es más pequeña, y encontrar una agencia o un freelance que recoja el proyecto si el desarrollador original se marcha requiere algo más de búsqueda.
1.3 Astro: el que asume que la mayoría de páginas no necesitan JavaScript
Astro parte de una observación incómoda y bastante cierta: la mayor parte del contenido que servimos en la web es texto, imágenes y enlaces, y llevamos una década enviando frameworks completos al navegador para renderizar cosas que el HTML resolvía solo. Su arquitectura de islas invierte el planteamiento habitual: por defecto la página es HTML estático sin JavaScript, y la interactividad se activa isla por isla, únicamente donde se declara.
El resultado en métricas es difícil de discutir para sitios de contenido. Cuando no hay hidratación no hay bloqueo del hilo principal, y eso se traduce directamente en un INP y un LCP mejores, que es exactamente lo que Google mide desde que las métricas de Core Web Vitals incorporaron INP como señal de interactividad. Además, Astro es agnóstico: puedes usar componentes de React, Vue, Svelte o Solid dentro del mismo proyecto, lo que lo convierte en una vía de migración progresiva muy razonable.
Su límite aparece cuando el producto es una aplicación de verdad. Si la mayor parte de la interfaz es estado compartido, navegación sin recarga, formularios interconectados y datos que cambian en vivo, estarás luchando contra el diseño del framework en lugar de aprovecharlo.
2. Modelos de renderizado: la decisión que realmente estás tomando
Elegir framework es, en el fondo, elegir dónde y cuándo se convierte tu contenido en HTML. Todo lo demás (sintaxis, herramientas, plugins) es superficie. Merece la pena repasar las cuatro estrategias que están en juego, porque los tres frameworks las soportan pero cada uno tiene una por defecto y esa configuración por defecto es la que acabará dominando el proyecto.
2.1 Generación estática (SSG)
El HTML se construye en el momento del despliegue y se sirve como un archivo. Es la opción más rápida, más barata y más resistente a picos de tráfico que existe: un CDN sirviendo archivos estáticos aguanta prácticamente cualquier cosa sin que tu servidor se entere. El problema aparece cuando el catálogo crece: reconstruir veinte mil páginas en cada cambio de precio deja de ser viable, y ahí es donde entran las estrategias híbridas.
2.2 Renderizado en servidor (SSR)
El HTML se genera en cada petición. Es lo que necesitas cuando el contenido es personalizado (un panel de cliente, un carrito, precios por segmento B2B) o cuando cambia con demasiada frecuencia para prerenderizarlo. A cambio, cada visita consume CPU en tu infraestructura y el tiempo hasta el primer byte depende de lo rápido que respondan tu base de datos y tus APIs. Un SSR mal cacheado es la forma más habitual de convertir una web rápida en una web cara.
2.3 Regeneración incremental y caché por ruta
Es el punto medio que ha ganado la partida en la práctica. La página se genera una vez, se sirve estática y se regenera en segundo plano cada X segundos o cuando un webhook lo pide. Next.js lo lleva integrado desde hace años; Nuxt lo cubre con sus reglas de ruta en Nitro; Astro lo resuelve combinando prerender con adaptadores de servidor. Para un catálogo de ecommerce o un blog corporativo con cientos de entradas, esta suele ser la respuesta correcta.
2.4 Arquitectura de islas
La página es HTML estático y cada componente interactivo se hidrata de forma independiente, con la posibilidad de retrasar esa hidratación hasta que el elemento sea visible o hasta que el navegador esté ocioso. Astro la popularizó y es su modo natural de trabajo. La ventaja es que el coste de la interactividad es proporcional a la interactividad que realmente usas, en lugar de ser un peaje fijo que paga toda la página.
La conclusión práctica es sencilla: si tu proyecto es mayoritariamente contenido con islas de interacción, Astro te dará el mejor resultado con el menor esfuerzo. Si es mayoritariamente aplicación con algo de contenido, Next.js o Nuxt te evitarán pelearte con el framework. Y si estás justo en medio, gana el criterio de equipo, que veremos más adelante.
3. Rendimiento real: mide el JavaScript, no los benchmarks
Casi todas las comparativas de rendimiento que circulan miden lo que menos importa. Que un framework renderice diez mil filas en 12 milisegundos en lugar de 18 no cambia la vida de nadie. Lo que sí cambia el negocio es cuántos kilobytes de JavaScript tiene que descargar, parsear y ejecutar un móvil de gama media con una conexión mediocre antes de que el usuario pueda pulsar un botón.
En proyectos reales que hemos auditado, la diferencia entre una web de contenido construida con islas y la misma web construida con hidratación completa suele estar entre 120 y 400 KB de JavaScript comprimido. En un portátil con fibra es imperceptible. En un Android de gama media con 4G irregular es la diferencia entre un INP de 150 ms y uno de 600 ms, y por tanto entre pasar y no pasar el umbral de Core Web Vitals.
Dicho esto, conviene desmontar un mito frecuente: Next.js y Nuxt no son lentos. Un Next.js bien construido, con la mayoría de la interfaz en Server Components, imágenes optimizadas, fuentes autoalojadas y componentes cliente reducidos al mínimo, da resultados excelentes. Lo que es lento es el Next.js por defecto de un equipo que marca todo como componente cliente porque así funcionan los ejemplos que copió. El framework te da la herramienta; la disciplina la pones tú.
Por eso, antes de plantear una migración por motivos de velocidad, recomendamos siempre hacer una auditoría de rendimiento web con datos de campo, no solo de laboratorio. En más de la mitad de los casos que llegan a nosotros pidiendo cambiar de framework, el cuello de botella real eran imágenes sin optimizar, un tag manager cargando siete scripts de terceros y una fuente bloqueando el render. Cambiar de framework no habría arreglado nada de eso, y habría costado tres meses.
3.1 Qué medir antes de decidir
Nuestra lista mínima antes de tocar arquitectura: peso total de JavaScript en la ruta más visitada, tiempo de bloqueo del hilo principal, LCP e INP en datos de campo reales, número de peticiones a terceros y coste mensual de la infraestructura actual. Con esos cinco números encima de la mesa, la conversación sobre frameworks deja de ser una discusión de gustos y se convierte en una decisión de ingeniería.
4. Ecosistema, contratación y curva de aprendizaje
Este es el factor que más peso tiene en la decisión y el que menos aparece en las comparativas técnicas. Un framework no lo eliges para el sprint que viene: lo eliges para los próximos cuatro o cinco años de mantenimiento, incorporaciones, bajas y relevos.
React sigue siendo el ecosistema con más masa crítica, y eso arrastra a Next.js. Hay más candidatos, más librerías maduras para casos complejos (tablas, formularios, gráficas, estado de servidor), más documentación y más probabilidad de que cualquier proveedor externo pueda continuar el trabajo. Para una empresa que no quiere depender de una persona concreta, es un argumento serio.
Vue y Nuxt compensan con productividad. Equipos de dos o tres personas suelen entregar más rápido en Nuxt, la base de código tiende a ser más pequeña y la documentación oficial es probablemente la mejor de los tres. Si el equipo ya viene de Vue, cambiar a React por seguir la corriente es tirar meses de conocimiento a la basura.
Astro tiene la curva más suave de todas, con un matiz importante: es suave para lo que hace bien. Un desarrollador con HTML, CSS y algo de JavaScript es productivo en Astro en días. Pero si el proyecto empieza a pedir estado global y flujos de aplicación, ese mismo desarrollador acabará escribiendo React o Vue dentro de las islas, y la curva vuelve a aparecer por la puerta de atrás.
4.1 El coste oculto de la rotación
Un patrón que vemos con frecuencia en startups y en departamentos de IT pequeños: el proyecto se construye con la tecnología favorita de quien lo arrancó, esa persona se marcha a los dieciocho meses y nadie más en la empresa entiende la arquitectura. Es el mismo mecanismo que describimos al hablar de los errores técnicos que frenan el paso del MVP a un producto escalable: decisiones tomadas para ir rápido en el mes uno que se convierten en deuda estructural en el mes veinte. Elegir el stack que tu organización puede sostener, y no el que más te apetece hoy, es una forma barata de comprar tranquilidad.
¿Vas a cambiar de framework? Empieza por saber qué tienes
Antes de reescribir un frontend analizamos el rendimiento real, la arquitectura actual y el coste de mantenimiento, y te decimos si la migración compensa o si el problema está en otro sitio. Si compensa, la planificamos por fases y sin parar el negocio.
5. Coste de infraestructura y dependencia del proveedor
Un frontend moderno puede costar veinte euros al mes o dos mil, con el mismo tráfico y funcionalidad casi idéntica. La diferencia está en cuántas peticiones acaban ejecutando código en un servidor en lugar de resolverse en el CDN.
Una web mayoritariamente estática, con regeneración incremental para lo que cambia, se sirve desde caché en el 95% de las peticiones. Un SSR total ejecuta lógica en todas y cada una de ellas, y en plataformas serverless con facturación por invocación y por tiempo de ejecución esa cuenta escala mucho más rápido de lo que la gente espera cuando llega una campaña o una mención en prensa.
5.1 Lock-in: lo que hay que mirar antes de firmar
Next.js está profundamente integrado con Vercel, y varias de sus funcionalidades más cómodas dan su mejor versión allí. Se puede autoalojar perfectamente en Node o en contenedores, pero requiere trabajo de plataforma y hay matices de caché y de imágenes que conviene tener resueltos antes de comprometerse. Nuxt, gracias a Nitro, es el más neutral de los tres: el mismo proyecto se despliega en Node, en Docker, en un VPS clásico o en edge cambiando un adaptador. Astro genera archivos estáticos en su modo por defecto, lo que significa que puede vivir en cualquier hosting, incluso en el que ya tienes.
Para empresas con requisitos de soberanía del dato, con infraestructura propia o con contratos que exigen alojamiento en España o en la UE, esta diferencia no es menor. Si tu proyecto tiene que convivir con servidores que ya administras, revisa el encaje con tu operativa actual antes de casarte con una plataforma concreta: lo tratamos en detalle dentro de nuestros servicios IT para empresas.
6. El escenario real: ya tienes un CMS o un ecommerce funcionando
La mayoría de las empresas que nos preguntan por frameworks frontend no parten de cero. Tienen un WordPress con diez años de contenido, un Drupal con flujos editoriales montados o un PrestaShop con integraciones al ERP. La pregunta no es Next contra Astro: la pregunta es si desacoplar el frontend merece la pena.
6.1 Cuándo headless tiene sentido
Desacoplar compensa cuando hay varios canales consumiendo el mismo contenido (web, app móvil, pantallas, marketplaces), cuando el equipo de frontend necesita desplegar sin depender del ciclo del CMS, cuando el rendimiento del theme actual es irrecuperable o cuando la interfaz que quieres construir simplemente no se puede montar con el page builder que tienes. Lo desarrollamos en la guía de WordPress headless con Next.js y su arquitectura, y el mismo razonamiento aplica al caso de Drupal headless y cuándo conviene desacoplar el frontend.
6.2 Cuándo no compensa
Desacoplar duplica la superficie de mantenimiento: pasas de un sistema a dos, con dos despliegues, dos monitorizaciones y dos superficies de seguridad. Se pierden funcionalidades que el equipo de marketing daba por hechas, empezando por la previsualización en vivo y el editor visual. Y aparece una dependencia nueva: cualquier cambio de maquetación deja de ser una tarea del editor y pasa a ser un ticket de desarrollo.
Si tu web es una corporativa con un blog, si el equipo editorial es autónomo y si el problema es de velocidad, casi siempre sale más barato arreglar lo que hay. Un WordPress con un theme ligero, caché de página bien configurada, imágenes en formatos modernos y terceros bajo control compite de tú a tú con cualquier frontend desacoplado, y con una fracción del coste. Las novedades de rendimiento y de gestión de medios que llegaron con la actualización a WordPress 7 han estrechado esa distancia todavía más. Y si el proyecto está en Drupal, conviene revisar antes lo que ofrece Drupal 11 y su ruta de modernización antes de asumir que la única salida es reescribir.
6.3 El caso ecommerce
En ecommerce el cálculo cambia porque el checkout es sagrado. Desacoplar el catálogo y las páginas de producto es habitual y da buenos resultados de SEO y de velocidad; desacoplar el checkout es donde los proyectos se rompen, porque hay pasarelas, impuestos, portes, promociones y casos límite que la plataforma ya resolvía. Nuestra recomendación por defecto es híbrida: frontend rápido para el catálogo, checkout nativo de la plataforma. Cuando el negocio vive dentro de un ecosistema concreto, como ocurre con las apps y desarrollos a medida sobre Shopify, seguir las convenciones de la plataforma suele ganar a cualquier arquitectura teóricamente superior.
7. Árbol de decisión: cómo lo resolvemos en Keliam
Este es el orden de preguntas que aplicamos, y es deliberadamente aburrido. Las decisiones de arquitectura buenas suelen serlo.
- ¿Qué porcentaje de la interfaz es contenido y qué porcentaje es aplicación? Si el contenido supera el 80%, Astro es el punto de partida.
- ¿Hay estado compartido entre pantallas, navegación sin recarga o datos en tiempo real? Si la respuesta es sí en más de una pantalla, descarta el enfoque de islas puras.
- ¿Qué domina el equipo que va a mantenerlo? React lleva a Next.js, Vue lleva a Nuxt. No hay tercera opción razonable.
- ¿Dónde tiene que desplegarse? Si hay infraestructura propia o requisitos de alojamiento, prioriza portabilidad.
- ¿Existe ya un CMS o un ecommerce en producción? Evalúa headless parcial antes que reescritura total.
- ¿Qué presupuesto de mantenimiento hay para los próximos tres años? Un stack complejo con presupuesto de mantenimiento cero es una avería programada.
En la práctica, el reparto de nuestros proyectos de los últimos dos años se acerca bastante a esto: webs corporativas, blogs, documentación y landings de campaña van a Astro; aplicaciones de cliente, paneles internos, portales con áreas privadas y productos SaaS van a Next.js; y Nuxt aparece cuando el equipo ya es de Vue o cuando el proyecto necesita ir muy rápido con muy poca gente.
8. Migraciones: cómo hacerlas sin parar el negocio
Si después de todo lo anterior la migración sigue teniendo sentido, la forma de ejecutarla importa tanto como la elección del framework. Las reescrituras de big bang, en las que un equipo desaparece seis meses para volver con la web nueva, fallan con una regularidad deprimente: mientras tanto el negocio no ha podido publicar nada, la web antigua se ha quedado sin mantenimiento y el día del cambio aparecen doscientas URLs que nadie había mapeado.
8.1 Migración por rutas
El enfoque que recomendamos es incremental. Se pone un proxy delante que decide, ruta a ruta, si la petición va al sistema antiguo o al nuevo. Se empieza por una sección de bajo riesgo y alto volumen (el blog suele ser perfecta), se mide durante dos o tres semanas y solo entonces se mueve la siguiente. Si algo va mal, revertir es cambiar una regla del proxy, no deshacer un despliegue completo.
8.2 El SEO es la parte que más se descuida
Antes de mover nada hay que exportar el inventario completo de URLs indexadas, planificar las redirecciones 301 una a una, replicar los datos estructurados, mantener las etiquetas canónicas y comprobar que los sitemaps siguen siendo válidos. Una migración técnicamente impecable que pierde el 40% del tráfico orgánico es un fracaso, por muy buenas que sean las métricas de laboratorio. Y conviene monitorizar la cobertura en Search Console durante al menos ocho semanas después del cambio, porque los efectos no son inmediatos.
8.3 Errores frecuentes que nos encontramos
Marcar todos los componentes como cliente y anular la ventaja del renderizado en servidor. Cargar el gestor de etiquetas sin control y meter por la puerta de atrás todo el JavaScript que se había ahorrado con la arquitectura. Servir imágenes sin optimizar porque el CMS antiguo lo hacía automáticamente y el nuevo no. Olvidar la accesibilidad porque el framework ya no genera el HTML semántico que generaba el theme. Y, el más caro de todos, no dejar presupuesto de mantenimiento: un frontend moderno tiene dependencias que se actualizan cada pocas semanas y que dejan de recibir parches de seguridad antes de lo que la gente cree.
9. Preguntas frecuentes
¿Astro sirve para una tienda online?
Para el escaparate y el catálogo, sí, y con muy buenos resultados de velocidad y SEO. Para el checkout completo, normalmente no compensa: es preferible mantener el proceso de compra en la plataforma que ya gestiona pagos, impuestos y logística.
¿Merece la pena migrar de Next.js Pages Router a App Router?
Si el proyecto está en mantenimiento estable y funciona, no hay urgencia. Si está en evolución activa, sí, pero hazlo por rutas y no de golpe: ambos routers pueden convivir en la misma aplicación durante la transición.
¿Nuxt es peor opción por tener menos cuota de mercado?
Técnicamente no. El riesgo es organizativo: la disponibilidad de perfiles y de proveedores es menor. Si tu equipo ya trabaja con Vue, ese riesgo desaparece y Nuxt es una elección excelente.
¿Y si simplemente no migro?
Es una respuesta perfectamente válida y la que damos con más frecuencia de lo que la gente espera. Optimizar lo que ya funciona suele dar el 80% de la mejora por el 20% del coste y sin ningún riesgo de posicionamiento.
¿Cuánto dura una migración de frontend?
Para una web corporativa de tamaño medio, entre seis y doce semanas trabajando por fases. Para un portal con áreas privadas e integraciones, cuenta trimestres, no semanas. Cualquier estimación por debajo de eso suele ignorar la migración de contenido y el trabajo de SEO.
Conclusión
Next.js, Nuxt y Astro no compiten realmente por el mismo puesto. Astro gana cuando el trabajo es servir contenido rápido y bien posicionado con islas de interacción puntuales. Next.js gana cuando el producto es una aplicación con estado, un equipo de React detrás y ambición de crecer. Nuxt gana cuando el equipo es de Vue, quiere ir rápido y necesita libertad total de despliegue. Fuera de esos tres escenarios, la diferencia entre ellos es mucho menor que la diferencia entre hacerlo bien y hacerlo mal con cualquiera de los tres.
La recomendación que damos a los CTOs y responsables de IT con los que trabajamos es siempre la misma: no empieces por el framework. Empieza por medir lo que tienes, define qué porcentaje de tu interfaz es contenido y qué porcentaje es aplicación, mira con honestidad qué stack puede mantener tu organización durante los próximos años y calcula el coste de infraestructura del modelo de renderizado que estás eligiendo. Cuando tengas esas cuatro respuestas, el framework se elige prácticamente solo.
Y si la conclusión es que lo que tienes se puede arreglar sin reescribirlo, esa también es una decisión de arquitectura, y probablemente la más rentable de todas.
