Corriger les hero images lentes & Core Web Vitals

Comment corriger les hero images lentes : en bref

Les hero images sont de grandes images en haut d'une page web. Ces hero images entraîneront un long Largest Contentful Paint si elles ne sont pas optimisées. 9 sites sur 10 que l'on me demande d'optimiser auront des problèmes avec les hero images. Dans cet article, je vais vous montrer différentes techniques pour accélérer les hero images.

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

Qu'est-ce qu'une hero image ?

Une Hero Image, parfois appelée 'hero header', est une grande image avec du texte, souvent placée en haut d'une page web. Une hero image sert de premier aperçu de votre entreprise et de votre offre pour l'utilisateur en raison de son emplacement bien en vue vers le haut d'une page web qui s'étend généralement sur toute la largeur.

Un petit rappel : Les hero images, les Core Web Vitals et le Largest Contentful Paint : 
En raison de la taille de la hero image (elle s'étend généralement sur toute la largeur de la page et une bonne partie de la hauteur de la fenêtre d'affichage visible), cet élément deviendra l'élément Largest Contentful Paint dans presque tous les cas.
Le Largest Contentful Paint est une métrique importante des Core Web Vitals. L'élément largest contentful paint est le plus grand élément qui sera affiché dans la fenêtre d'affichage visible du navigateur. Selon le Web Almanac 2025, sur 76 % des pages mobiles, l'élément LCP est une image. Seules 62 % des origines mobiles réussissent actuellement le LCP. Corrigez la hero image et vous corrigez le LCP pour la plupart des sites.
Parce que les images non optimisées ont tendance à utiliser beaucoup de bande passante et prennent donc beaucoup de temps à charger, les hero images causent souvent de mauvaises métriques Largest Contentful Paint.

Optimiser la hero image et le Largest Contentful Paint

Il existe de nombreuses techniques pour optimiser les hero images et le Largest Contentful Paint. Je vais vous les expliquer ici. La plupart des techniques peuvent être combinées pour de meilleurs résultats !

1. Faire un preload de la hero image ou envoyer des 103 Early Hints

Lorsque vous souhaitez qu'un élément soit disponible le plus tôt possible dans le navigateur, vous pouvez faire un preload de cet élément. Le preloading implique l'utilisation de resource hints. Les resource hints indiquent au navigateur quelque chose sur la priorité d'un élément et déclencheront un téléchargement très précoce de cette ressource. Selon le Web Almanac 2025, seules 2,1 % des pages font un preload de leur image LCP. C'est une énorme opportunité manquée.

<link
  rel="preload"
  as="image"
  href="wolf.jpg"
  fetchpriority="high"
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w"
  imagesizes="50vw">

Les 103 Early Hints permettent aux serveurs d'envoyer des resource hints avant la réponse HTML finale. Le navigateur peut commencer le preloading de la hero image pendant que le serveur génère encore la page. Chrome, Edge et Firefox prennent tous en charge le preloading via les Early Hints. Safari prend en charge le preconnect mais pas encore le preload via les Early Hints. Pour plus de détails sur la configuration, lisez le guide complet des 103 Early Hints.

Sur les sites surveillés par CoreDash, les pages avec une image LCP en preloading ont un taux de « bon » LCP de 81 % contre 64 % sans preloading. Pour une présentation complète de toutes les options de preloading, voir comment faire un preload de l'image LCP.

2. Utiliser fetchpriority="high" sur la hero image

L'attribut fetchpriority indique au navigateur quelles ressources sont les plus importantes. Définir fetchpriority="high" sur votre hero image augmente sa priorité de téléchargement au-dessus des autres images et des ressources concurrentes telles que les scripts et les polices.

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">

Selon le Web Almanac 2025, seules 17 % des pages définissent fetchpriority="high" sur leur image LCP. Cela signifie que 83 % des sites passent à côté de gains de performance faciles.

Vous pouvez également ajouter fetchpriority="high" au lien de preload illustré ci-dessus. N'utilisez fetchpriority="high" que sur une seule image par page. Plusieurs images à priorité élevée sont en concurrence les unes avec les autres et annulent l'avantage. Pour en savoir plus sur la façon dont les navigateurs hiérarchisent les ressources, lisez le guide des Core Web Vitals sur la priorisation des ressources.

3. Compresser la hero image et utiliser des formats next-gen

La compression des images réduira la taille de leur fichier. Les fichiers de plus petite taille utiliseront moins de bande passante et seront disponibles pour le navigateur le plus tôt possible. La compression des images peut être effectuée dans votre éditeur de photos, dans votre CMS (astuce : votre développeur peut définir le niveau de compression WordPress) ou avec un outil de compression d'image en ligne.

La plupart des hero images lentes sont plus lentes qu'elles ne devraient l'être car elles sont servies dans le « mauvais » conteneur d'image comme PNG ou JPEG. Il existe des alternatives beaucoup plus rapides à JPEG et PNG comme WebP et AVIF. Selon le Web Almanac 2025, 57 % des images LCP sont encore servies en JPEG et 26 % en PNG, tandis que seulement 11 % utilisent WebP et moins de 1 % utilisent AVIF.

Pour de nombreux systèmes CMS, il existe des plugins de conversion qui convertiront vos images aux formats next-gen. Lorsque la conversion d'image est difficile à intégrer dans votre site Web, un CDN avec prise en charge de la conversion d'image pourrait être la solution que vous recherchez. Pour un aperçu complet des techniques d'optimisation d'image, consultez optimiser les images pour les Core Web Vitals.

4. N'utilisez pas de background images, utilisez des responsive images normales

Votre hero image doit être une image normale et jamais une background image. La façon habituelle de créer des hero images est d'ajouter une background image au conteneur hero et de définir le background-size de ce conteneur sur cover. Cela garantira que la hero image s'adaptera à l'écran dans tous les cas.

Les background images sont mauvaises pour les Core Web Vitals. Souvenez-vous de ça ! Apprenez-en plus sur pourquoi les background images sont mauvaises pour les performances. Si vous ne pouvez pas éviter complètement les background images, vous pouvez au moins différer les background images qui sont en dessous de la ligne de flottaison.

• Les background images sont chargées avec une priorité inférieure
• Les background images ne sont pas responsive (à moins que vous ne vouliez vraiment compliquer les choses)
• Les background images peuvent causer des problèmes de Core Web Vitals avec la plupart des bibliothèques de lazy loading

La façon dont je procède consiste à ajouter une image normale dans une position absolue et à définir la propriété object-fit de cette image sur cover. Une fois que j'ai changé la background image en une image normale, je peux commencer à utiliser des responsive images. Si vous utilisez Elementor, découvrez comment corriger les hero images Elementor.

Les responsive images signifient que pour différents appareils (mobile, ordinateur de bureau, tablette), une version différente de la même hero image peut être envoyée. Pour un ordinateur de bureau, je peux envoyer une énorme hero image de 1920x1280 tandis que pour un appareil mobile, je n'aurais besoin d'envoyer qu'une hero image plus petite de 400x266 pixels. C'est 25 fois moins de données !

• Les hero images sont désormais chargées avec une priorité plus élevée
• Je peux maintenant utiliser des responsive images pour la hero image

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source
        type="image/webp"
        media="(max-width:540px)"
        srcset="herosm.webp">
    </source>
    <img fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. Servir les hero images depuis le domaine principal et envisager un CDN

Trop souvent, je vois l'image largest contentful paint servie à partir d'un domaine différent, par exemple 'static.mydomain.com'. Ces sous-domaines pointent souvent vers un CDN. Bien que j'encourage l'utilisation d'un CDN (voir ci-dessous), une configuration comme celle-ci n'est pas recommandée. L'image sur le sous-domaine nécessite une nouvelle connexion à un nouveau serveur. Les nouvelles connexions sont coûteuses et prendront un temps précieux. Lorsque l'image est servie à partir du domaine principal (www.mydomain.com par exemple), les images peuvent être récupérées beaucoup plus rapidement via la connexion serveur déjà établie.

Lorsqu'il est configuré sur le domaine principal, un CDN peut offrir une énorme augmentation de vitesse. Surtout lorsque votre site est visité du monde entier. Un CDN dispose de serveurs stratégiquement placés dans le monde entier où vos ressources statiques (comme les images) sont mises en cache pour des temps de réponse locaux rapides. Cela signifie que les données n'ont pas à voyager dans le monde entier, mais peuvent être servies à partir d'un serveur edge local. Pour un guide de configuration complet, consultez comment configurer Cloudflare pour les Core Web Vitals.

6. Éviter le lazy loading de la hero image

Assurez-vous qu'aucun lazy loading n'est appliqué à votre hero image. Les hero images doivent toujours se charger en eager.

De nombreux sites, en particulier les sites WordPress, utilisent une sorte de plugin pagespeed WordPress comme WP Rocket ou WP Core Web Vitals. Ces plugins font généralement un excellent travail pour accélérer les sites lents, mais ils ne peuvent pas réparer la stupidité :-)

Ces plugins vont lazy load les images qui semblent être de bonnes candidates pour le lazy loading. Si la hero image n'est pas une image eager, ces plugins feront probablement aussi un lazy loading de la hero image.

Cela entraînera, au mieux, un léger retard dans les métriques LCP. Au pire, en particulier lorsque le lazy loading basé sur JavaScript est activé, cela entraînera un retard plus important. Selon le Web Almanac 2025, environ 17 % des pages font un lazy loading de leur image LCP. Cela représente 17 % des sites qui détériorent activement leur LCP. Si Lighthouse vous avertit à ce sujet, voyez comment corriger l'avertissement de l'image LCP chargée en lazy loading.

Faire charger les images en eager est simple. Ajoutez simplement loading="eager" à l'image. Notez que eager est en fait la valeur par défaut du navigateur. L'omission complète de l'attribut loading a le même effet. Le véritable objectif est de s'assurer que la hero image n'a PAS loading="lazy". L'ajout explicite de eager reste utile comme signal d'intention, en particulier sur les sites où un CMS ou un plugin peut appliquer automatiquement le lazy loading.

<img src="hero.webp" loading="eager" fetchpriority="high" width="800" height="400">

7. Éviter les layout shifts causés par la hero image

Un autre problème courant que je vois avec les bannières hero et les hero images est qu'elles provoquent un énorme layout shift. Ces layout shifts peuvent se produire pour différentes raisons.

• L'élément hero est créé avec JavaScript. Certains plugins hero et constructeurs de pages comme Elementor sont connus pour s'appuyer sur JavaScript pour afficher le contenu hero. Bien qu'il n'y ait rien de mal avec JavaScript, assurez-vous que l'élément hero s'affiche de la même manière sans JavaScript.
• Les polices dans l'élément hero provoquent un layout shift. L'élément hero contient généralement un grand texte avec un appel à l'action et un slogan. Assurez-vous que ces grandes polices ne provoquent pas de layout shift.
• Dimensions d'image manquantes. Lorsque la hero image n'est pas une image de couverture (que ce soit en tant que background image ou en tant qu'image positionnée en absolu), les dimensions d'image manquantes (largeur et hauteur) provoqueront certainement un grand layout shift.

Bien que la correction du layout shift n'améliorera pas le Largest Contentful Paint, elle améliorera les Core Web Vitals de la page. Pour plus d'informations sur la façon de corriger le layout shift, veuillez lire le guide détaillé sur la façon de corriger le Cumulative Layout Shift !

8. Utiliser le chargement en 2 étapes pour améliorer les Core Web Vitals de la hero

Le chargement en 2 étapes est une technique rapide que nous appliquons à toutes nos images. Nous servons d'abord une image de très basse qualité qui devrait se télécharger beaucoup plus tôt que la grande image de haute qualité. Une fois que l'image de basse qualité a été affichée à l'écran, le navigateur est déclenché pour récupérer l'image de haute qualité en arrière-plan. Une fois que l'image de haute qualité a été téléchargée, l'image de basse qualité sera remplacée par l'image de haute qualité.

Il existe 3 méthodes de chargement en 2 étapes. Les deux premières sont des méthodes que vous devriez considérer. La dernière est celle que vous ne devriez pas faire.

1. Chargement complet en 2 étapes

Avec un chargement complet en 2 étapes, la première image de basse qualité a exactement les mêmes dimensions (largeur et hauteur) que l'image originale de haute qualité.

Le résultat de ce chargement en 2 étapes est que l'élément largest contentful paint sera l'image de basse qualité beaucoup plus rapide (qui sera ensuite permutée en différé). La permutation de l'image se fera si rapidement qu'un visiteur occasionnel ne s'en rendra probablement jamais compte. Le résultat de cette technique est que le LCP est affiché beaucoup plus tôt, la page apparaît « prête » beaucoup plus tôt, ce qui contribue à une bien meilleure expérience utilisateur et à l'amélioration des Core Web Vitals.

2. Espaces réservés (placeholders) inline plus petits

Le plus petit placeholder est une technique plutôt cool qui a un inconvénient : elle n'améliore pas les Core Web Vitals. Cela reste une excellente technique car elle améliore l'expérience utilisateur.

L'idée de base est la même que pour la technique de chargement en 2 étapes, mais au lieu d'une image de basse qualité avec les mêmes dimensions, une image beaucoup plus petite avec des dimensions plus petites est placée inline via une data URI. La hero image finale qui sera l'image largest contentful paint est toujours téléchargée en arrière-plan. Cette astuce n'améliorera pas le Largest Contentful Paint mais fera apparaître la page prête encore plus rapidement que la technique de chargement en 2 étapes.

3. Placeholders transparents

Une technique de chargement en 2 étapes courante et une méthode pour inciter le navigateur à envoyer une métrique Largest Contentful Paint précoce consistent à utiliser des éléments SVG transparents. Ces éléments sont petits et peuvent être placés inline, tout comme le petit placeholder inline.

L'utilisation d'un élément SVG inline et sa permutation sont en fait une technique de lazy loading. L'avantage de cette technique est qu'elle fonctionne sur tous les navigateurs. 

Le lazy loading, bien sûr, ne devrait être appliqué qu'aux éléments en dehors de la fenêtre d'affichage. Dans ce cas, l'élément SVG transparent ne fera que retarder la véritable hero image et n'a aucune valeur ajoutée pour votre visiteur. Même si les métriques de paint peuvent être excellentes, l'UX de la page va en fait s'aggraver.

C'est pourquoi la hero image doit toujours être chargée en eager sans astuces qui causent une mauvaise UX.

Mettre tout cela ensemble

Voici à quoi ressemble une hero image optimisée lorsque vous combinez preloading, fetchpriority, responsive images et eager loading :

<!-- Dans le <head> -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- Dans le <body> -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Texte alternatif descriptif">

Après avoir effectué des modifications, vérifiez l'amélioration avec le Real User Monitoring. Lighthouse vous donne un aperçu de laboratoire, mais Google se base sur les données de terrain réelles des utilisateurs collectées au cours des 28 jours précédents.