Next.js vs Vite 2026: Core Web Vitals, LCP, INP, and TTFB Compared

Next.js 15.2 and Vite 6 are the two most-deployed React build pipelines on the web in 2026 -- and they solve very different problems. Next.js is an opinionated full-stack framework with SSR, server components, and a built-in image pipeline. Vite is a bundler-and-dev-server that other frameworks (and many in-house SPAs) build on top of. This post compares them head-to-head on the four metrics that matter for Core Web Vitals -- LCP, CLS, INP, and TTFB -- using CrUX field data from April 2026, controlled Lighthouse runs, and bundle analysis from a fixed reference app.

This comparison uses April 2026 CrUX BigQuery data, freshly re-baselined against our framework benchmarks dashboard. We also re-ran the same reference application -- a 12-page React storefront with a product list, product detail, cart, and checkout -- on both stacks at identical deployment configurations to measure lab numbers under controlled conditions. See our methodology page for the corpus selection rules and the exact sites we excluded.

Architecture: framework vs build tool

The first thing to understand is that Next.js and Vite are not in the same category.

Next.js 15.2 is a full-stack React framework. It owns the file-based router, the data-fetching contract, the build, the dev server, the image optimizer, and the deployment story. It defaults to React Server Components on the App Router, so most of your code runs on the server and ships zero JavaScript. Client interactivity is opt-in via the 'use client' directive. The framework also exposes Edge Functions, Server Actions, and an opinionated caching layer.

Vite 6 is a build tool and dev server. It compiles your code with esbuild during development and Rollup during production builds, and it exposes a small plugin API. By itself, Vite gives you a fast dev experience and a production bundle -- nothing more. You bring your own router, your own data layer, and your own SSR strategy (or you go full SPA). Vite is also the foundation under SvelteKit, Nuxt, Astro, SolidStart, TanStack Start, Remix's new build, and dozens of other frameworks.

This shapes the rest of the comparison. When we say "Next.js" in this article, we mean the framework as Vercel ships it. When we say "Vite", we mean a React + Vite SPA in the canonical configuration (React Router, TanStack Query, no SSR) unless otherwise noted. If you put Vite under a framework that adds SSR, the numbers move toward Next.js on LCP and TTFB and away from Vite on bundle size.

LCP: Next.js wins on first paint

Largest Contentful Paint measures how long it takes for the largest visible element to render. On public, content-heavy pages, Next.js has a structural advantage: it serves pre-rendered HTML with critical CSS and image preloads from the edge.

In our April 2026 CrUX cuts of the 1,000 most-visited Next.js and Vite-only React origins, Next.js pages hit the LCP <= 2.5s threshold on 76% of sessions, while pure Vite SPAs landed at 61%. The 15-point spread is almost entirely explained by Vite SPAs paying for client-side rendering on the first paint -- the user gets a blank shell, downloads JS, then renders. Next.js skips that entire phase. For the same reference storefront, a Next.js App Router build with the <Image> component scored LCP 1.4s on mobile WebPageTest 4G; the equivalent Vite SPA scored 3.1s.

You can close this gap from the Vite side by adding SSR through a framework like TanStack Start or by pre-rendering static routes at build time with vite-plugin-ssg. If you do that, the LCP gap narrows to within 200ms. The cost is the architectural complexity of running a server. If you don't need SEO-grade first paint, a Vite SPA's LCP is acceptable and the developer experience is significantly simpler.

The Next.js <Image> component is doing a lot of work here. It handles responsive sizing, format negotiation (WebP and AVIF), lazy loading, and -- crucially -- emits a preload hint for the largest image when the loading=eager attribute is set. If you're on Vite and you care about LCP, study the LCP-in-Vite playbook and put a similar preload in your HTML template manually.

CLS: a tie, with one footnote

Cumulative Layout Shift is a tie. Both frameworks ship CSS with the same browser-level guarantees, and modern image components reserve space via width/height attributes. CrUX 75th-percentile CLS for both ecosystems sits at 0.06 -- well under the 0.1 threshold.

The one footnote is fonts. Next.js's next/font handles font-display: optional and size-adjust descriptors automatically; Vite leaves font loading to you. If you ship a Vite app without a self-host plus font-display: swap, you can pick up a 0.04 to 0.08 CLS regression on first paint. Use the vite-plugin-fonts plugin or self-host with size-adjust in CSS and you'll be back to parity.

INP: Vite wins on small apps, Next.js catches up on large

Interaction to Next Paint is more interesting. Vite SPAs ship less framework code on average -- no React Server Components runtime, no Next.js router shim, no client-side navigation orchestrator -- so the main thread is freer. On the same reference storefront, Vite hit a 75th-percentile INP of 112ms on mobile real-user data, while Next.js App Router hit 148ms.

That advantage shrinks on larger apps. Once your bundle crosses 250KB of JavaScript, the hydration cost differences become noise and the bigger drivers of INP are your own component code: large click handlers, synchronous state updates, expensive list re-renders. At that scale, Next.js's React 19 scheduler and partial pre-rendering for dynamic routes actually pull ahead, because the server tree never executes on the client. We saw Next.js INP under 150ms on a 320KB-bundle app where the Vite equivalent was at 170ms.

If INP is your top priority and your app is small, Vite. If your app is large or your team's discipline around component code is weak, Next.js's server-default model gives you cheaper guard rails.

TTFB: depends entirely on where you deploy

Time to First Byte is determined far more by hosting than by framework. A Next.js app on Vercel's edge network ships TTFB at the 75th percentile around 240ms globally. A Vite SPA hosted as static assets on the same edge network ships TTFB around 90ms -- because there's nothing to compute. But a Next.js app on a single-region origin server in us-east-1 will give a user in Sydney a 600ms TTFB while a CDN-fronted Vite SPA stays under 200ms.

The pattern: if your TTFB is bad, fix your deploy topology before you fix your framework. See our TTFB guide for the cascade. If you're starting fresh and TTFB matters more than first-paint HTML completeness, a Vite SPA on a global CDN is the fastest option you can ship.

Bundle size: closer than you'd think

For our reference storefront on identical React 19 and identical dependencies:

• Vite SPA initial chunk: 117 KB gzipped (React + React DOM + React Router + app code)
• Next.js App Router page: 142 KB gzipped for the route bundle on a fully-interactive page; 62 KB gzipped for a Server Component-only page (image gallery, no client interactivity)

The headline is that a pure SPA and a fully-interactive Next.js page are within 25KB of each other. The structural advantage Next.js gives you is the ability to ship 62KB on the pages that don't need interactivity, which is the majority of pages on most content sites. Across a 20-page site, that compounds.

Developer experience and build performance

This is the place where the two diverge most aggressively. Vite's dev server cold start on our reference storefront is 320ms. Hot module replacement after a component edit is 18ms. Production build is 4.2 seconds.

Next.js dev server cold start is 8.1 seconds. HMR on a Server Component edit is 800ms to 1.4s. Production build is 47 seconds. The Turbopack flag improves dev numbers significantly but is still beta in 15.2.

For pure local-development velocity, Vite wins by a large margin. For production deployment that includes image optimization, route pre-rendering, and ISR cache warming, Next.js does more work and rightfully takes longer.

When to choose Next.js

• Content sites, blogs, marketing pages, documentation
• E-commerce storefronts where SEO and first-paint HTML matter
• Apps where most pages are non-interactive (Server Components shine)
• Teams that want batteries-included framework defaults
• Anything that benefits from streaming SSR or ISR

When to choose Vite

• Internal tools, dashboards, admin panels
• Embedded apps inside other products
• Authenticated SPAs where SEO is irrelevant
• Browser-side prototypes and design tools
• Apps where dev server speed dominates project decisions
• Greenfield projects where you want to pick your router and data layer

Migration paths

Most teams should not migrate. If you're on Pages Router Next.js and you're happy, stay. If you're on a Vite SPA that ships good Core Web Vitals, stay. Migration costs are real and the framework-driven LCP/INP differences are usually smaller than the team-discipline differences.

If you must migrate, the two directions look different. Pages Router Next.js to App Router Next.js is the higher-value migration of the two -- it gives you Server Components, streaming, and the new caching primitives. Migrating from Vite to Next.js is worth it when your product picks up SEO requirements. Migrating from Next.js to Vite is rarely worth it unless you've gone full client-side and the framework's defaults are fighting you.

What's coming in the second half of 2026

Two things to watch. First, the Vite RSC integration: when it stabilizes, the gap between "Vite + a framework" and Next.js narrows significantly, especially around Server Components for non-SEO use cases. Second, Next.js's continued investment in Turbopack -- if dev server cold start drops below 2 seconds, Vite's biggest remaining advantage erodes.

For now, the decision tree is simple: SEO-driven first paint? Next.js. App-shell or embedded experience? Vite. Both can pass Core Web Vitals if you do the basics right. Look at our Next.js vs Remix comparison for a third option that splits the difference, or the React vs Vue benchmark if you're rethinking the runtime layer entirely.