← Retour aux ressources
// technique · performance

Optimiser les Core Web Vitals sur Next.js

Une page lente coûte des conversions et du référencement. Les Core Web Vitals mesurent le ressenti réel : chargement, stabilité, réactivité. Voici les leviers concrets qui font le plus de différence sur une app Next.js.

Technique29 juil. 2026~8 min · intermédiaire
Next.jsnext/imagenext/fontRSCLCPCLS
// sommaire
01Les trois métriques02LCP : images et fonts03CLS & INP04Le vrai levier : les server components05Sources & ressources
01

Les trois métriques

Google mesure trois choses, et elles pèsent sur ton SEO. Inutile d'optimiser à l'aveugle : on cible celle qui est dans le rouge.

LCPlargest contentful paint : vitesse d’affichage du gros élément (< 2,5 s)
CLScumulative layout shift : la page ne doit pas sauter (< 0,1)
INPinteraction to next paint : réactivité au clic (< 200 ms)
02

LCP : images et fonts

Le LCP est presque toujours plombé par une image trop lourde ou une police qui bloque le rendu. next/image et next/font règlent les deux quasiment tout seuls.

hero.tsxcopier
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.tsxcopier
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>;
}
i

Le principe des images optimisées côté serveur (WebP, tailles multiples) est le même que la Lambda de pourquoi AWS pour un e-commerce.

03

CLS & INP

01
Réserve la place

width/height sur les images et médias : le navigateur garde la place, la page ne saute pas.

02
Fonts en swap

display: swap évite le texte invisible puis le décalage quand la police charge.

03
Moins de JS

L'INP souffre du JS qui bloque le thread. Les server components envoient moins de JS au client.

04
Découpe le code

Charge en dynamique ce qui n'est pas visible au premier écran (modales, graphes).

04

Le vrai levier : les server components

Le plus gros gain sur une app Next.js moderne, c'est d'envoyer moins de JavaScript au navigateur. Les React Server Components rendent le HTML côté serveur et n'hydratent que ce qui est interactif — le reste n'embarque aucun JS client.

✓

Garde ‘use client’ pour les feuilles interactives de l'arbre, pas pour tout. Chaque composant serveur, c'est du JS en moins à télécharger et exécuter.

05

Sources & ressources

01web.dev — Web VitalsLa référence Google : les seuils LCP < 2,5 s, INP < 200 ms, CLS < 0,1, mesurés au 75e centile.↗02web.dev — Optimize Largest Contentful PaintDécompose le LCP en quatre sous-parties (TTFB, délai de chargement, durée, rendu) et explique fetchpriority et le preload.↗03web.dev — Optimize Cumulative Layout ShiftLes causes classiques du CLS : images sans dimensions, pubs et embeds, polices web, animations.↗04web.dev — Optimize Interaction to Next PaintInput delay, processing duration, presentation delay : où va le temps entre le clic et le prochain rendu.↗05Next.js — Image OptimizationLa doc officielle de next/image : tailles responsive, WebP, lazy-loading natif et prévention du layout shift.↗06Next.js — Font Optimizationnext/font self-héberge les polices Google : aucune requête externe, aucun layout shift.↗07Next.js — Optimizing package bundlingAnalyser le bundle et le réduire : optimizePackageImports, travail lourd déplacé côté serveur, lazy-loading.↗

Les Core Web Vitals ne se devinent pas : mesure d'abord (Lighthouse, PageSpeed), corrige la métrique dans le rouge, remesure. Images et fonts optimisées, place réservée, moins de JS grâce aux server components — et une app qui vole, pour l'utilisateur comme pour Google.