Fixing Core Web Vitals in Next.js and Nuxt

Which framework decision affects which metric

The thresholds are the same as everywhere: LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less, at the 75th percentile of real visits. Framework sites often pass LCP comfortably on desktop and fail INP on mobile, because the cost of hydration lands on the visitor's processor.

Choosing a rendering mode per route

Both frameworks let you decide per route whether HTML is built once at build time, rebuilt in the background on a timer, or built fresh for each request. The right answer depends on how often the content changes and whether it differs between visitors.

Next.js App Router

// app/products/[slug]/page.tsx
export const revalidate = 3600;   // rebuild at most once an hour

export async function generateStaticParams() {
  const products = await getTopProducts();
  return products.map(p => ({ slug: p.slug }));
}

export default async function ProductPage({ params }) {
  const { slug } = await params;
  const product = await getProduct(slug);
  return <ProductView product={product} />;
}

Watch out for things that silently switch a route to per-request rendering, such as reading cookies or headers in a layout shared by every page. Check the build output, which marks each route as static or dynamic, after every significant change. Caching defaults have changed between major Next.js versions, so confirm the behaviour in the documentation for the version you run.

Nuxt

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/about': { prerender: true },
    '/blog/**': { isr: 3600 },
    '/products/**': { swr: 600 },
    '/account/**': { ssr: false }
  }
});

How isr and swr behave depends on where you deploy, since the cache lives in the hosting platform or in Nuxt's server. Check the response headers on a deployed page to confirm pages are actually being served from cache.

The fix, step by step

Framework code for images, fonts and scripts

Hero image and font in Next.js

// app/layout.tsx
import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'], display: 'swap' });

export default function RootLayout({ children }) {
  return (
    <html lang="en-GB" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

// app/page.tsx
import Image from 'next/image';
import hero from './hero-kitchen.jpg';

export default function Home() {
  return (
    <Image
      src={hero}
      alt="Fitted oak kitchen with island"
      sizes="100vw"
      loading="eager"
      fetchPriority="high"
    />
  );
}

A statically imported image gives next/image its width and height automatically. Older versions use a priority prop for the hero, and newer versions have changed this prop, so check the image documentation for your version; setting eager loading and high fetch priority directly works as shown.

Third-party script in Next.js

import Script from 'next/script';

<Script src="https://widgets.example.com/chat.js" strategy="lazyOnload" />

Hero image and a lazy widget in Nuxt

<template>
  <NuxtImg
    src="/img/hero-kitchen.jpg"
    width="1600" height="900"
    sizes="100vw md:100vw lg:1600px"
    alt="Fitted oak kitchen with island"
    loading="eager"
    fetchpriority="high"
    preload
  />
  <LazyReviewCarousel v-if="showReviews" />
</template>

Prefixing a component name with Lazy makes Nuxt split it into its own chunk and load it only when it is rendered. Recent Nuxt versions can also delay hydration of a component until it is visible or the browser is idle, which is useful for heavy widgets further down the page.

Pushing the client boundary down

// Before: the whole product page is client code
'use client';
export default function ProductPage() { /* ... */ }

// After: page stays on the server, only the button hydrates
// app/products/[slug]/page.tsx (server)
import AddToBasket from './AddToBasket';
export default async function ProductPage({ params }) {
  const { slug } = await params;
  const product = await getProduct(slug);
  return (
    <article>
      <h1>{product.name}</h1>
      <ProductDetails product={product} />
      <AddToBasket id={product.id} />
    </article>
  );
}

// app/products/[slug]/AddToBasket.tsx
'use client';
export default function AddToBasket({ id }) { /* state and handlers */ }

Hydration and INP

Hydration is the step where the framework runs in the browser, attaches event handlers and makes server-rendered HTML interactive. Until it finishes, taps may not work, and while it runs it occupies the main thread in long tasks. On a mid-range phone, hydrating a large page can take long enough that a visitor's first tap waits, which shows up as input delay in INP.

• Less client code, less hydration. Server components in Next.js send no component code to the browser at all. Every component you keep on the server reduces the work.
• Hydration mismatches. If the server and client render different HTML, for example because of dates, random values or reading window during render, the framework may re-render parts of the page, which costs time and can cause layout shift. Fix the warnings in the console rather than suppressing them.
• Large lists. Hydrating hundreds of interactive list items is expensive. Paginate, virtualise, or render the list on the server and hydrate only the controls.
• Expensive state updates. In React, mark non-urgent updates such as filtering with startTransition so input stays responsive.

Edge cases

• Client-side navigations. After the first page, moving between pages in a single-page app does not trigger a new full load, and Chrome's field data is attributed mainly to the landing page. INP and CLS continue to accumulate across the session, so slow interactions on later views still count against the page where the visit started.
• Prefetching. Both frameworks prefetch linked routes. On pages with hundreds of links this can compete with the page's own resources on slow connections; limit prefetching on very link-heavy pages if you see it in the Network panel.
• Serverless cold starts. Per-request routes on serverless hosting can be slow on the first request after a quiet period. Static and incremental routes avoid this.
• Middleware on every request. Middleware that runs for every route, including static assets, adds time to each response. Limit it with a matcher.
• Image optimisation on the fly. The first request for each image size is generated on demand and can be slow. Configure a sensible set of sizes and make sure optimised images are cached.

Keeping framework sites fast

• Review the build output for routes that changed from static to dynamic.
• Set a bundle budget and check the analyser on every pull request that adds a dependency.
• Keep route-level real-user reporting so a regression on one route type is visible quickly.
• Make server components the default in code review and ask for a reason each time 'use client' is added.

For the individual metrics, see poor INP, slow TTFB and CLS in React and Next.js. Image specifics are in images in Next.js.