Optimiser le LCP d’une image hero : la méthode de Julien Jimenez

L’image hero, cette grande photo qui ouvre la page, est souvent ce que le visiteur attend en premier, et très souvent l’élément retenu par le Largest Contentful Paint, l’indicateur de Google qui date l’apparition du contenu principal. Pour être jugé bon, le LCP doit rester inférieur ou égal à 2,5 secondes au 75^e centile des visites.

Comment optimiser le LCP d’une image hero sans la sacrifier ? Ni en la compressant jusqu’au flou, ni en la remplaçant par un aplat de couleur : en comprenant où part le temps, puis en agissant dans le bon ordre. Découverte, priorité, poids, rendu, serveur : c’est l’ordre de ce décryptage.

Avant tout réglage : identifier l’élément LCP et lire ses phases

Identifier l’élément LCP réel de chaque gabarit

Première vérification, souvent sautée : l’image hero est-elle vraiment l’élément LCP ? Selon l’écran, ce peut être le titre, un bloc de texte ou une autre image ; sur mobile, un grand titre l’emporte parfois sur une photo recadrée. Trois sources permettent de trancher :

le panneau Performance des outils de développement de Chrome, qui marque le LCP sur la chronologie et désigne l’élément ;
le diagnostic de PageSpeed Insights, qui indique l’élément LCP du test de laboratoire ;
une mesure chez vos visiteurs, qui révèle l’élément réellement retenu sur leurs appareils.

On raisonne par gabarit (accueil, catégorie, fiche, article, page de destination) : chaque modèle de page a son élément LCP typique, et c’est le modèle qui se corrige.

Les phases du LCP, du premier octet à l’affichage

Le LCP d’une image se décompose en quatre phases successives. Les connaître évite de compresser une image dont le vrai problème est d’être découverte trop tard.

Décomposition du LCP d’une image hero

Premier octet: Le serveur envoie le début du HTML.
Délai de chargement: L’image attend d’être découverte, puis demandée.
Durée de chargement: Le fichier de l’image est téléchargé.
Délai de rendu: L’image arrivée est enfin affichée.

Cas type, proportions d’exemple : une image découverte tard passe plus de temps à attendre qu’à se télécharger.

Les quatre phases du LCP d’une image
Phase	Ce qu’elle mesure	Symptôme typique	Levier principal
Premier octet	De la navigation au premier octet du HTML	Serveur lent, redirections	Cache, CDN
Délai de chargement	Du premier octet au départ de l’image	Image découverte tard	Image dans le HTML, `fetchpriority`
Durée de chargement	Le téléchargement de l’image	Fichier lourd ou surdimensionné	AVIF ou WebP, `srcset`
Délai de rendu	De l’arrivée de l’image à son affichage	CSS, polices ou scripts bloquants	CSS critique, scripts différés

Le panneau Performance affiche cette décomposition pour l’élément LCP. Un constat revient souvent sur les images hero : un délai de chargement bien plus long que le téléchargement lui-même. L’image attend son tour au lieu de partir.

Rendre l’image hero découvrable dès le HTML

L’analyseur de préchargement du navigateur parcourt le HTML dès son arrivée pour lancer au plus tôt les téléchargements utiles, mais il ne voit que le HTML initial. Une image déclarée en fond dans le CSS, injectée par un script de carrousel ou cachée dans un attribut data-src ne sera découverte qu’après le téléchargement et l’exécution de ces ressources.

Le réglage de base est donc une vraie balise img, ou picture, présente dans le HTML servi, avec ses attributs src et srcset. Vérifiez-le dans le code source de la page, et non dans l’inspecteur, qui montre le DOM après l’exécution des scripts.

Cas type : une boutique dont le carrousel d’accueil est entièrement construit en JavaScript. Le HTML ne contient qu’un conteneur vide, et la première image n’est demandée qu’une fois le script téléchargé, analysé et exécuté. Rendre la première diapositive en HTML suffit souvent à avancer nettement le LCP, sans toucher au design. Si l’image doit rester en fond CSS, un préchargement explicite la rend découvrable ; c’est un pis-aller, car une balise img avec object-fit: cover reproduit la plupart des mises en page de fond.

Prioriser sans tout prioriser : fetchpriority, préchargement, lazy loading

fetchpriority sur la seule image principale

Même découverte tôt, une image démarre souvent avec une priorité modeste : le navigateur ignore encore qu’elle sera grande et visible. L’attribut fetchpriority="high" lève ce doute et la fait passer devant les autres images. Il se pose sur une seule image par page, celle du LCP ; dans un carrousel, sur la première diapositive uniquement.

Le préchargement, pour ce qui est découvert trop tard

Le préchargement par link rel="preload" sert aux ressources critiques invisibles pour l’analyseur, comme une image de fond ou une image dont l’adresse dépend d’un script ; les attributs imagesrcset et imagesizes permettent d’en précharger la bonne variante. Précharger dix ressources revient à n’en prioriser aucune : elles se disputent la même bande passante.

Côté code

Une image hero découvrable, prioritaire, bien dimensionnée et jamais différée :

<picture>
  <source type="image/avif"
    srcset="hero-768.avif 768w, hero-1536.avif 1536w"
    sizes="(min-width: 1024px) 50vw, 100vw">
  <img src="hero-1536.webp"
    srcset="hero-768.webp 768w, hero-1536.webp 1536w"
    sizes="(min-width: 1024px) 50vw, 100vw"
    width="1536" height="1024" alt="…"
    fetchpriority="high">
</picture>

Le piège du chargement différé sur l’image principale

L’attribut loading="lazy" demande au navigateur d’attendre que l’image approche de la zone visible : parfait pour les images situées plus bas, désastreux pour l’image du haut, chargée seulement après le calcul de la mise en page. Le piège est fréquent parce qu’il est souvent automatique : certains thèmes, extensions ou composants d’image diffèrent toutes les images sans distinction. Dans le code source servi, l’image LCP ne doit porter ni loading="lazy", ni classe de chargement différé, ni source vide remplacée par un script.

Formats, dimensions, srcset et sizes

Une fois l’image découverte tôt et prioritaire, reste à réduire sa durée de téléchargement.

Le format. AVIF et WebP compressent nettement mieux que JPEG à qualité visuelle comparable, et l’élément picture les propose avec un repli. Réglez la qualité à l’œil, sur la photo réelle.
Les dimensions. Envoyer une image de 3 000 pixels de large à un téléphone de 390 pixels gaspille du temps sans gain visible. Préparez plusieurs largeurs, déclarées dans srcset.
L’attribut sizes. Il indique la largeur d’affichage réelle selon l’écran. Un 100vw posé sur une image qui n’occupe que la moitié de l’écran fait télécharger une variante trop grande.

Gardez width et height : ils réservent l’espace avant l’arrivée de l’image et protègent le CLS, tandis qu’un height: auto en CSS laisse l’image fluide.

CSS, polices et scripts qui retardent l’affichage

L’image est arrivée mais ne s’affiche pas encore : c’est le délai de rendu. Les coupables habituels :

les feuilles de style bloquantes, à alléger, avec le CSS critique du premier écran livré en ligne et aucun import en chaîne ;
les polices, quand un titre se superpose à l’image : font-display adapté, sous-ensemble de caractères, préchargement de la seule police critique ;
les scripts synchrones dans l’en-tête, qui interrompent la lecture du HTML et passent en defer ;
les extraits anti-scintillement des outils de test A/B, qui masquent toute la page tant que l’outil n’a pas répondu, un frein aussi discret que coûteux ;
les apparitions animées : une image hero qui surgit en fondu depuis une opacité nulle n’est comptée qu’une fois visible.

C’est ici que l’ordre compte : retoucher la compression de l’image alors qu’un script masque toute la page, c’est s’attaquer au mauvais secteur du tour.

Serveur, cache et CDN : gagner sur le premier octet

Toutes les phases attendent la première : si le HTML tarde, l’image partira tard, quelle que soit la qualité du reste.

Mettre en cache le HTML des pages les plus visitées, côté application ou en périphérie sur un CDN.
Supprimer les redirections évitables : une redirection 301 en un seul saut, et des liens internes qui pointent vers l’URL finale.
Servir les images depuis un CDN, avec des règles de cache longues et des noms de fichiers versionnés ; un preconnect anticipe la connexion si elles viennent d’un autre domaine.
Exploiter les réponses anticipées (103 Early Hints) quand l’hébergement les propose, pour signaler les ressources critiques avant la fin du calcul de la page.

Pour les navigations internes, les règles de spéculation et le cache de navigation arrière (bfcache) peuvent rendre l’affichage quasi instantané : des accélérateurs, pas des substituts aux réglages précédents.

Vérifier le gain sur le terrain

Chaque réglage se contrôle deux fois, en laboratoire puis chez vos visiteurs. La check-list de l’image hero :

image LCP présente dans le code source servi, avec srcset, sizes, width et height ;
fetchpriority="high" sur cette seule image, chargement différé sur toutes les autres ;
dans la cascade de chargement, l’image part juste après le HTML et les ressources critiques ;
délai de chargement réduit et délai de rendu minimal dans la décomposition du LCP ;
variante téléchargée conforme à la largeur affichée, sur mobile comme sur ordinateur ;
LCP au 75^e centile suivi par gabarit, chez les visiteurs et dans les données CrUX.

Sur le terrain, l’amélioration apparaît progressivement dans CrUX et dans la Search Console, au rythme de leur fenêtre glissante de 28 jours ; une mesure chez vos visiteurs la montre plus tôt. Surveillez ensuite les régressions : une image de campagne trop lourde ou un carrousel réintroduit suffisent à reperdre le terrain gagné.

Questions fréquentes sur le LCP d’une image hero

Q01

Faut-il précharger l’image hero en plus de fetchpriority ?

Pas si l’image figure déjà en balise img dans le HTML initial : fetchpriority suffit généralement. Le préchargement devient utile quand l’image reste invisible pour l’analyseur du navigateur, comme une image de fond en CSS ou une image dont l’adresse dépend d’un script.

Q02

AVIF ou WebP : quel format choisir pour l’image hero ?

Les deux, idéalement, dans un élément picture : AVIF en premier choix, WebP en second, avec un repli classique. Sur une image très détaillée, comparez le rendu et le poids des deux variantes. L’essentiel reste de servir la bonne largeur à chaque écran.

Q03

Une vidéo en haut de page peut-elle être l’élément LCP ?

Oui : c’est alors l’image d’affiche ou la première image affichée qui peut être retenue. Les mêmes principes s’appliquent, avec une image d’affiche légère, découverte dès le HTML et prioritaire. Sur mobile, une image fixe bien optimisée offre souvent le meilleur compromis.

Q04

Pourquoi mon LCP reste-t-il lent alors que l’image est légère ?

Parce que le poids de l’image ne concerne qu’une des quatre phases du LCP. Un serveur lent, une découverte tardive ou un rendu bloqué par le CSS, les polices ou un script de test A/B peuvent coûter bien davantage. Décomposez le LCP pour savoir quelle phase domine.

Optimiser le LCP d’une image hero : la séquence à retenir

Optimiser le LCP d’une image hero est d’abord une question d’ordre : vérifier l’élément LCP, lire ses phases, rendre l’image découvrable dès le HTML, la prioriser seule, lui donner le bon format et les bonnes dimensions, lever ce qui bloque son affichage, puis gagner sur le premier octet. À chaque étape un contrôle, et à la fin le verdict du terrain.

Bien menée, cette séquence garde l’image intacte et la page aussi riche qu’avant : seul change l’instant où elle apparaît. Si la Search Console reste rouge malgré un bon score de laboratoire, le décryptage PageSpeed vert, Search Console rouge aide à lire l’écart ; si la page répond mal aux clics, celui consacré à l’INP et aux tâches longues JavaScript prend le relais.