LCP request discovery dans Lighthouse : les vérifications et le fix

Que vous apprend LCP request discovery sur votre image LCP ?

LCP request discovery est l'insight de Lighthouse 13 qui a remplacé « Preload Largest Contentful Paint image » et « Largest Contentful Paint image was lazily loaded ». Il vérifie si votre image LCP, la grande photo qu'attendent vos visiteurs, est découvrable dès le HTML : si le navigateur a pu commencer à la télécharger dès l'arrivée du HTML, avec une priorité haute. Le fix : la photo en <img> dans le HTML, sans loading="lazy", avec fetchpriority="high".

Vous cherchez juste le fix rapide ? Passez directement à WordPress, aux constructeurs de page, à Shopify ou à Next.js.

Que signifient les trois vérifications de LCP request discovery ?

Dans Lighthouse 13 et PageSpeed Insights, le message indique : « Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading ». En dessous figurent trois vérifications, chacune au vert ou au rouge.

Le message pour la page d'accueil d'un hôtel dont la grande photo a loading="lazy". Lighthouse 13.6 avec le throttling DevTools.

• fetchpriority=high should be applied : le navigateur a demandé l'image LCP sans fetchpriority="high". Lorsque la photo passe par un preload, la vérification indique « fetchpriority=high should be applied to the image preload request » : le preload en a besoin lui aussi. Quand le test passe, elle indique « fetchpriority=high applied ».
• Request is discoverable in initial document : l'URL de la photo se trouve dans le HTML lui-même, dans une balise <img> ou un preload, là où le preload scanner (la partie du navigateur qui lit le HTML en avance) la trouve. Une image d'arrière-plan dans une feuille de style, un slider qui construit ses slides en JavaScript ou un script de lazy loading qui a déplacé l'URL dans data-src fait passer cette vérification au rouge.
• LCP resources shouldn’t use loading=lazy : la photo a loading="lazy", le navigateur ne la demande donc qu'une fois que le layout confirme sa présence à l'écran.

Une seule vérification rouge fait passer l'alerte au rouge. En bas, l'élément LCP, une miniature avec son HTML, montre l'élément mesuré par Lighthouse sur écran mobile. « Unscored » signifie que l'alerte n'ajoute aucun point en soi, mais le LCP compte pour un quart de votre score Performance, et Google classe votre site selon ce qu'obtiennent vos vrais visiteurs. L'alerte n'apparaît que si l'élément LCP est une image : une balise <img>, un arrière-plan CSS ou le poster d'une vidéo.

Pourquoi une image LCP tardive ralentit-elle la page ?

Sur un téléphone, le visiteur voit le titre et le texte autour d'un bloc vide à la place de la grande photo, pendant une seconde ou plus.

Pendant le téléchargement du HTML, le preload scanner de Chrome le parcourt en avance et demande chaque image présente dans le src ou srcset d'une balise <img> sans loading="lazy" : c'est le démarrage le plus précoce possible pour une photo. Toutes les autres démarrent plus tard : dans une feuille de style, elle attend ce fichier et le layout ; dans un attribut style ou avec loading="lazy", elle attend le layout, qui exige d'abord chaque feuille de style render-blocking ; un slider ou un script de lazy loading doit d'abord être téléchargé et exécuté avant de demander la photo.

Cette attente, le resource load delay, dure généralement plus longtemps que le téléchargement lui-même : sur le site médian avec un mauvais LCP, l'image attend 1 290 ms avant de se télécharger en 350 ms (web.dev).

Sur la page d'accueil d'un hôtel configurée comme un site WordPress avec un constructeur de page, j'ai intégré la même photo de sept manières différentes et chargé chacune d'elles sur un téléphone bridé :

Médianes de cinq chargements, en secondes, en 4G lente avec un CPU 4x plus lent. Le HTML est arrivé à 0,58 s à chaque fois.

Toutes les versions ont chargé la même photo de 63 Ko, sauf celle avec l'attribut style, incapable de basculer vers le fichier mobile plus léger. Le moment où la requête a démarré a fait toute la différence : la photo dans le HTML a été demandée dès l'arrivée du HTML, alors que les autres ont attendu le premier affichage à 1,7 s ou l'exécution des scripts à 2,4 s.

La page de l'hôtel 2,5 secondes après le début du chargement sur le même téléphone bridé.

fetchpriority="high" indique d'emblée à Chrome que cette image compte, et lui alloue ainsi une plus grande part de la bande passante. Sur une page chargée, où la photo dispute la connexion à des dizaines de scripts et de feuilles de style, cela accélère le LCP : Google a mesuré un passage de 2,6 s à 1,9 s sur Google Flights. Cela n'aide qu'une photo que le navigateur a déjà trouvée : pour une photo dans une feuille de style ou un script, il faut d'abord modifier le HTML.

Pourquoi fetchpriority=high reste-t-il au rouge alors que l'image l'a déjà ?

La vérification analyse la requête qui a chargé l'image LCP. Déconnecté, cherchez le nom de fichier de la photo dans le code source de la page. Les causes fréquentes (solutions ci-dessous) :

• Un preload que vous n'avez pas écrit. Un thème, un hébergeur ou un CDN peut envoyer un preload pour la photo dans un en-tête Link ou via 103 Early Hints ; un plugin de cache ou Next.js ajoute une balise <link rel="preload"> dans le head. Pour vérifier les en-têtes, ouvrez le panneau Network des DevTools, cliquez sur la première requête (la page elle-même) et examinez ses Headers.
• Un plugin de lazy loading a réécrit l'image. Si la vérification de découvrabilité est aussi au rouge, cherchez data-src ou data-lazy-src sur la photo : un plugin y a déplacé l'URL, et un script demandera la photo plus tard.
• WordPress a attribué l'attribut à une autre image. WordPress ajoute fetchpriority="high" à la première grande image du premier écran (50 000 pixels ou plus). Un logo uploadé en taille double, par exemple 600 par 200 pixels, arrive en premier et s'en empare.
• Lighthouse a mesuré une autre image. L'élément LCP en bas de l'alerte indique de laquelle il s'agit. Sur mobile, il peut s'agir d'un hero mobile distinct, avec la photo desktop masquée en CSS et l'attribut resté sur cette photo desktop.

La page de l'hôtel avec un script de lazy loading : deux vérifications au rouge. Lighthouse 13.6 avec le throttling DevTools.

Combien de temps vos visiteurs attendent-ils l'image LCP ?

Vos field data montrent combien de temps attendent vos visiteurs réels. Dans CoreDash, ouvrez le rapport LCP Breakdown sur mobile et choisissez LCP Priority sous More dimensions : chaque ligne correspond à un mode de chargement de l'image LCP, avec son LCP p75 découpé en sous-parties. La partie verte représente le load delay, l'attente entre l'arrivée du HTML et le début du téléchargement de l'image. Groupez par URL pour repérer le template où ce délai est trop long.

CoreDash sur mobile, p75 : comparez la partie verte de chaque ligne de LCP Priority.

Comment voir dans les DevTools le retard pris par l'image ?

Enregistrez une trace de la page dans le panneau Performance des Chrome DevTools et ouvrez LCP request discovery dans la barre latérale Insights. Sur ma page de test de l'hôtel, avec la photo en arrière-plan dans la feuille de style du constructeur de page, l'insight montre combien de temps après le premier octet du HTML, son « earliest start point », la requête de la photo a démarré. La barre hachurée dans la piste Network matérialise cette attente.

La requête de la photo démarre après les feuilles de style. Chrome DevTools, panneau Performance, téléphone bridé.

Dans le panneau Network, la colonne Initiator à côté de la photo indique le fichier qui l'a demandée : une feuille de style, un script de slider, ou le HTML quand elle a démarré à temps.

Comment corriger LCP request discovery ?

Cherchez le nom de fichier de la photo dans le code source de la page. Si elle est dans le src ou srcset d'une balise <img>, le navigateur la trouve tôt ; dans un data-src, une feuille de style ou nulle part, c'est ce qu'il faut corriger. L'objectif partout : la photo en <img> dans le HTML, sans loading="lazy", avec fetchpriority="high", sur cette seule image. Ajoutez fetchpriority="high" à un preload que vous n'avez pas écrit, ou désactivez-le. Remplacez un hero mobile distinct par une seule photo pour les deux écrans, ou une balise <picture> avec un <source> pour le fichier mobile et fetchpriority="high" sur son <img>.

WordPress et les plugins de lazy loading

WordPress évite le lazy loading pour les premières images et attribue fetchpriority="high" à la première grande image. Si l'alerte reste au rouge, un plugin surcharge généralement ce comportement :

• WP Rocket : l'option Optimize Critical Images, activée par défaut, identifie l'image LCP d'après les visites réelles, la précharge avec fetchpriority="high" et l'exclut de LazyLoad. Testez à nouveau après régénération du cache.
• Perfmatters : réglez Exclude Leading Images et Preload Critical Images sur le nombre d'images visibles dans le premier écran sur mobile, souvent une.
• LiteSpeed Cache : ajoutez le nom de fichier de la photo à Lazy Load Image Excludes, ou activez Viewport Images.
• FlyingPress : vérifiez que la photo possède loading="eager" et un preload ; si ce n'est pas le cas, excluez-la du lazy loading.

Uploadez le logo à la taille où il s'affiche, pour que l'attribut aille à la photo. Ne conservez qu'un seul module de lazy loading, sinon la photo restera en lazy loading après l'avoir exclue du premier. Dans le bloc Cover, Fixed background transforme la photo en arrière-plan dans un attribut style : désactivez-le et la photo redevient une balise <img>. Mon plugin WP Core Web Vitals détermine l'image LCP par taille d'écran d'après vos visiteurs et la charge en premier, avec une priorité haute.

Elementor et les autres constructeurs de page

Une photo définie en arrière-plan d'un Conteneur ou d'une Section Elementor finit dans le CSS d'Elementor : le navigateur ne la découvre donc qu'après ce CSS et le layout. Utilisez un widget Image pour la photo du hero (un hero Elementor avec une image) ; l'option Optimized Image Loading (Réglages, Performances) s'en charge alors comme le fait WordPress. Lazy Load Background Images, activée par défaut, peut retarder un hero en arrière-plan placé sous une barre d'annonce. Dans les autres constructeurs aussi, utilisez un élément image pour la première photo.

Sliders

La première slide doit être une balise <img> dans le HTML, sans loading="lazy", avec fetchpriority="high" ; les autres slides reçoivent loading="lazy" et fetchpriority="low". Un slider qui construit ses slides en JavaScript ne démarre la première slide qu'après l'exécution de ce script : utilisez un slider qui écrit la première slide dans le HTML, ou n'affichez qu'une seule photo sur mobile. Dans le widget Carrousel d'images d'Elementor, l'option Lazyload place l'URL de chaque slide dans data-src : désactivez-la.

Shopify

Dawn, Horizon et les thèmes dérivés attribuent fetchpriority="high" à l'image de la première section du template et la chargent immédiatement : placez donc la bannière ou le diaporama en première section. Sur une page produit Dawn, la photo principale n'a pas de fetchpriority : dans snippets/product-thumbnail.liquid, ajoutez fetchpriority: 'high' à l'image_tag lorsque lazy_load est false (la première photo). Une mise à jour du thème peut écraser ce fichier : vérifiez l'attribut ensuite. Un hero généré en JavaScript par une application démarre tard, quoi que fasse le thème : utilisez une section du thème.

Dans les autres thèmes, cherchez loading: 'lazy' ou une classe lazyload avec data-src dans le fichier de la section, et indexez la priorité sur la position de la section :

{%- liquid
  assign fetch_priority = 'auto'
  if section.index == 1
    assign fetch_priority = 'high'
  endif
-%}
{{ section.settings.image | image_url: width: 1600 | image_tag: widths: '750, 1100, 1600', sizes: '100vw', fetchpriority: fetch_priority }}

Sans paramètre loading, image_tag charge les images en lazy loading à partir de la quatrième section.

Images d'arrière-plan CSS

Sans option d'image dans votre thème ou constructeur, il vous faudra un développeur. Transformez d'abord l'arrière-plan en balise <img> : le navigateur la découvre alors dans le HTML, et srcset permet à chaque écran de choisir son propre fichier. object-fit remplit l'espace exactement comme le faisait l'arrière-plan :

<section class="hero">
  <img class="hero-img" src="/wp-content/uploads/2026/10/terrace-1024.jpg"
    srcset="/wp-content/uploads/2026/10/terrace-768.jpg 768w, /wp-content/uploads/2026/10/terrace-1024.jpg 1024w, /wp-content/uploads/2026/10/terrace-1600.jpg 1600w"
    sizes="100vw" width="1600" height="1067" alt="Terrace above the sea" fetchpriority="high">
</section>

.hero { position: relative; }
.hero-img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

S'il doit absolument rester en arrière-plan, préchargez le fichier sélectionné par le CSS pour chaque taille d'écran, avec les media queries du CSS et fetchpriority="high" ; précharger un autre fichier télécharge la photo deux fois. Ajoutez-le uniquement au template de cette page. Pour un CSS qui bascule sur le fichier 768 px en dessous de 768 px :

<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-768.jpg" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-1600.jpg" media="(min-width: 768px)" fetchpriority="high">

Next.js, Astro et React

next/image applique le lazy loading par défaut. Depuis Next.js 15, la prop priority (preload dans la 16) passe l'image en eager et la précharge sans fetchpriority, ce qui laisse la vérification au rouge. Définissez les deux vous-même, sans priority :

<Image src={hero} alt="Terrace above the sea" sizes="100vw" loading="eager" fetchPriority="high" />

Dans Astro 5.10 et supérieur, la prop priority sur <Image> configure les deux. Un hero que React affiche dans le navigateur n'existe qu'après l'exécution du JavaScript : faites son rendu côté serveur ou prérendez la page, pour que la balise <img> soit dans le HTML.

Un hero impossible à modifier

Un test A/B qui remplace la photo ou un widget qui construit le hero en JavaScript démarre la photo trop tard. Si l'URL de la photo ne change pas, un preload avec fetchpriority="high" dans votre propre template la lance plus tôt. Sur un serveur lent, les 103 Early Hints peuvent démarrer une photo identique sur tous les écrans avant même l'arrivée du HTML. Les deux solutions demandent un développeur.

L'image LCP démarre-t-elle désormais avec le HTML ?

Relancez Lighthouse : trois vérifications au vert, et votre photo comme élément LCP. Dans les DevTools, la requête de la photo démarre immédiatement après le HTML. Le test passe, mais le LCP reste lent ? Examinez les autres composantes du LCP : un serveur lent (time to first byte), une photo longue à télécharger (load duration), ou des feuilles de style et des scripts qui bloquent l'affichage (render delay). Pour les visiteurs réels, surveillez le load delay sur mobile dans CoreDash ; Search Console met jusqu'à 28 jours.

Une Core Web Vitals power hour est faite pour la photo que cette page ne peut pas atteindre : une image insérée par un constructeur de page, un slider ou une application sans réglage dédié, ou une photo qui passe les trois vérifications alors que le LCP sur mobile reste lent. Nous la suivons à travers une trace de votre propre page, du HTML jusqu'à l'écran, pour trouver ce qui la bloque.