Next.js vs Vite 2026: comparacion de Core Web Vitals (LCP, INP, TTFB)

Next.js 15.2 y Vite 6 son los dos pipelines de build de React mas desplegados en 2026, y resuelven problemas muy distintos. Next.js es un framework full-stack opinado con SSR, Server Components y pipeline de imagenes integrado. Vite es un bundler y dev server sobre el que se construyen otros frameworks (y muchas SPAs internas). Este articulo los compara cara a cara en las cuatro metricas que importan para Core Web Vitals -- LCP, CLS, INP y TTFB -- usando datos de campo de CrUX de abril de 2026, ejecuciones controladas de Lighthouse y analisis de bundle sobre una aplicacion de referencia fija.

Esta comparativa usa datos CrUX de BigQuery de abril 2026, recalibrados frente a nuestro dashboard de benchmarks de frameworks. Tambien hemos vuelto a ejecutar la misma aplicacion de referencia -- una tienda React de 12 paginas con listado de productos, detalle, carrito y checkout -- en ambos stacks con configuraciones de despliegue identicas para medir numeros de laboratorio en condiciones controladas. Mira nuestra pagina de metodologia para las reglas de seleccion del corpus y los sitios excluidos.

Arquitectura: framework vs herramienta de build

Lo primero que conviene entender es que Next.js y Vite no estan en la misma categoria.

Next.js 15.2 es un framework React full-stack. Es dueno del router basado en ficheros, el contrato de fetching de datos, el build, el dev server, el optimizador de imagenes y la historia de despliegue. Por defecto activa React Server Components en el App Router, asi que la mayor parte de tu codigo corre en el servidor y envia cero JavaScript al cliente. La interactividad cliente es opt-in con la directiva 'use client'. El framework tambien expone Edge Functions, Server Actions y una capa de cache opinada.

Vite 6 es una herramienta de build y dev server. Compila tu codigo con esbuild en desarrollo y con Rollup en produccion, y expone una API pequena de plugins. Por si solo, Vite te da una experiencia de desarrollo rapida y un bundle de produccion, nada mas. Aportas tu propio router, tu propia capa de datos y tu estrategia SSR (o vas full SPA). Vite tambien es la base bajo SvelteKit, Nuxt, Astro, SolidStart, TanStack Start, el nuevo build de Remix y decenas de frameworks mas.

Esto condiciona el resto de la comparativa. Cuando decimos "Next.js" en este articulo, hablamos del framework tal como lo distribuye Vercel. Cuando decimos "Vite", hablamos de una SPA React + Vite en la configuracion canonica (React Router, TanStack Query, sin SSR) salvo que se indique otra cosa. Si pones Vite bajo un framework que anade SSR, los numeros se mueven hacia Next.js en LCP y TTFB y se alejan de Vite en tamano de bundle.

LCP: Next.js gana en el primer pintado

Largest Contentful Paint mide cuanto tarda en renderizarse el elemento visible mas grande. En paginas publicas y con mucho contenido, Next.js tiene una ventaja estructural: sirve HTML pre-renderizado con CSS critico y preload de imagenes desde el borde.

En nuestros cortes de abril 2026 con los 1000 origenes mas visitados de Next.js y Vite-solo en React, Next.js cumple el umbral LCP <= 2.5s en el 76% de las sesiones, mientras que las SPAs Vite puras se quedan en el 61%. Los 15 puntos de diferencia se explican casi enteramente porque las SPAs Vite pagan el renderizado cliente en el primer pintado -- el usuario ve una cascara vacia, descarga JS y entonces renderiza. Next.js se salta esa fase entera. Para la misma tienda de referencia, un build de Next.js App Router con el componente <Image> marca LCP de 1.4s en WebPageTest movil 4G; la SPA Vite equivalente marca 3.1s.

Puedes cerrar esta brecha desde el lado Vite anadiendo SSR con un framework como TanStack Start o pre-renderizando rutas estaticas en build con vite-plugin-ssg. Si lo haces, la brecha de LCP se acorta a menos de 200ms. El precio es la complejidad arquitectonica de operar un servidor. Si no necesitas un primer pintado SEO-grade, el LCP de una SPA Vite es aceptable y la experiencia de desarrollo es significativamente mas simple.

El componente <Image> de Next.js hace bastante trabajo aqui. Gestiona dimensionado responsive, negociacion de formato (WebP y AVIF), lazy loading y -- esto es clave -- emite un hint preload para la imagen mas grande cuando se marca loading=eager. Si estas en Vite y te importa LCP, estudia la guia de LCP en Vite y pon un preload similar en tu plantilla HTML manualmente.

CLS: empate, con una nota

Cumulative Layout Shift es un empate. Ambos frameworks envian CSS con las mismas garantias a nivel navegador, y los componentes de imagen modernos reservan espacio mediante atributos width/height. El P75 de CrUX para CLS en ambos ecosistemas se queda en 0.06 -- muy por debajo del umbral de 0.1.

La nota es sobre fuentes. next/font en Next.js gestiona font-display: optional y descriptors size-adjust automaticamente; Vite delega la carga de fuentes en ti. Si envias una app Vite sin self-host mas font-display: swap, puedes incurrir en una regresion de 0.04 a 0.08 en CLS en el primer pintado. Usa el plugin vite-plugin-fonts o self-host con size-adjust en CSS y volveras a paridad.

INP: Vite gana en apps pequenas, Next.js alcanza en grandes

Interaction to Next Paint es mas interesante. Las SPAs Vite envian menos codigo de framework de media -- nada de runtime de React Server Components, nada de shim del router de Next.js, nada de orquestador de navegacion cliente -- asi que el hilo principal esta mas libre. Sobre la misma tienda de referencia, Vite marca un P75 de INP de 112ms con datos reales de campo en movil, mientras Next.js App Router marca 148ms.

Esa ventaja se reduce en apps mas grandes. Una vez tu bundle pasa los 250KB de JavaScript, las diferencias de coste de hidratacion se convierten en ruido y los drivers mayores de INP son tu propio codigo: handlers de click grandes, actualizaciones de estado sincronas, re-renders caros en listas. A esa escala, el scheduler de React 19 y el partial pre-rendering de Next.js para rutas dinamicas se adelantan, porque el arbol de servidor nunca se ejecuta en cliente. Hemos visto Next.js con INP por debajo de 150ms en una app de 320KB de bundle donde el equivalente Vite estaba en 170ms.

Si INP es tu prioridad y tu app es pequena, Vite. Si tu app es grande o la disciplina del equipo en codigo cliente es debil, el modelo server-default de Next.js te da garantias mas baratas.

TTFB: depende totalmente de donde despliegues

Time to First Byte lo determina mucho mas el hosting que el framework. Una app Next.js en la red edge de Vercel marca TTFB en P75 alrededor de 240ms globalmente. Una SPA Vite servida como estaticos en la misma red edge marca TTFB alrededor de 90ms -- porque no hay nada que computar. Pero una app Next.js en un origen monoregion en us-east-1 da a un usuario de Madrid un TTFB de 600ms mientras una SPA Vite tras CDN se queda por debajo de 200ms.

El patron: si tu TTFB es malo, arregla tu topologia de despliegue antes de cambiar de framework. Mira nuestra guia de TTFB para la cascada de causas. Si empiezas de cero y TTFB importa mas que la completitud del HTML inicial, una SPA Vite sobre CDN global es la opcion mas rapida que puedes desplegar.

Tamano de bundle: mas cercano de lo que parece

Para nuestra tienda de referencia con React 19 identico y dependencias identicas:

• SPA Vite, chunk inicial: 117 KB gzipped (React + React DOM + React Router + codigo de app)
• Next.js App Router: 142 KB gzipped en una pagina plenamente interactiva; 62 KB gzipped en una pagina solo de Server Components (galeria de imagenes, sin interactividad cliente)

El titular es que una SPA pura y una pagina Next.js totalmente interactiva estan a 25KB la una de la otra. La ventaja estructural de Next.js es la capacidad de enviar 62KB en las paginas que no necesitan interactividad, que son la mayoria en un sitio de contenido. Sobre un sitio de 20 paginas, esto se acumula.

Experiencia de desarrollo y velocidad de build

Aqui es donde mas divergen los dos. El arranque en frio del dev server de Vite en nuestra tienda de referencia es de 320ms. El HMR tras editar un componente es de 18ms. El build de produccion es de 4.2 segundos.

El arranque en frio del dev server de Next.js es de 8.1 segundos. El HMR sobre la edicion de un Server Component es de 800ms a 1.4s. El build de produccion es de 47 segundos. El flag Turbopack mejora los numeros de dev significativamente pero sigue en beta en 15.2.

Para velocidad pura de desarrollo local, Vite gana con margen. Para despliegue de produccion que incluye optimizacion de imagenes, pre-renderizado de rutas y calentamiento de cache ISR, Next.js hace mas trabajo y por tanto tarda mas con razon.

Cuando elegir Next.js

• Sitios de contenido, blogs, paginas de marketing, documentacion
• Tiendas e-commerce donde SEO y HTML del primer pintado importan
• Apps donde la mayoria de paginas no son interactivas (Server Components brillan)
• Equipos que quieren defaults batteries-included
• Cualquier cosa que aproveche streaming SSR o ISR

Cuando elegir Vite

• Herramientas internas, dashboards, paneles de administracion
• Apps embebidas dentro de otros productos
• SPAs autenticadas donde el SEO es irrelevante
• Prototipos cliente y herramientas de diseno
• Apps donde la velocidad del dev server domina las decisiones del proyecto
• Proyectos greenfield donde quieres elegir tu propio router y capa de datos

Rutas de migracion

La mayoria de equipos no deberian migrar. Si estas en Pages Router de Next.js y estas contento, quedate. Si estas en una SPA Vite con buenos Core Web Vitals, quedate. Los costes de migracion son reales y las diferencias dirigidas por framework en LCP/INP suelen ser mas pequenas que las diferencias de disciplina del equipo.

Si tienes que migrar, las dos direcciones se ven distintas. Pages Router a App Router de Next.js es la migracion de mayor valor de las dos -- te da Server Components, streaming y los nuevos primitivos de cache. Migrar de Vite a Next.js merece la pena cuando tu producto adquiere requisitos de SEO. Migrar de Next.js a Vite raramente merece la pena salvo que hayas ido full cliente y los defaults del framework esten peleando contigo.

Que viene en la segunda mitad de 2026

Dos cosas para vigilar. Primero, la integracion Vite RSC: cuando se estabilice, la brecha entre "Vite + un framework" y Next.js se acorta significativamente, especialmente alrededor de Server Components para casos sin SEO. Segundo, la inversion continua de Next.js en Turbopack -- si el arranque en frio del dev server cae por debajo de 2 segundos, la mayor ventaja restante de Vite se erosiona.

Por ahora, el arbol de decision es simple: SEO con primer pintado HTML? Next.js. Experiencia app-shell o embebida? Vite. Ambos pueden pasar Core Web Vitals si haces lo basico bien. Mira nuestra comparativa Next.js vs Remix para una tercera opcion que parte la diferencia, o el benchmark React vs Vue si te estas replanteando la capa de runtime entera.