Optimiser les images pour les Core Web Vitals

Comment les images affectent les Core Web Vitals

Les images sont responsables du Largest Contentful Paint sur 85 % des pages desktop et 76 % des pages mobiles, selon le Web Almanac 2025. Cela fait de l'optimisation des images l'action la plus impactante que vous puissiez réaliser pour vos Core Web Vitals. Mais les images n'affectent pas seulement la vitesse de chargement. Elles peuvent causer des décalages de mise en page (layout shifts) et, sur les pages riches en images, même ralentir l'interactivité. Ce guide couvre tous les aspects : des attributs HTML et du préchargement aux images responsives, en passant par les formats modernes et les stratégies que vous devriez appliquer à chaque image de votre page.

Dernière révision par Arjen Karel en février 2026

Quels Core Web Vitals les images peuvent-elles affecter ?

Vous pourriez être surpris d'apprendre que les images peuvent affecter tous les Core Web Vitals. Les images, si elles sont mises en file d'attente pour le téléchargement tardivement lors du rendu ou si elles sont tout simplement trop volumineuses, entraîneront généralement un score LCP élevé. Si les dimensions de l'image ne sont pas définies ou changent pendant la phase de chargement, les images peuvent également affecter le score CLS. Enfin, si le décodage de l'image nécessite trop de travail sur le thread principal (main thread), elles peuvent même affecter l'INP. Examinons cela de plus près :

Largest Contentful Paint

Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour que le plus grand élément de la page (comme une image ou une vidéo) devienne visible pour l'utilisateur. Selon le Web Almanac 2025, les images sont l'élément LCP sur 85 % des pages desktop et 76 % des pages mobiles. Si une image est mise en file d'attente trop tard ou prend trop de temps à charger, cela peut ralentir considérablement le score LCP de la page.

Cumulative Layout Shift

Le Cumulative Layout Shift (CLS) mesure à quel point le contenu d'une page se décale pendant son chargement. Les images peuvent causer des layout shifts si elles ne sont pas correctement dimensionnées ou si elles sont insérées dans la page après qu'elle a déjà été chargée, provoquant le déplacement d'autres éléments. Le Web Almanac 2025 rapporte que 65 % des pages desktop ont encore au moins une image sans dimensions explicites.

Interaction to Next Paint (INP)

Les images peuvent également impacter l'Interaction to Next Paint (INP), qui mesure le temps qu'il faut à une page pour répondre visuellement après une interaction de l'utilisateur. S'il y a trop de grandes images devant être décodées, la page peut mettre plus de temps à répondre aux interactions des utilisateurs, conduisant à un mauvais score INP. Cela est particulièrement courant sur les pages de liste de produits où des centaines d'images se disputent les ressources.

Étape 1 : Optimiser l'élément image HTML pour la vitesse

L'attribut src

Spécifie l'URL de l'image. Cette propriété est essentielle, car elle indique au navigateur où trouver l'image.

Les attributs width et height

Spécifient la largeur et la hauteur de l'image en pixels. Ces propriétés sont importantes pour rendre correctement l'image sur la page, car elles définissent la taille du conteneur de l'image et la façon dont l'image s'y intègre. Définissez toujours à la fois la largeur (width) et la hauteur (height) pour prévenir les layout shifts.

L'attribut alt

Spécifie un texte alternatif pour l'image si elle ne peut pas être affichée. C'est important pour des raisons d'accessibilité, car cela aide les utilisateurs malvoyants à comprendre de quoi parle l'image. C'est également important pour l'optimisation des moteurs de recherche (SEO), car les moteurs de recherche utilisent le texte alternatif pour comprendre le contenu de l'image.

L'attribut loading (lazy loading)

Spécifie la manière dont le navigateur doit charger l'image (lazy, eager ou auto). Cette propriété est importante pour améliorer les performances de la page, car elle permet aux images d'être chargées de manière asynchrone et uniquement lorsqu'elles sont nécessaires. Ne définissez jamais loading="lazy" sur l'image LCP. Selon le Web Almanac 2025, 16 % des pages chargent encore leur image LCP en lazy-load, ce qui est l'une des erreurs de performance les plus courantes sur le web.

L'attribut srcset

L'attribut sizes

L'attribut decoding

L'attribut fetchpriority

L'attribut fetchpriority spécifie la priorité de récupération d'une ressource par rapport aux autres ressources de la page. L'attribut peut prendre l'une des trois valeurs suivantes : "high", "low" ou "auto". Une ressource avec une priorité élevée (high) est chargée avant les ressources avec des priorités plus basses. En 2026, fetchpriority est pris en charge dans tous les navigateurs modernes (Chrome 102+, Safari 17.2+, Firefox 132+, Edge 102+) et peut être utilisé en production en toute sécurité. Seulement 17 % des pages l'utilisent sur leur image LCP, ce qui signifie que la grande majorité des sites passent à côté d'une victoire facile.

Étape 2 : Assurez-vous que l'image est mise en file d'attente pour le téléchargement le plus tôt possible

La deuxième chose à faire, une fois que vous avez optimisé le HTML, est d'examiner la planification des images. Dans de nombreux cas, le plus grand goulot d'étranglement concernant les images affectant la métrique LCP est la planification tardive. Si un navigateur a l'occasion de télécharger l'élément LCP tôt dans le processus de rendu, l'image sera disponible pour le navigateur le plus tôt possible et le navigateur pourra commencer à peindre cet élément tôt dans le processus de rendu.

Cela semble simple, non ? Eh bien, comment s'assurer que l'image est mise en file d'attente pour le téléchargement le plus tôt possible ?

Précharger l'élément LCP

La manière la plus efficace de garantir un téléchargement précoce est de précharger l'image. Le préchargement de l'image se fait avec une simple balise au début de l'élément <head>. Par exemple :

<link rel="preload" as="image" href="image.jpg">

Cette simple balise indiquera au navigateur que nous aurons besoin de "image.jpg" très bientôt et le navigateur commencera à télécharger ce fichier immédiatement.

Sur les sites surveillés par CoreDash, 83 % des chargements de page avec une image LCP préchargée obtiennent un score « bon » (good) sur le LCP, contre 65 % sans préchargement.

Chargement immédiat (eager load) de l'élément LCP

Utiliser un fetchpriority élevé (high)

Si, pour une raison quelconque, vous ne pouvez pas précharger l'élément LCP, assurez-vous au moins que l'élément a l'attribut fetchpriority défini sur high. Cela indiquera au navigateur qu'une image est importante pour la page et le navigateur la téléchargera avec une priorité élevée. Veuillez noter que l'utilisation de fetchpriority="high" n'est généralement pas aussi efficace que le préchargement d'une image !

Étape 3 : Assurez-vous que l'image est téléchargée le plus rapidement possible

La troisième chose à faire est de s'assurer que vous ne gaspillez pas de précieuses ressources réseau sur des images plus volumineuses qu'elles ne devraient l'être. Vous pouvez le faire en utilisant des images responsives, en utilisant la compression et en utilisant de nouveaux formats d'image plus rapides.

Images responsives

Voici une image responsive utilisant srcset et sizes :

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450" alt="Descriptive alt text">

Le navigateur choisit l'image la plus appropriée en fonction de la largeur du viewport. Pour les images sous la ligne de flottaison (below-the-fold) en lazy-load, vous pouvez également utiliser sizes="auto" (pris en charge dans Chrome 126+ et Edge 126+), ce qui permet au navigateur de calculer automatiquement la bonne taille en fonction de la mise en page CSS de l'image.

Compression d'image

Formats d'image nouveaux et plus rapides

Les images sont souvent l'une des ressources les plus volumineuses sur une page web, et elles peuvent considérablement ralentir la vitesse de chargement d'une page si elles ne sont pas optimisées. Les formats d'image modernes comme le WebP et l'AVIF offrent une compression nettement meilleure que le JPEG tout en conservant la même qualité visuelle.

Le WebP est pris en charge par la quasi-totalité des navigateurs (~99 % de support mondial) et réduit généralement la taille des fichiers de 25 à 35 % par rapport au JPEG. L'AVIF va encore plus loin avec des économies de plus de 50 % par rapport au JPEG et bénéficie désormais d'un support de 94,7 % des navigateurs (Chrome 85+, Firefox 93+, Safari 16.4+). Malgré cela, le Web Almanac 2025 montre que l'AVIF n'est utilisé que pour 0,7 % des images LCP, tandis que le JPEG domine toujours à 57 %. Il s'agit d'une opportunité massive.

Utilisez l'élément <picture> pour servir le meilleur format pris en charge par chaque navigateur :

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" width="800" height="450" alt="Descriptive alt text">
</picture>

Le navigateur essaiera d'abord l'AVIF, se repliera sur le WebP, et utilisera le JPEG en dernier recours. Si vous êtes curieux de connaître l'avenir, lisez l'article sur le JPEG XL et son statut de prise en charge actuel par les navigateurs.

Étape 4 : Éliminer les layout shifts !

Les images qui changent de taille pendant leur chargement provoqueront un layout shift. C'est aussi simple que cela. Cette section couvre les 3 raisons les plus courantes. Pour le guide complet sur toutes les causes de CLS liées aux images et aux médias (y compris les vidéos, les iframes, la direction artistique, les incohérences d'images responsives et le lazy loading), consultez Comment les images et les médias causent des Layout Shifts.

1. Dimensions d'image manquantes

2. Problèmes de style

Généralement, on empêche les images de devenir plus grandes que le viewport grâce à une astuce CSS simple :

img{
   max-width:100%;
   height:auto;
}

C'est une excellente astuce et vous devriez l'utiliser. Malheureusement, je vois régulièrement des variantes de cette astuce qui causent bel et bien un layout shift. Par exemple en ajoutant width:auto :

img{
   max-width:100%;
   height:auto;
   width:auto;
}

Cela fera en sorte que n'importe quelle image sera rendue avec un width et un height en auto. Cela signifie généralement que le navigateur rendra l'image à 0x0px avant que l'image ne soit téléchargée.

3. Placeholders

Certains scripts de lazy loading basés sur JavaScript utilisent des placeholders. Si vous utilisez une astuce CSS comme le max-width:100% et height:auto mentionnés ci-dessus, alors la hauteur auto (auto height) du placeholder carré ne correspondra pas à l'attribut height de l'image. Concrètement, l'image sera d'abord rendue avec le placeholder carré à 720x720, et lorsque l'image finale aura été téléchargée, elle sera rendue à 720x180 :

<img
  src="1x1placeholder.png"
  data-src="hero.png"
  width="720"
  height="180"
  style="height:auto;max-width:100%"
>

Étape 5 : Protéger le thread principal (main thread)

La prochaine chose à vérifier est de ne pas avoir trop d'images décodées sur le thread principal (main thread) en même temps. En général, ce ne sera pas un problème, mais je l'ai vu se produire de nombreuses fois sur des pages de liste de produits (où parfois jusqu'à 500 images se disputent les ressources !).

L'astuce consiste à ajouter decoding="async" à toutes les images pour s'assurer qu'elles puissent être décodées sur un thread séparé. Essayez également d'éviter qu'autant d'images ne soient décodées d'un seul coup en ajoutant loading="lazy" à toutes les images sous la ligne de flottaison (below-the-fold) et cachées.

Étape 6 : Choisissez la bonne stratégie pour chaque image !

Stratégies d'image pour l'élément LCP

L'élément LCP est généralement l'élément visuel le plus important. Nous devons donc vraiment prioriser celui-ci.

1. Préchargez l'image tôt dans le head de la page avec ce code : <link rel="preload" as="image" href="path-to-img.png">
2. Indiquez au navigateur que cette image ne doit pas être chargée en lazy-load en définissant loading="eager" ou en omettant l'attribut loading
3. Suggérez au navigateur que cette image doit être téléchargée avec une priorité élevée en utilisant fetchpriority="high" (si vous préchargez l'image, vous pouvez ignorer cette partie)
4. Définissez decoding="sync" puisque cet élément est tellement important que nous voulons le décoder sur le thread principal (main thread)

Voici un exemple complet d'une image LCP optimisée et responsive avec préchargement :

<!-- In <head> -->
<link rel="preload" as="image" href="hero-800.jpg"
  imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  imagesizes="(max-width: 600px) 100vw, 800px">

<!-- In <body> -->
<img src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450" alt="Descriptive alt text"
  fetchpriority="high" decoding="sync">

Stratégie d'image pour les logos et autres images visibles (non-LCP)

Les images visibles doivent être chargées assez tôt pendant le chargement de la page, mais de préférence après l'élément LCP. Nous pouvons y parvenir en préchargeant l'élément LCP. Cela donnera à ces images visibles leur ordre de téléchargement naturel et correct.

1. Indiquez au navigateur que cette image ne doit pas être chargée en lazy-load en définissant loading="eager" ou en omettant l'attribut loading
2. Définissez decoding="async" puisque cet élément peut être décodé en toute sécurité en dehors du thread principal (main thread) !

Stratégie d'image pour les images sous la ligne de flottaison (below-the-fold)

Toutes les images sous la ligne de flottaison (below-the-fold) doivent être chargées en lazy-load. C'est aussi simple que cela ! Il n'y a pas d'exceptions !

1. Indiquez au navigateur que cette image doit être chargée en lazy-load en définissant loading="lazy"
2. Définissez decoding="async" puisque cet élément peut être décodé en toute sécurité en dehors du thread principal (main thread) !

Éviter les images d'arrière-plan (background images)

Si vous utilisez des images d'arrière-plan (background images), vous devez reconsidérer la question. Les background images ne peuvent pas être chargées en lazy-load, vous ne pouvez pas contrôler la propriété decoding et vous ne pouvez pas définir le fetchpriority. Les background images ne sont généralement pas responsives, ce qui vous coûtera probablement beaucoup de bande passante. Mais surtout, les background images sont généralement découvertes après que le navigateur a téléchargé les fichiers CSS. Ce n'est presque jamais le bon moment pour déclencher un téléchargement d'image ! Lisez pourquoi les background images sont néfastes et comment différer les background images lorsque vous n'avez pas le choix.

Vous pouvez utiliser des balises d'images normales en combinaison avec le CSS object-fit:cover pour que les images normales se comportent comme des background images !

Surveiller l'impact avec le Real User Monitoring

Après avoir appliqué ces optimisations, vérifiez qu'elles améliorent réellement les performances pour les utilisateurs réels. Les outils de laboratoire comme Lighthouse peuvent confirmer que vos modifications sont correctes, mais seul le Real User Monitoring vous montre l'impact réel sur vos visiteurs. Suivez votre LCP, CLS et INP au fil du temps pour confirmer que vos optimisations d'images fonctionnent comme prévu.