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

Vous voulez la solution rapide ? Passez directement à WordPress, aux page builders, à Shopify ou à Next.js.

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

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

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

• fetchpriority=high should be applied : le navigateur a demandé l'image LCP sans fetchpriority="high". Quand la photo est passée 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 elle passe, elle indique « fetchpriority=high applied ».
• Request is discoverable in initial document : l'URL de la photo se trouve directement dans le HTML, dans un <img> ou un preload, là où le preload scanner (la partie du navigateur qui lit le HTML en amont) la découvre. Une image d'arrière-plan dans une feuille de style, un slider qui génère 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 porte loading="lazy" : le navigateur ne la demande donc qu'une fois que la mise en page confirme sa présence à l'écran.

Une seule vérification rouge fait passer l'avertissement au rouge. L'élément LCP en bas, une miniature accompagnée de son HTML, montre quel élément Lighthouse a mesuré sur écran mobile. « Unscored » signifie que l'avertissement ne rapporte aucun point en lui-même, mais le LCP compte pour un quart de votre score de Performance, et Google base son classement sur l'expérience de vos vrais visiteurs. L'avertissement n'apparaît que si l'élément LCP est une image : un <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, votre visiteur voit le titre et le texte autour d'un bloc vide à l'emplacement de la grande photo, pendant une seconde ou plus.

Pendant le téléchargement du HTML, le preload scanner de Chrome le parcourt en amont et demande chaque image présente dans le src ou le srcset d'un <img> sans loading="lazy" : c'est le moment le plus précoce pour démarrer une photo. Toute autre photo démarre 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 : sur le site médian avec un mauvais LCP, l'image attend 1 290 ms puis se télécharge en 350 ms (web.dev).

Sur la page d'accueil d'un hôtel conçue comme un site WordPress avec un page builder, j'ai intégré la même photo de sept manières différentes et chargé chacune sur un téléphone avec throttling :

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

Chaque version chargeait la même photo de 63 ko, sauf l'attribut style, incapable de basculer vers le fichier mobile plus léger. C'est le moment où la requête a démarré qui a fait la différence : la photo dans le HTML a été demandée dès l'arrivée du HTML, tandis que les autres ont attendu le premier affichage à 1,7 s ou les 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 avec throttling.

fetchpriority="high" indique à Chrome dès le premier instant que cette image est prioritaire, lui allouant ainsi une plus grande part de la connexion. Sur une page chargée, où la photo dispute la bande passante à des dizaines de scripts et de feuilles de style, cela peut accélérer le LCP : Google a mesuré une baisse 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 rouge alors que l'image l'a déjà ?

La vérification examine la requête qui a chargé l'image LCP. Recherchez le nom de fichier de la photo dans le code source de la page, en étant déconnecté. Voici les causes courantes (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 un <link rel="preload"> dans le head. Pour vérifier un en-tête, ouvrez le panneau Network dans DevTools, cliquez sur la première requête (la page elle-même) et lisez ses Headers.
• Un plugin de lazy loading a réécrit l'image. Si la vérification de découvrabilité est rouge elle aussi, cherchez data-src ou data-lazy-src sur la photo : un plugin y a déplacé l'URL, et un script demande 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 téléversé 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 au bas de l'avertissement indique laquelle. Sur un téléphone, il peut s'agir d'un hero mobile distinct, la photo pour ordinateur étant masquée en CSS avec l'attribut sur cette photo desktop.

La page de l'hôtel avec un script de lazy loading : deux vérifications rouges. Lighthouse 13.6 avec 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 LCP Breakdown pour mobile et sélectionnez LCP Priority sous More dimensions : chaque ligne correspond à un mode de chargement de l'image LCP, avec son p75 LCP décomposé en sous-parties. La partie verte représente le load delay, soit l'attente entre l'arrivée du HTML et le début du téléchargement de l'image. Groupez par URL pour identifier le template où cette attente est trop longue.

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

Comment voir dans DevTools à quel point l'image a démarré tard ?

Enregistrez une trace de la page dans le panneau Performance des DevTools de Chrome et ouvrez LCP request discovery dans le volet latéral Insights. Sur ma page de test de l'hôtel, avec la photo en arrière-plan dans la feuille de style du page builder, l'insight indique 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 signale cette attente.

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

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

Comment corriger LCP request discovery ?

Trouvez le nom de fichier de la photo dans le code source de la page. Dans le src ou le srcset d'un <img>, le navigateur la découvre tôt ; dans data-src, une feuille de style ou nulle part, c'est ce qu'il faut changer. L'objectif partout : la photo dans un <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 séparé par une seule photo pour les deux écrans, ou un seul <picture> avec un <source> pour le fichier mobile et fetchpriority="high" sur son <img>.

WordPress et les plugins de lazy loading

WordPress exclut les premières images du lazy loading et attribue fetchpriority="high" à la première grande image. Quand l'avertissement reste rouge, c'est généralement un plugin qui prend le dessus :

• WP Rocket : Optimize Critical Images, activé par défaut, apprend quelle est l'image LCP d'après les visites réelles, la précharge avec fetchpriority="high" et l'exclut de LazyLoad. Relancez le test après la reconstruction du cache.
• Perfmatters : réglez Exclude Leading Images et Preload Critical Images sur le nombre d'images du premier écran sur mobile, souvent une seule.
• LiteSpeed Cache : ajoutez le nom de fichier de la photo dans Lazy Load Image Excludes, ou activez Viewport Images.
• FlyingPress : vérifiez que la photo porte loading="eager" et un preload ; sinon, excluez-la du lazy loading.

Téléversez votre logo à la taille où il s'affiche, pour que l'attribut aille à la photo. Ne gardez qu'un seul système de lazy loading, sinon la photo restera en lazy loading après l'avoir exclue dans l'un d'eux. Dans le bloc Cover, Fixed background transforme la photo en un arrière-plan dans un attribut style : désactivez-le et la photo redevient un <img>. Mon plugin WP Core Web Vitals apprend quelle est l'image LCP par taille d'écran grâce à vos visiteurs et la charge en premier, avec une priorité haute.

Elementor et les autres page builders

Une photo définie comme arrière-plan d'un Conteneur ou d'une Section Elementor se retrouve 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 hero (un hero Elementor avec une image) ; Optimized Image Loading (Réglages, Performances) s'en charge ensuite comme le fait WordPress. Lazy Load Background Images, activé par défaut, peut retarder un hero en arrière-plan placé sous une barre de notification. Dans les autres builders aussi, utilisez un élément image pour la première photo.

Sliders

Le premier slide doit être un <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 lance le premier slide qu'après l'exécution de ce script : utilisez un slider qui injecte le premier slide dans le HTML, ou n'affichez qu'une seule photo sur mobile. Dans le Carousel 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 d'un 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' au image_tag quand lazy_load est à false (la première photo). Une mise à jour du thème pouvant remplacer ce fichier, vérifiez l'attribut par la suite. 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 dans le fichier de la section loading: 'lazy' ou une classe lazyload avec data-src, et liez la priorité à 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 applique le lazy loading aux images à partir de la quatrième section.

Images d'arrière-plan CSS

Sans option d'image dans votre thème ou votre builder, cela nécessite un développeur. Transformez d'abord l'arrière-plan en un <img> : le navigateur le trouve alors dans le HTML, et srcset permet à chaque écran de choisir son propre fichier. object-fit lui fait remplir l'espace exactement comme 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 choisi par le CSS pour chaque taille d'écran, avec les media queries du CSS et fetchpriority="high" ; un preload visant un autre fichier télécharge la photo deux fois. Ajoutez-le uniquement au template de cette page. Pour un CSS qui bascule vers le fichier de 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, priority (preload en 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 les versions ultérieures, la prop priority sur <Image> configure les deux. Un hero rendu par React dans le navigateur n'existe qu'une fois le JavaScript exécuté : effectuez le rendu sur le serveur ou pré-rendez la page, pour que le <img> soit dans le HTML.

Un hero que vous ne pouvez pas modifier

Un test A/B qui remplace la photo ou un widget qui génère le hero en JavaScript le fait démarrer en retard. Quand l'URL de la photo ne change pas, un preload avec fetchpriority="high" dans votre propre template la démarre plus tôt. Sur un serveur lent, les 103 Early Hints peuvent lancer une photo qui utilise le même fichier sur tous les écrans avant même l'arrivée du HTML. Les deux nécessitent un développeur.

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

Relancez Lighthouse : trois vérifications vertes, et votre photo en élément LCP. Dans DevTools, la requête de la photo démarre immédiatement après le HTML. Tout passe, et 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, avec les photos à compresser listées sous Improve image delivery), ou des feuilles de style et des scripts qui retardent l'affichage (render delay). Pour vos visiteurs réels, surveillez le load delay sur mobile dans CoreDash ; la Search Console met jusqu'à 28 jours.

Une Core Web Vitals power hour est là pour la photo que cette page ne permet pas de régler : celle intégrée par un page builder, un slider ou une application sans réglage dédié, ou celle qui réussit les trois vérifications alors que le LCP sur mobile reste lent. Nous la suivons dans une trace de votre propre page, du HTML jusqu'à l'écran, et identifions ce qui la ralentit.