TechnicalMay 7, 2026~8 min · intermediate

Optimizing Core Web Vitals on Next.js

A slow page costs conversions and SEO. Core Web Vitals measure the real feel: loading, stability, responsiveness. Here are the concrete levers that make the biggest difference on a Next.js app.

StackNext.jsnext/imagenext/fontRSCLCPCLS

The three metrics

Google measures three things, and they weigh on your SEO. No point optimizing blindly: target the one in the red.

LCPlargest contentful paint: how fast the big element shows (< 2.5s)

CLScumulative layout shift: the page must not jump (< 0.1)

INPinteraction to next paint: click responsiveness (< 200ms)

LCP: images and fonts

LCP is almost always dragged down by a too-heavy image or a render-blocking font. next/image and next/font fix both almost automatically.

hero.tsxTSCopy

import Image from "next/image";
// next/image : lazy-loading, tailles responsive, format moderne automatiques
<Image src="/hero.jpg" alt="" width={1200} height={630}
       priority sizes="(max-width:768px) 100vw, 1200px" />
// "priority" pour l'image du LCP (au-dessus de la ligne de flottaison)

layout.tsxTSCopy

import { Inter } from "next/font/google";
// next/font : la police est self-hostee et pre-chargee -> zero CLS, zero requete externe
const inter = Inter({ subsets: ["latin"], display: "swap" });
export default function RootLayout({ children }) {
  return <html className={inter.className}><body>{children}</body></html>;
}

Worth noting

The principle of server-side optimized images (WebP, multiple sizes) is the same as the Lambda in why AWS for an e-commerce.

CLS & INP

Reserve the space

width/height on images and media: the browser keeps the space, the page doesn’t jump.

Fonts on swap

display: swap avoids invisible text then the shift when the font loads.

Less JS

INP suffers from thread-blocking JS. Server components ship less JS to the client.

Split the code

Dynamically load what isn’t visible on first screen (modals, charts).

The real lever: server components

The biggest gain on a modern Next.js app is shipping less JavaScript to the browser. React Server Components render HTML server-side and only hydrate what’s interactive — the rest ships no client JS.

Good reflex

Keep ‘use client’ for the interactive leaves of the tree, not for everything. Every server component is less JS to download and run.

Sources & further reading

01web.dev — Web VitalsThe Google reference: the LCP < 2.5s, INP < 200ms, CLS < 0.1 thresholds, measured at the 75th percentile.↗02web.dev — Optimize Largest Contentful PaintBreaks LCP into four subparts (TTFB, load delay, load duration, render delay) and covers fetchpriority and preloading.↗03web.dev — Optimize Cumulative Layout ShiftThe classic CLS causes: images without dimensions, ads and embeds, web fonts, animations.↗04web.dev — Optimize Interaction to Next PaintInput delay, processing duration, presentation delay: where the time goes between the click and the next paint.↗05Next.js — Image OptimizationThe official next/image docs: responsive sizing, WebP, native lazy-loading and layout-shift prevention.↗06Next.js — Font Optimizationnext/font self-hosts Google fonts: no external request, no layout shift.↗07Next.js — Optimizing package bundlingAnalyze and shrink the bundle: optimizePackageImports, heavy work moved server-side, lazy-loading.↗

In short

Core Web Vitals aren't guessed: measure first (Lighthouse, PageSpeed), fix the metric in the red, remeasure. Optimized images and fonts, reserved space, less JS thanks to server components — and an app that flies, for users and Google alike.

web.dev — Core Web Vitals ↗