Performance Web et Core Web Vitals : Optimiser son Score en 2026

Les Core Web Vitals ne sont plus une suggestion — c’est un facteur de ranking Google et un indicateur direct de l’expérience utilisateur. En 2026, avec INP qui a remplacé FID et des seuils de plus en plus exigeants, optimiser ses métriques de performance est devenu une compétence essentielle.

Les Core Web Vitals en 2026

INP remplace FID : ce qui change

FID (First Input Delay) mesurait le délai du premier clic. Le problème : une page pouvait avoir un excellent FID et être lente sur toutes les interactions suivantes.

INP (Interaction to Next Paint) mesure la latence de toutes les interactions — clics, taps, touches clavier — et retient la pire (au 98e percentile). C’est une métrique bien plus représentative de l’expérience réelle.

MétriqueBonÀ améliorerMauvais
LCP≤ 2.5s≤ 4s> 4s
INP≤ 200ms≤ 500ms> 500ms
CLS≤ 0.1≤ 0.25> 0.25

Les trois métriques en résumé

  • LCP (Largest Contentful Paint) : quand le contenu principal est visible. Cible : ≤ 2.5s.
  • INP (Interaction to Next Paint) : réactivité aux interactions. Cible : ≤ 200ms.
  • CLS (Cumulative Layout Shift) : stabilité visuelle. Cible : ≤ 0.1.

Optimiser le LCP

Le LCP est souvent le métrique le plus impactant sur le SEO. Il mesure quand l’élément le plus grand du viewport (généralement une image hero ou un titre) est peint.

Optimisation des images

Les images sont la cause n°1 de mauvais LCP :

// Next.js — Image optimisée
import Image from 'next/image'

export function HeroImage() {
  return (
    <Image
      src="/hero.jpg"
      alt="Description"
      width={1200}
      height={630}
      priority // Précharge l'image LCP
      sizes="100vw"
    />
  )
}

Règles clés :

  • priority sur l’image LCP (et seulement celle-là)
  • sizes explicite pour générer les bons srcsets
  • Format WebP/AVIF via le pipeline d’optimisation Next.js ou Astro
  • Pas de lazy loading sur l’image LCP — c’est le contenu le plus important

Optimisation des fonts et CSS

Les fonts bloquent le rendu si elles ne sont pas gérées correctement :

/* Préchargement de la font critique */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap; /* Texte visible immédiatement */
  unicode-range: U+0000-00FF; /* Subset latin uniquement */
}
<!-- Dans le <head> -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

En Next.js, next/font gère tout ça automatiquement. Utilisez-le systématiquement au lieu de charger les fonts manuellement.

Le CSS critique doit être inline dans le <head>. Les frameworks modernes le font automatiquement — les React Server Components envoient le CSS nécessaire au premier rendu sans round-trip supplémentaire.

Réduire l’INP

L’INP est la nouvelle métrique la plus difficile à optimiser. Elle requiert une attention constante à la réactivité du JavaScript.

Identifier et splitter les long tasks

Une “long task” est une tâche JavaScript qui bloque le main thread pendant plus de 50ms. Pendant ce temps, les interactions utilisateur sont en file d’attente.

// Mauvais : une seule grosse opération
function processData(items: Item[]) {
  items.forEach(item => {
    heavyComputation(item)  // Bloque le main thread
  })
}

// Bon : découpage en chunks avec yield
async function processDataChunked(items: Item[]) {
  const CHUNK_SIZE = 50
  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE)
    chunk.forEach(item => heavyComputation(item))

    // Yield au navigateur entre les chunks
    await new Promise(resolve => setTimeout(resolve, 0))
  }
}

L’impact des RSC sur l’INP

Les React Server Components réduisent naturellement l’INP en déplaçant le code côté serveur. Moins de JavaScript client = moins de long tasks = meilleur INP.

Le même principe s’applique avec la Composition API de Vue.js : en déplaçant les computations dans des computed efficaces plutôt que des watchers coûteux, on réduit le travail du main thread.

Stabiliser le CLS

Le CLS mesure les décalages de layout inattendus. Un bouton qui se déplace quand une image charge au-dessus, un header qui saute quand une pub apparaît — tout ça nuit à l’expérience.

Les causes principales :

  1. Images sans dimensions : toujours spécifier width et height
  2. Fonts qui causent un reflow : utiliser font-display: swap et size-adjust
  3. Contenu injecté dynamiquement : réserver l’espace avec des skeletons
  4. Ads et embeds tiers : containeriser avec des dimensions fixes
/* Réserver l'espace pour une image responsive */
.image-container {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #f0f0f0; /* Placeholder visuel */
}

Outillage de mesure

En développement :

  • Chrome DevTools → Performance tab → INP overlay
  • Web Vitals extension Chrome
  • Lighthouse en mode navigation et timespan

En production (données terrain) :

  • Google Search Console → Core Web Vitals report
  • Chrome User Experience Report (CrUX)
  • RUM (Real User Monitoring) : Vercel Analytics, web-vitals library

En CI :

  • Lighthouse CI dans GitHub Actions
  • Budget de performance dans le next.config.js
// web-vitals pour le monitoring terrain
import { onINP, onLCP, onCLS } from 'web-vitals'

onLCP(metric => sendToAnalytics('LCP', metric))
onINP(metric => sendToAnalytics('INP', metric))
onCLS(metric => sendToAnalytics('CLS', metric))

Les performances sont aussi liées à l’infrastructure. Dans un monorepo Turborepo, le partage de composants optimisés entre apps (design system) garantit des performances cohérentes sur tous les frontends.

En résumé

Les Core Web Vitals en 2026, c’est :

  • LCP : prioriser l’image hero, optimiser fonts et CSS critique
  • INP : chasser les long tasks, profiter des RSC, yield au navigateur
  • CLS : dimensions explicites, réservation d’espace, font-display: swap

La performance n’est pas un one-shot. C’est un monitoring continu avec des budgets de performance intégrés dans la CI. Mesurez en terrain réel (CrUX), pas seulement en lab (Lighthouse).

KD

Kevin De Vaubree

Développeur Full-Stack Senior