Guide technique 2026

Optimiser ses images pour les Core Web Vitals et le LCP

Vous avez optimisé vos images, ajouté du lazy loading partout, et votre score LCP est toujours mauvais. Et si c'était justement le lazy loading le problème ? La plupart des erreurs sur les Core Web Vitals liés aux images ne viennent pas d'un oubli de compression : elles viennent d'un attribut appliqué au mauvais endroit.

10 min de lecture Optimiser ses images pour les Core Web Vitals et le LCP

En résumé

Pour améliorer vos Core Web Vitals liés aux images : convertissez votre image hero en WebP ou AVIF, ajoutez explicitement ses attributs width et height pour éviter le CLS, et utilisez fetchpriority='high' sur l'image LCP principale. N'utilisez jamais loading='lazy' sur une image visible sans scroll : c'est l'erreur qui dégrade le plus le LCP.

Ce qu'il faut retenir

✓ L'image LCP est souvent la plus grande image visible au chargement : l'identifier avant toute optimisation.
✓ loading='lazy' sur l'image LCP pénalise directement le score : c'est l'erreur la plus fréquente.
✓ WebP réduit le poids de 25 à 35 % vs JPEG, mais sans fetchpriority, le gain reste partiel.
✓ width et height explicites sur toutes les images éliminent le CLS dès le déploiement.
✓ PageSpeed Insights distingue les données terrain (CrUX) des mesures laboratoire (Lighthouse) : les deux comptent.

Ce que Google mesure vraiment : LCP, CLS, INP et le rôle des images

Les Core Web Vitals sont trois métriques que Google utilise pour évaluer l’expérience utilisateur d’une page. Les images en affectent deux directement.

Déf

LCP (Largest Contentful Paint)

Temps écoulé avant que le plus grand élément visible de la page soit affiché. Dans la majorité des cas, cet élément est une image. Google considère un LCP ≤ 2,5 secondes comme 'bon'.

Aussi appelé : Largest Contentful Paint, temps de rendu du plus grand élément

Ex : Sur une page avec une image hero en haut, le LCP mesure le temps avant que cette image soit entièrement affichée à l'écran.

Déf

CLS (Cumulative Layout Shift)

Mesure des déplacements visuels inattendus pendant le chargement. Une image dont les dimensions ne sont pas déclarées pousse le contenu vers le bas quand elle s'affiche. Google considère un CLS ≤ 0,1 comme 'bon'.

Aussi appelé : Cumulative Layout Shift, stabilité visuelle

Ex : Un article dont les images n'ont pas de width/height déclarés saute visuellement pendant le chargement : chaque image qui arrive repousse le texte.

L’INP (Interaction to Next Paint) mesure la réactivité aux clics et saisies : les images l’affectent peu directement, sauf si leur décodage mobilise le thread principal pendant plusieurs centaines de millisecondes. Pour des images de taille raisonnable, cela reste marginal.

En pratique : la quasi-totalité des problèmes de Core Web Vitals liés aux images se concentrent sur le LCP et le CLS. Ce sont les deux métriques à traiter en priorité.

Identifier son image LCP : la première étape souvent sautée

Avant d’optimiser quoi que ce soit, il faut savoir quelle image Google regarde. Ce n’est pas toujours évident.

Dans PageSpeed Insights, la section “Diagnostics” identifie l’élément LCP et indique son délai de chargement. Dans Chrome DevTools, l’onglet Performance affiche le marqueur LCP et met l’élément en surbrillance dans le DOM après analyse.

L’image LCP est le plus souvent :

La photo hero en haut de page sur un site vitrine
La première image produit sur une fiche e-commerce
Une bannière ou illustration principale sur un article de blog

Si votre page n’a pas d’image au-dessus de la ligne de flottaison, l’élément LCP peut être un bloc de texte : dans ce cas, les optimisations images auront un impact limité sur le LCP.

Connaître cet élément change l’ordre de priorité. Toutes les images d’une page ne méritent pas les mêmes traitements : l’image LCP mérite une attention particulière que les autres n’ont pas.

Format et compression : l’impact réel de WebP et AVIF sur le LCP

Un fichier plus léger se télécharge plus vite. Un téléchargement plus rapide contribue à un LCP plus bas. Le lien est direct, mais insuffisant seul.

WebP réduit le poids d’une photo de 25 à 35 % par rapport à un JPEG à qualité visuelle équivalente. AVIF va plus loin (35 à 50 % de réduction selon le contenu), mais son support navigateur reste en dessous de WebP.

2,5 s

seuil LCP 'Good' selon Google

Google web.dev, Core Web Vitals

97 %

support navigateur WebP en 2026

Can I Use, mai 2026

~94 %

support navigateur AVIF en 2026

Can I Use, mai 2026

❌ Idée reçue

Passer ses images en WebP suffit pour améliorer son LCP.

✅ Réalité

WebP réduit le poids du fichier, et un fichier plus léger se télécharge plus vite. Mais si l'image n'est pas découverte tôt par le navigateur (absence de preload) ou si loading='lazy' est actif, le gain de format sera annulé par le délai de découverte de la ressource. Format et chargement sont deux variables indépendantes.

Source : Google web.dev, Optimize LCP

En pratique : convertir l’image LCP en WebP lossy est une bonne étape, pas une solution complète. Elle doit être combinée avec les techniques de chargement des sections suivantes pour avoir un impact mesurable sur le score.

Pour les conversions concrètes (outils, seuils de qualité recommandés, cas particuliers), notre guide des formats image JPEG, PNG, WebP couvre les détails par cas d’usage.

Dimensions explicites : deux attributs qui éliminent le CLS

Le CLS provoqué par les images a une cause unique : le navigateur ne connaît pas les dimensions de l’image avant de l’avoir téléchargée. Il affiche le contenu environnant, puis quand l’image arrive, il repousse tout ce qui suit.

La solution est deux attributs HTML :

<img src="hero.webp" width="1200" height="630" alt="Description" />

width et height permettent au navigateur de calculer le ratio de l’image et de réserver l’espace correspondant avant le téléchargement. Le contenu ne bouge pas. Le CLS tombe à zéro sur ces images.

Pour les images responsives qui changent de taille selon l’écran, la propriété CSS aspect-ratio remplit le même rôle :

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

Ces deux attributs (width + height en HTML, ou aspect-ratio en CSS) sont la correction la plus rapide à déployer sur un site existant. L’impact sur le CLS est immédiat.

loading=“lazy” : quand c’est une erreur (et sur quelles images l’éviter)

loading="lazy" est une instruction utile pour les images en bas de page : elle diffère leur téléchargement jusqu’à ce qu’elles s’approchent du viewport. Moins de requêtes au chargement initial, page plus légère perçue par le navigateur.

Le problème : beaucoup de développeurs l’appliquent sur toutes les images sans exception. Y compris sur l’image hero, qui est l’élément LCP.

loading='lazy' sur l'image LCP : l'erreur la plus coûteuse

Si votre image hero ou votre première image produit a l’attribut loading=“lazy”, vous demandez au navigateur de différer le chargement de l’élément que Google mesure en priorité. Le navigateur attend que l’image soit dans le viewport pour la télécharger, mais elle l’est dès le premier instant. Le délai artificiel se traduit directement en LCP dégradé.

La règle est simple : loading="lazy" est adapté aux images situées sous la ligne de flottaison, celles que l’utilisateur ne voit pas immédiatement sans scroller. Sur toutes les images visibles sans scroll (above-the-fold), l’attribut est contre-productif.

En pratique : retirez loading="lazy" de l’image LCP identifiée à l’étape précédente. Laissez-le sur toutes les autres images qui ne sont pas immédiatement visibles.

fetchpriority et preload : précharger l’image LCP pour gagner des décimales

Le navigateur charge les ressources dans un ordre qu’il détermine seul. Par défaut, les images ne sont pas prioritaires : il commence par le HTML, le CSS critique, puis le JavaScript avant de s’occuper des images. L’image LCP peut ainsi attendre plusieurs centaines de millisecondes avant d’être téléchargée.

fetchpriority="high" change cet ordre : il indique au navigateur que cette ressource est critique et doit être téléchargée en priorité.

Précharger l'image LCP : mise en œuvre

1

Identifier l'image LCP dans PageSpeed Insights

Lancez une analyse sur votre page. Dans la section 'Opportunités' ou 'Diagnostics', PageSpeed Insights identifie l'élément LCP et son URL. Notez le chemin exact du fichier image.

Dans Chrome DevTools > Performance, cliquez sur 'Record' puis rechargez la page : le marqueur LCP apparaît sur la timeline avec l'élément mis en surbrillance.
2

Ajouter fetchpriority='high' sur la balise img

Sur la balise <img> de l'image LCP, ajoutez l'attribut fetchpriority='high'. Retirez loading='lazy' si présent. Ce seul attribut peut réduire le LCP de plusieurs centaines de millisecondes sur un réseau mobile.

Ne pas appliquer fetchpriority='high' à plusieurs images : le signal perd de son efficacité si trop d'éléments sont marqués prioritaires.
3

Ajouter un preload dans le <head> pour les images critiques en CSS

Si l'image LCP est chargée via CSS (background-image) plutôt qu'une balise <img>, le navigateur ne la découvre qu'après avoir parsé et appliqué la feuille de styles. Un <link rel='preload'> dans le <head> anticipe ce délai.

Exemple : <link rel='preload' as='image' href='/hero.webp' fetchpriority='high' />
4

Vérifier l'impact dans PageSpeed Insights

Relancez l'analyse. Comparez le LCP avant et après dans les deux colonnes : données terrain (CrUX) et données laboratoire (Lighthouse). Le changement en laboratoire est immédiat, le changement terrain prend 28 jours de collecte Chrome UX Report.

Si le LCP stagne, vérifiez que l'image est effectivement servie depuis un CDN ou hébergement rapide : le TTFB (Time to First Byte) du serveur peut être le facteur limitant.

fetchpriority est disponible depuis Chrome 101, Firefox 132 et Safari 17.2. Pour les navigateurs plus anciens, l’attribut est simplement ignoré, aucun risque de régression.

Images responsives : srcset et sizes pour servir le bon format au bon écran

Un smartphone affiche votre image hero sur 390 pixels de large. Sans srcset, il télécharge la même image que le moniteur 1920px, potentiellement 4 à 6 fois plus lourde que nécessaire.

srcset déclare plusieurs versions de l’image à différentes résolutions :

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 50vw"
  width="800"
  height="450"
  fetchpriority="high"
  alt="Description de l'image"
/>

sizes indique au navigateur quelle largeur l’image occupera selon la taille de l’écran, avant qu’il ait rendu la page. Sans sizes, le navigateur suppose que l’image fait 100 % de la largeur de la fenêtre et peut télécharger une version inutilement grande.

En pratique : pour l’image LCP, proposer trois variantes (400 px, 800 px, 1600 px) couvre la quasi-totalité des cas mobiles, tablettes et desktop. La génération de ces variantes se fait en amont, lors de l’export ou via une pipeline d’images.

Mesurer et valider avec PageSpeed Insights, Lighthouse et CrUX

PageSpeed Insights affiche deux types de données sur une même page. La distinction est importante.

Données terrain (CrUX) : collectées sur de vrais utilisateurs Chrome visitant votre URL. Elles reflètent la réalité de votre audience, connexions mobiles, appareils variés, cache rempli ou vide. Ce sont ces données qui impactent le ranking Google.

Données laboratoire (Lighthouse) : mesure synthétique simulant un appareil mobile sur une connexion lente. Utile pour diagnostiquer et comparer avant/après, mais pas représentative du terrain.

Google Search Console > Rapport “Core Web Vitals” regroupe les données terrain URL par URL sur 28 jours glissants. C’est le panneau à surveiller après avoir déployé des corrections : les changements n’y apparaissent pas avant plusieurs semaines de collecte.

Lighthouse est l’outil de débogage, CrUX est la mesure finale. Optimiser jusqu’à 100 en Lighthouse sans améliorer le CrUX est possible, et inversement. Les deux métriques ont leur rôle.

Questions fréquentes

Qu'est-ce que le LCP et pourquoi les images l'affectent-elles ? ▾

Le LCP (Largest Contentful Paint) mesure le temps avant que le plus grand élément visible de la page soit affiché. Dans la majorité des pages web, cet élément est une image, souvent l'image hero ou la première image produit. Google considère un LCP ≤ 2,5 secondes comme 'bon'. Un LCP lent impacte à la fois l'expérience utilisateur et le positionnement dans les résultats de recherche.

Comment savoir quelle image est mon image LCP ? ▾

Lancez une analyse dans PageSpeed Insights sur l'URL concernée. La section 'Diagnostics' identifie l'élément LCP et son chemin exact. Autre méthode : Chrome DevTools > onglet Performance > enregistrer un chargement de page. Le marqueur LCP sur la timeline désigne l'élément avec sa durée de rendu.

Est-ce que passer en WebP améliore automatiquement les Core Web Vitals ? ▾

Partiellement. WebP réduit le poids du fichier de 25 à 35 % vs JPEG à qualité équivalente, ce qui accélère le téléchargement. Mais si l'image n'est pas préchargée correctement ou si loading='lazy' est actif sur l'image LCP, le gain de format est annulé par le délai de découverte de la ressource. Format et chargement sont deux variables indépendantes.

loading='lazy' est-il toujours une bonne pratique ? ▾

Non, selon la position de l'image. Sur les images situées sous la ligne de flottaison (non visibles sans scroller), loading='lazy' est bénéfique : il réduit les requêtes au chargement initial. Sur les images visibles immédiatement, notamment l'image LCP, il est contre-productif et dégrade directement le score LCP.

Qu'est-ce que fetchpriority='high' et à quoi ça sert ? ▾

fetchpriority='high' est un attribut HTML qui indique au navigateur de prioriser le téléchargement de cette ressource par rapport aux autres. Sur l'image LCP, il permet de réduire le délai entre le début du chargement de la page et le téléchargement de l'image. L'attribut est supporté depuis Chrome 101, Firefox 132 et Safari 17.2 : les navigateurs plus anciens l'ignorent sans erreur.

Comment les images provoquent-elles du CLS ? ▾

Quand le navigateur ne connaît pas les dimensions d'une image avant de la télécharger, il n'y réserve pas de place dans le layout. Quand l'image arrive, elle pousse le contenu environnant vers le bas : c'est un Layout Shift. La solution : déclarer explicitement width et height sur toutes les balises <img>, ou utiliser aspect-ratio en CSS pour les images responsives.

Quelle différence entre les données Lighthouse et les données terrain dans PageSpeed Insights ? ▾

Lighthouse est une mesure de laboratoire : elle simule un appareil mobile sur une connexion lente dans des conditions contrôlées. Les données terrain (CrUX) proviennent de vrais utilisateurs Chrome sur votre URL sur les 28 derniers jours. Le ranking Google utilise les données terrain, pas Lighthouse. Lighthouse est utile pour diagnostiquer et comparer avant/après ; CrUX est la mesure qui compte pour le SEO.

Compressez et convertissez vos images en WebP directement dans le navigateur

100% local, gratuit, sans compte. Aucune image ne quitte votre appareil.

Essayer Impmage

GlitchGhost

Développeur indépendant

Développeur spécialisé performance web et optimisation d'images. Créateur d'Impmage.

Développeur webSpécialiste performanceCréateur d'Impmage

Cet article vous a aidé ? : X LinkedIn WhatsApp