Core Web Vitals for Next.js

What real Next.js sites measure

Framework-maker sites make a clean A/B test, and we measured both with Lighthouse 13 (mobile emulation) in July 2026. nextjs.org scored 87/100 — LCP 2.2 s, inside the 2.5 s threshold, TBT 436 ms, CLS 0 — a content-focused Next.js site doing what the framework promises. vercel.com scored 41/100: LCP 5.0 s and TBT 3,106 ms, the cost of a marketing site dense with animated demos, third-party scripts, and client-side interactivity — on the same framework, from the same company. CLS was zero on both, and that is representative: layout stability is close to a solved problem in Next.js, because next/image and next/font reserve space by design. The two numbers bracket the Next.js reality — the framework gives you an 87; your client bundle decides how much of it you keep.

Ship less JavaScript: server components and the client boundary

With the App Router, every component is a React Server Component until you say otherwise — its code never ships to the browser. Total Blocking Time regressions come from where you draw the “use client” boundary: mark a layout or page client-side and everything it imports joins the bundle. Push “use client” to the leaves — the button, the search box, the carousel — and keep data fetching and markup on the server.

Make the cost visible. next build prints first-load JS per route: treat anything over ~150KB as a budget breach and investigate with @next/bundle-analyzer. The usual suspects are heavyweight dependencies imported into shared layouts (date libraries, chart kits, icon barrels — mitigate icon and utility barrels with optimizePackageImports in next.config). For genuinely heavy below-the-fold widgets — editors, maps, charts — use next/dynamic so they load after the critical path, with ssr: false when they are client-only.

next/image, priority, and the LCP

next/image solves format (AVIF/WebP via the formats config), sizing (srcset generation), and lazy loading — but it lazy-loads everything by default, including your hero. The single most impactful line on many Next.js pages is adding priority to the LCP image: it disables lazy loading and emits a preload so the fetch starts immediately. Audit every above-the-fold image for it, and only the above-the-fold ones — priority on offscreen images wastes bandwidth the hero needs.

The second-most impactful attribute is sizes. Without it, the browser assumes the image spans the full viewport and picks a needlessly large srcset candidate. A hero that renders at 100vw on mobile but 50vw on desktop should say so: sizes="(max-width: 768px) 100vw, 50vw". For remote images, configure remotePatterns so the optimizer can process them instead of passing originals through untouched.

Fonts, hydration, and layout shift

CLS on Next.js sites rarely comes from images (next/image reserves space via width/height) — it comes from fonts and post-hydration content. next/font eliminates the font half: it self-hosts Google or local fonts, removes the third-party request, and applies size-adjust metrics to the fallback font so the swap doesn’t reflow the page. If you still load fonts via a <link> to Google Fonts, migrating to next/font is a mechanical, high-yield change.

The other half is content that appears after hydration: client components that render nothing on the server (the classic useEffect-gated auth or theme check), ad slots, and data that pops in. Reserve the space — explicit dimensions or CSS aspect-ratio on containers — or stream the real content from the server inside a Suspense boundary with a correctly sized fallback, so the layout is stable from first paint.

Caching and TTFB: fetch, ISR, and PPR

A Server Component that awaits an uncached fetch puts your API’s latency inside your TTFB — every visitor pays it. Decide per data source how fresh is fresh enough: fetch with next: { revalidate: 3600 } (or route-level ISR via export const revalidate) serves cached HTML instantly and refreshes in the background. Content that changes on publish rather than on a clock should use on-demand revalidation with revalidateTag from your CMS webhook.

For pages that mix static shell with per-user content, Partial Prerendering (PPR) serves the static shell from the edge immediately and streams the dynamic holes — you keep a fast LCP without giving up personalization. And check where your functions run: data fetched from a single-region backend is fastest with compute in that same region; moving rendering to the edge while the database stays in one region often makes TTFB worse, not better.

Measuring Next.js correctly

Never judge performance on next dev — development builds skip minification, disable optimizations, and hydrate with extra instrumentation; they are routinely 5-10x slower than production. Measure next build + next start locally, or better, the deployed production URL, since platform-level compression, HTTP/2+, and CDN behavior are part of the result.

Preview deployments carry a footgun worth knowing: hosting platforms typically serve them with an X-Robots-Tag: noindex header (correctly — you don’t want previews indexed). If you copy headers or middleware from preview configurations to production, or test SEO on a preview URL, you will see noindex findings that don’t apply to production — and conversely, a misconfigured production deployment that keeps noindex is a catastrophic, silent SEO failure. Audit the production domain explicitly.