Blog · 2 mai 2026 · 7 min de lecture

Optimiser les images pour les Core Web Vitals : LCP, CLS, INP

Comment les images influencent vos Core Web Vitals et les techniques concrètes (format moderne, dimensions, fetchpriority, preload) pour débloquer un score de 90+.

performance core-web-vitals seo

Les Core Web Vitals sont depuis 2021 un signal de classement officiel de Google. Sur la grande majorité des sites, ce sont les images qui plombent le score. Voici comment elles agissent sur chaque métrique et les techniques éprouvées pour passer la barre des 90 sur Lighthouse.

Les trois métriques en 30 secondes

LCP — Largest Contentful Paint : temps avant que le plus gros élément visible (souvent une image) soit affiché. Cible : < 2,5 s.
CLS — Cumulative Layout Shift : à quel point la mise en page « bouge » pendant le chargement. Cible : < 0,1.
INP — Interaction to Next Paint : temps de réponse aux interactions utilisateur. Cible : < 200 ms. (Remplace le FID depuis mars 2024.)

Sur les trois, les images jouent un rôle majeur. Détaillons.

LCP — la métrique reine

Identifier l’image LCP

Sur 80 % des sites, l’élément LCP est une image (la hero image, la photo de produit, la vignette d’article au-dessus du pli). Ouvrez Lighthouse en mode mobile, regardez la section « Largest Contentful Paint element » : elle pointe précisément le coupable.

Le poids de l’image LCP

Plus l’image est lourde, plus son téléchargement prend du temps. Les ordres de grandeur :

Réseau	Bande passante effective	Poids confortable pour LCP < 2,5 s
4G médian	~1,5 Mo/s	< 200 Ko
4G dégradé / mobile faible	~500 Ko/s	< 100 Ko
3G	~150 Ko/s	< 30 Ko (rare en France)

En pratique, viser une image LCP < 200 Ko sur mobile est un bon objectif universel. Au-delà, le LCP commence à déraper même sur de bonnes connexions.

Format moderne pour le LCP

Le format compte autant que le poids brut :

JPG qualité 80 — référence historique, mais pas optimal en 2026.
WebP qualité 80 — −30 % vs JPG, recommandation par défaut.
AVIF qualité 70 — −50 % vs JPG, idéal pour le LCP critique.

Notre outil de compression propose les trois formats. Pour une hero image typique, passer de JPG 80 à AVIF 70 fait gagner facilement 400 ms de LCP sur mobile 4G.

`fetchpriority="high"`

Par défaut, le navigateur télécharge les images dans l’ordre du DOM. La balise fetchpriority="high" lui indique : « cette image-là, charge-la en premier ».

<img src="hero.avif"
     alt="..."
     width="1200"
     height="800"
     fetchpriority="high"
     decoding="async">

Sur l’image LCP uniquement. Sur toutes les images, ça n’a aucun effet.

Preload de l’image LCP

Pour aller plus loin, vous pouvez précharger l’image dans le <head> avant même que le navigateur ne parse votre <img> :

<link rel="preload"
      as="image"
      href="/hero.avif"
      type="image/avif"
      imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
      imagesizes="100vw">

Sur un site rapide, ça peut faire gagner 100 à 300 ms de LCP supplémentaires.

Pas de lazy loading sur l’image LCP

Erreur fréquente : appliquer loading="lazy" à toutes les images, y compris celle au-dessus du pli. Résultat : le navigateur attend d’avoir parsé suffisamment de CSS et de JS pour décider que l’image est visible, ce qui retarde le téléchargement et explose le LCP.

Règle simple : loading="lazy" sur tout, sauf l’image LCP, qui reçoit loading="eager" (la valeur par défaut, mais autant l’expliciter).

CLS — l’art de ne pas faire bouger la page

Le piège des images sans dimensions

Quand le navigateur rencontre une <img> sans width ni height, il réserve 0 pixel pour elle. Quand l’image arrive, elle pousse tout ce qui est en dessous : c’est un layout shift, et votre CLS grimpe.

La règle d’or : toute balise <img> doit avoir des attributs width et height explicites, dans la valeur en pixels intrinsèques de l’image (pas la taille d’affichage).

<!-- ✅ correct -->
<img src="photo.webp" alt="..." width="1200" height="800">

<!-- ❌ déclencheur de CLS -->
<img src="photo.webp" alt="...">

Le navigateur calcule l’aspect-ratio (1200/800 = 1.5) et réserve la bonne hauteur même quand votre CSS contraint la largeur à 100 %.

Aspect-ratio CSS

Pour les cas où vous ne connaissez pas les dimensions à l’avance (galerie dynamique, contenu généré), utilisez aspect-ratio en CSS sur le conteneur :

.product-image {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
}

Le navigateur réserve la hauteur calculée à partir du ratio, même avant que l’image soit téléchargée.

Placeholders pour les images au-delà du pli

Pour les galeries longues, utiliser un placeholder (couleur dominante en background-color, ou LQIP — Low Quality Image Placeholder) évite le « flash » de fond blanc et améliore la perception de la stabilité.

INP — quand les images consomment le CPU

L’INP mesure le temps entre une interaction utilisateur (clic, tap, frappe) et le prochain paint. Les images peuvent l’impacter de plusieurs manières :

Décodage bloquant

Décoder une grosse image AVIF prend du CPU. Si plusieurs images se décodent en parallèle au moment où l’utilisateur interagit, le thread principal est saturé et l’INP grimpe.

Solution : ajouter decoding="async" sur les images, et préférer AVIF aux gros JPG décodés simultanément.

<img src="photo.avif" alt="..." width="800" height="600" decoding="async">

Multiplicité des images

Charger 50 images en même temps consomme la bande passante ET le CPU. Le loading="lazy" natif n’est pas qu’une question de bande passante : il libère aussi le CPU pour les interactions.

Animations GIF / vidéo en lecture

Les vieux GIF animés sont des tueurs d’INP : ils consomment du CPU en continu. Si vous en avez, convertissez-les en WebP animé ou en MP4 silencieux avec playsinline : 5 à 10 fois moins de CPU.

Stratégies cumulatives

Pour un site web moderne, voici la pile complète qui fonctionne :

1. Compression + format moderne

<picture>
  <source type="image/avif" srcset="/photo-800.avif 800w, /photo-1600.avif 1600w" sizes="(max-width: 800px) 100vw, 1200px">
  <source type="image/webp" srcset="/photo-800.webp 800w, /photo-1600.webp 1600w" sizes="(max-width: 800px) 100vw, 1200px">
  <img src="/photo-1600.jpg"
       alt="..."
       width="1600"
       height="1067"
       loading="lazy"
       decoding="async">
</picture>

AVIF en priorité, WebP en repli, JPG en dernier.
Plusieurs résolutions via srcset, le navigateur choisit la bonne.
Dimensions explicites sur le <img> final.

2. Lazy loading natif

loading="lazy" sur tout sauf l’image LCP. Le navigateur ne charge l’image que quand elle approche du viewport.

3. CDN avec optimisation

Cloudflare Polish, BunnyCDN Optimizer ou ImageKit/Cloudinary servent automatiquement la bonne version selon le client (taille d’écran, support format). Zéro configuration côté serveur.

4. Preload sélectif

<link rel="preload" as="image"> uniquement pour l’image LCP. Les autres images n’en ont pas besoin.

5. Compression côté CMS

Si vous êtes sur WordPress, voir notre guide WordPress pour la chaîne complète plugin + WebP Express.

Outils de mesure

PageSpeed Insights (pagespeed.web.dev) — score Lighthouse + données CrUX (utilisateurs réels).
Search Console → Expérience sur la page — données réelles de vos vrais visiteurs sur 28 jours glissants.
WebPageTest — analyse multi-localisation, vue waterfall détaillée.
Lighthouse CI — automatiser les mesures dans votre pipeline de déploiement.

À surveiller en priorité : la donnée mobile sur 4G médiane. C’est ce que voient la majorité de vos visiteurs réels, et c’est ce que Google utilise pour son classement.

Recettes concrètes

Hero image d’une page d’accueil

Format AVIF qualité 70 (fallback WebP).
< 200 Ko quelle que soit la résolution.
fetchpriority="high", pas de lazy loading.
Dimensions explicites.
Optionnel : <link rel="preload"> dans le head.

Photo d’article de blog

Format WebP qualité 85.
< 100 Ko pour la photo principale.
loading="lazy", decoding="async".
Largeur servie en srcset adaptée au layout (souvent 800-1200 px max).

Galerie photo (e-commerce, portfolio)

Format WebP qualité 80, AVIF si CPU côté serveur le permet.
Miniatures < 30 Ko, photo détail < 200 Ko.
loading="lazy" sur tout, decoding="async".
Aspect-ratio CSS pour éviter le CLS.
Placeholder (couleur dominante) pendant le chargement.

Image embarquée dans un mailing transactionnel

JPG qualité 75 (compatibilité maximale email).
< 100 Ko.
Dimensions explicites pour éviter les sauts dans le client mail.

Conclusion

Optimiser les images pour les Core Web Vitals tient en cinq règles, dans cet ordre d’impact :

Compresser au bon poids (200 Ko grand max sur mobile).
Format moderne (AVIF ou WebP), avec fallback.
Dimensions explicites sur toutes les <img> (anti-CLS).
Lazy loading sauf LCP, et fetchpriority="high" sur l’image LCP.
Décodage asynchrone (decoding="async") pour libérer le thread principal.

Suivre ces cinq règles fait passer un score Lighthouse Performance de 50-60 à 90+ sur la majorité des sites, sans toucher au CSS ni au JavaScript. Vous pouvez appliquer dès maintenant la première étape avec notre compresseur d’images — il gère AVIF, WebP, et le redimensionnement, sans envoyer vos fichiers sur un serveur.