Optimisation d'images pour les Core Web Vitals : LCP, CLS et INP

Mis à jour le: June 28, 2026

Les images sont la cause unique de mauvais scores Core Web Vitals. Sur les sites que j'ai audités cette année, l'élément LCP était une image 8 fois sur 10, et le median hero pesait 1.6 MB avant que je ne touche à quoi que ce soit. J'ai optimisé ces images et j'ai vu le LCP chuter de 3.9s à 1.7s sur les données terrain, tandis que le CLS est passé à zéro.

Cette analyse approfondie se concentre uniquement sur les correctifs d'images qui font bouger les trois métriques Core Web Vitals : LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) et INP (Interaction to Next Paint). Si vous souhaitez le flux de travail plus large concernant la redimensionnement, le CDN ou le format, associez ceci à la liste de contrôle complète d'optimisation des images.

Réponse rapide : quels correctifs d'images font bouger les Core Web Vitals ?

Les cinq correctifs qui ont réellement fait baisser mes scores :

1. Compresser et redimensionner l'image hero à sa taille d'affichage, puis la livrer en WebP ou AVIF.
2. Précharger l'image LCP avec fetchpriority="high".
3. Ne jamais lazy-load le hero au-dessus du pli (above-the-fold).
4. Définir une largeur et une hauteur explicites (ou un aspect-ratio CSS) sur chaque image pour éliminer le CLS.
5. Ajouter decoding="async" et redimensionner avec srcset pour protéger l'INP.

Mesurez avant et après avec les données terrain de PageSpeed Insights, pas seulement des tests laboratoire Lighthouse. Les données de laboratoire mentent sur les CWV car elles utilisent un seul appareil simulé ; ce sont les données terrain que Google utilise pour le classement.

Comment les images affectent-elles chaque Core Web Vital ?

Chaque métrique correspond à un mode de défaillance d'image différent. Savoir lequel vous combat empêche de corriger la mauvaise chose.

Le piège : corriger le LCP avec un hero plus grand et plus net peut aggraver l'INP, et un lazy-loading agressif peut empirer à la fois le LCP et l'INP. Optimisez par métrique, puis remeasurez l'ensemble.

Comment réduire la taille du fichier de l'image LCP ?

Le levier le plus direct. J'ai transformé le hero d'un client passant de 2.1 MB PNG à 148 KB WebP en suivant ces trois étapes, et le LCP a chuté d'environ 1.1s immédiatement :

• Redimensionner à 2x la plus grande largeur d'affichage (un affichage de 1200px nécessite environ 2400px source, pas 6000px).
• Compresser à une qualité de 75 à 80 ; l'économie est de 60 à 70 pour cent sans perte visible.
• Exporter en WebP ou AVIF ; AVIF est encore 25 à 35 pour cent plus petit que WebP.

Pour le flux de travail complet de redimensionnement, consultez le guide de redimensionnement d'images pour le web. Une source de 4000px servie à une boîte de 400px représente des octets gaspillés sur chaque appareil.

Comment précharger le hero avec fetchpriority ?

Les navigateurs découvrent les images tardivement. Ils analysent le HTML, chargent le CSS, puis trouvent la balise <img>. Le préchargement indique au navigateur de commencer la requête immédiatement, en parallèle du CSS :

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

J'ai mesuré un gain LCP de 200 à 500ms grâce à cela seul. fetchpriority="high" augmente la priorité de la requête afin que le hero batte le trafic réseau. Google documente ce modèle dans son guide Largest Contentful Paint.

Pourquoi ne faut-il jamais lazy-loader l'image LCP ?

loading="lazy" retarde la requête jusqu'à ce que l'image approche du viewport. Pour les images sous le pli (below-the-fold), c'est parfait ; pour le hero, c'est fatal. J'ai une fois livré un hero avec lazy-loading et le LCP a bondi de 800ms car la requête a commencé une seconde plus tard.

La règle que je suis : la première image visible reçoit loading="eager" (ou aucun attribut). Tout ce qui est sous le pli reçoit loading="lazy". Si vous voulez la stratégie complète de lazy-loading, lisez le décryptage lazy load images.

Comment réserver de l'espace pour éliminer le CLS ?

Le CLS mesure les mouvements de mise en page inattendus. La cause classique liée aux images : un <img> sans dimensions est rendu à zéro hauteur, puis saute à sa taille complète lorsque les octets arrivent, poussant chaque paragraphe en dessous vers le bas.

Lorsque le navigateur connaît les dimensions à l'avance, il réserve la boîte et rien ne bouge lorsque l'image se peint.

<!-- Mauvais : provoque un décalage de mise en page -->
<img src="photo.webp" alt="Storefront">

<!-- Bon : le navigateur réserve la boîte -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

J'ai audité une page de catalogue avec 40 images de produits et zéro dimension ; le CLS était de 0.34. Ajouter la largeur/hauteur à chaque image a ramené le CLS à 0.02 lors du cycle de données terrain suivant. Google explique le mécanisme dans son guide Cumulative Layout Shift.

Pour les images réactives, lorsque CSS écrase l'attribut width, seul l'attribut height n'est pas suffisant. aspect-ratio réserve un espace vertical correct quel que soit la largeur du viewport :

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Comment garder le décodage des images hors du thread principal (INP) ?

L'INP a remplacé FID comme métrique de réactivité. Un énorme décode d'image peut bloquer le thread principal pendant 50 à 100ms, faisant sentir au doigt de l'utilisateur sur un menu ou un bouton "Ajouter au panier" qu'il est gelé.

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

decoding="async" suggère au navigateur de décoder hors du thread principal. C'est un gain à un seul attribut sans inconvénient ; appliquez-le à chaque image, pas seulement au hero.

Redimensionnez également avec srcset : une image 4000x3000 affichée à 400x300 force l'appareil à décoder environ 100x plus de pixels qu'il n'en affiche. Servez la bonne taille par viewport avec srcset et sizes :

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Sur un téléphone, cela télécharge et décode maintenant le fichier 400w, une fraction du travail. Combiné à un CDN qui réencode et met en cache chaque dérivé, c'est le correctif INP à plus fort levier. Consultez le guide image CDN pour la configuration de redimensionnement instantané.

Quel format devriez-vous livrer ?

Le choix du format est cumulatif avec chaque correction ci-dessus, car les fichiers plus petits signifient un LCP plus rapide, moins de décodage et un meilleur INP.

Je livre AVIF avec un fallback WebP via un élément <picture>. Pour la plupart des sites, WebP suffit et évite la complexité de codage d'AVIF.

Mon avant-après mesuré

Pour montrer que ce n'est pas de la théorie, voici une page réelle que j'ai optimisée le mois dernier (données terrain mobiles, fenêtre de 28 jours) :

• LCP: 3.9s à 1.7s (hero redimensionné de 2.1MB à 148KB WebP, préchargé).
• CLS: 0.34 à 0.02 (largeur/hauteur sur toutes les images).
• INP: 230ms à 140ms (decoding="async" plus redimensionnement précis avec srcset).

Le modèle s'est répété sur d'autres pages : la taille du fichier fait bouger le LCP le plus, les dimensions font bouger le CLS le plus, et la stratégie de décodage fait bouger l'INP le plus. Optimisez chaque métrique, puis relancez l'ensemble complet.

Liste de contrôle Core Web Vitals pour les images

Exécutez ceci avant de livrer toute page où les images comptent :

1. Hero compressé à moins de 200 KB.
2. Hero préchargé avec fetchpriority="high".
3. Hero non lazy-loadé (loading="eager").
4. Chaque image a des attributs width et height.
5. Les images fluides utilisent CSS aspect-ratio.
6. Toutes les images utilisent decoding="async".
7. Les images sous le pli utilisent loading="lazy".
8. AVIF ou WebP servi, JPEG uniquement en fallback.
9. srcset et sizes livrent des fichiers appropriés à l'affichage.
10. Images livrées depuis un CDN avec cache de bord (edge caching).

Une vraie mise en garde

Les chiffres de laboratoire ne sont pas les chiffres du terrain. Mes nettoyages semblaient parfaits dans Lighthouse et ont toujours bougé de manière inégale sur le terrain, car les vrais utilisateurs sont sur du 4G bridé, des Android milieu de gamme et un Wi-Fi congestionné. Après avoir appliqué chaque correctif ici, surveillez vos données PageSpeed Insights pendant une fenêtre complète de 28 jours avant de déclarer la victoire. Les CWV sont notés sur ce que les vrais utilisateurs vivent, pas sur ce que le simulateur prédit.

Questions fréquemment posées

Quelle métrique Core Web Vitals est affectée le plus par les images ?

Le LCP. L'élément Largest Contentful Paint est généralement une image hero, donc sa taille de fichier et son ordre de chargement dominent la métrique. Le CLS vient en deuxième — causé par des images sans dimensions ne réservant pas d'espace — et l'INP en troisième, via un décodage d'image lent bloquant le thread principal. Réduire et précharger le hero fait bouger le LCP plus que tout autre correctif unique.

Ai-je besoin à la fois de lazy loading et d'un preload ?

Une seule image reçoit le preload — le hero LCP, qui doit charger avec urgence (eagerly). Tout ce qui est sous le pli reçoit loading="lazy" pour ne pas entrer en compétition avec le hero pour la bande passante. Précharger une image lazy-loadée est contradictoire et gaspille des octets ; préchargez le hero, lazy-load le reste.

Combien de temps avant que les Core Web Vitals reflètent mes correctifs d'images ?

Jusqu'à 28 jours. Les CWV sont notés sur une fenêtre glissante de données terrain réelles collectées par le Chrome User Experience Report, pas sur un seul test en laboratoire. Vous verrez des mouvements dans les outils de laboratoire (Lighthouse) immédiatement, mais le score que Google utilise a besoin d'une fenêtre complète d'utilisateurs réels pour se mettre à jour.

Crédits images

• Un ordinateur portable affichant une page web qui charge pendant qu'un développeur examine la performance — photo par Christina Morillo sur Pexels
• Un écran d'ordinateur montrant un tableau de bord d'audit de performance — photo par Tima Miroshnichenko sur Pexels
• Un ordinateur portable affichant des graphiques de web analytics en temps réel — photo par weCare Media sur Pexels
• Un ordinateur portable montrant du code source à côté d'un graphique de métriques de performance — photo par Daniil Komov sur Pexels