LCP request discovery in Lighthouse: checks en de fix

Wat vertelt LCP request discovery je over je LCP-afbeelding?

LCP request discovery is het Lighthouse 13-insight dat "Preload Largest Contentful Paint image" en "Largest Contentful Paint image was lazily loaded" verving. Het controleert of je LCP-afbeelding, de grote foto waarop je bezoekers wachten, vindbaar is vanuit de HTML: of de browser meteen kon beginnen met downloaden zodra de HTML binnenkwam, met hoge prioriteit. De fix: de foto als een <img> in de HTML, zonder loading="lazy", met fetchpriority="high".

Wil je direct de snelle fix? Spring naar WordPress, page builders, Shopify of Next.js.

Wat betekenen de drie checks van LCP request discovery?

In Lighthouse 13 en PageSpeed Insights luidt de melding: "Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading". Daaronder staan drie checks, elk groen of rood.

De melding voor de homepage van een hotel waarvan de grote foto loading="lazy" heeft. Lighthouse 13.6 met DevTools throttling.

• fetchpriority=high should be applied: de browser vroeg je LCP-afbeelding op zonder fetchpriority="high". Kwam de foto binnen via een preload, dan luidt de check "fetchpriority=high should be applied to the image preload request": ook de preload heeft het nodig. Slaagt de check, dan staat er "fetchpriority=high applied".
• Request is discoverable in initial document: de URL van de foto staat in de HTML zelf, in een <img> of een preload, waar de preload scanner (het deel van de browser dat vooruitleest in de HTML) hem vindt. Een achtergrondafbeelding in een stylesheet, een slider die zijn slides opbouwt met JavaScript of een lazy-load script dat de URL naar data-src verplaatste, zet deze check op rood.
• LCP resources shouldn’t use loading=lazy: de foto heeft loading="lazy", waardoor de browser hem pas opvraagt zodra de layout laat zien dat hij in beeld staat.

Eén rode check maakt de melding rood. Het LCP-element onderaan, een thumbnail met de bijbehorende HTML, toont welk element Lighthouse op een telefoonscherm heeft gemeten. Unscored betekent dat de melding op zichzelf geen punten oplevert, maar LCP telt voor een kwart mee in je Performance-score, en Google rankt op wat je echte bezoekers te zien krijgen. De melding verschijnt alleen als je LCP-element een afbeelding is: een <img>, een CSS-achtergrond of een video-poster.

Waarom maakt een late LCP-afbeelding de pagina traag?

Op een telefoon ziet je bezoeker een seconde of langer de kop en de tekst rond een leeg vlak waar de grote foto hoort.

Terwijl de HTML downloadt, leest de preload scanner van Chrome er alvast doorheen en vraagt elke afbeelding in een <img> src of srcset zonder loading="lazy" op: het vroegste moment waarop een foto kan starten. Elke andere foto start later: in een stylesheet wacht hij op dat bestand en de layout; in een style-attribuut of met loading="lazy" wacht hij op de layout, die eerst elke render-blocking stylesheet nodig heeft; een slider of lazy-load script moet eerst downloaden en draaien voordat het de foto opvraagt.

Dat wachten, de resource load delay, duurt meestal langer dan het downloaden zelf: bij de mediane site met een slechte LCP wacht de afbeelding 1.290 ms en downloadt daarna in 350 ms (web.dev).

Op de homepage van een hotel, die ik net als een WordPress-site met een page builder opbouwde, zette ik dezelfde foto op zeven manieren op de pagina en laadde elke variant op een telefoon met throttling:

Mediaan van vijf tests, in seconden, op Slow 4G met een 4x tragere CPU. De HTML kwam telkens binnen op 0,58 s.

Elke versie laadde dezelfde foto van 63 kB, behalve het style-attribuut, dat niet kan wisselen naar het kleinere bestand voor mobiel. Het moment waarop het request startte maakte het verschil: de foto in de HTML werd opgevraagd zodra de HTML binnenkwam; de rest wachtte op de first paint op 1,7 s of op de scripts op 2,4 s.

De hotelpagina na 2,5 seconden laden op dezelfde telefoon met throttling.

fetchpriority="high" vertelt Chrome vanaf het eerste moment dat deze afbeelding belangrijk is, waardoor hij meer van de verbinding krijgt. Op een drukke pagina, waar de foto concurreert met tientallen scripts en stylesheets, kan dat LCP sneller maken: Google mat een daling van 2,6 s naar 1,9 s op Google Flights. Het helpt alleen een foto die de browser al heeft gevonden: bij een foto in een stylesheet of script moet je eerst de HTML aanpassen.

Waarom staat fetchpriority=high nog steeds op rood als de afbeelding het al heeft?

De check kijkt naar het request dat je LCP-afbeelding heeft geladen. Zoek uitgelogd in de paginabron naar de bestandsnaam van de foto. De gebruikelijke oorzaken (fixes hieronder):

• Een preload die je niet zelf hebt geschreven. Een thema, host of CDN kan een preload voor de foto meesturen in een Link-header of in 103 Early Hints; een cache-plugin of Next.js voegt een <link rel="preload"> toe aan de head. Voor een header open je het Network-paneel in DevTools, klik je op het eerste request (de pagina zelf) en bekijk je de Headers.
• Een lazy-load-plugin heeft de afbeelding herschreven. Staat ook de discoverable-check op rood, zoek dan naar data-src of data-lazy-src op de foto: een plugin heeft de URL daarnaartoe verplaatst, en een script vraagt de foto pas later op.
• WordPress gaf het attribuut aan een andere afbeelding. WordPress voegt fetchpriority="high" toe aan de eerste grote afbeelding in het eerste scherm (50.000 pixels of meer). Een logo dat op dubbel formaat is geüpload, zeg 600 bij 200 pixels, komt eerst en pakt het mee.
• Lighthouse heeft een andere afbeelding gemeten. Het LCP-element onderaan de melding laat zien om welke het gaat. Op een telefoon kan het een aparte mobiele hero zijn, waarbij de desktopfoto via CSS verborgen is en het attribuut op die desktopfoto staat.

De hotelpagina met een lazy-load-script: twee rode checks. Lighthouse 13.6 met DevTools throttling.

Hoe lang wachten je bezoekers op de LCP-afbeelding?

Je field data laat zien hoe lang echte bezoekers wachten. Open in CoreDash de LCP Breakdown voor mobiel en kies LCP Priority onder More dimensions: elke rij toont een manier waarop de LCP-afbeelding is geladen, met de p75 LCP opgesplitst in onderdelen. Het groene deel is de load delay: het wachten tussen de binnenkomst van de HTML en het moment dat de afbeelding begint met downloaden. Groepeer op URL om het template te vinden waar dit lang duurt.

CoreDash op mobiel, p75: vergelijk het groene deel van elke LCP Priority-rij.

Hoe zie je in DevTools hoe laat de afbeelding begon?

Draai een trace van de pagina in het Performance-paneel van Chrome DevTools en open LCP request discovery in de Insights-zijbalk. Op mijn testpagina voor het hotel, met de foto als achtergrond in de stylesheet van de page builder, toont het insight hoe lang na de eerste byte van de HTML—zijn "earliest start point"—het request voor de foto begon. De gestreepte balk in de Network-track markeert die wachttijd.

Het request voor de foto start na de stylesheets. Chrome DevTools, Performance-paneel, telefoon met throttling.

In het Network-paneel toont de Initiator-kolom naast de foto het bestand dat hem opvroeg: een stylesheet, een slider-script, of de HTML als hij op tijd begon.

Hoe los je LCP request discovery op?

Zoek de bestandsnaam van de foto in de paginabron. Staat hij in een <img> src of srcset, dan vindt de browser hem vroeg; staat hij in data-src, een stylesheet of nergens, dan moet je dat aanpassen. Het doel is overal hetzelfde: de foto als een <img> in de HTML, zonder loading="lazy", met fetchpriority="high", alleen op die ene afbeelding. Voeg fetchpriority="high" toe aan een preload die je niet zelf schreef, of zet hem uit. Vervang een aparte mobiele hero door één foto voor beide schermen, of door één <picture> met een <source> voor het mobiele bestand en fetchpriority="high" op de <img>.

WordPress en lazy-load-plugins

WordPress houdt de eerste afbeeldingen buiten lazy loading en geeft de eerste grote fetchpriority="high". Is de melding toch nog rood, dan overschrijft meestal een plugin dit gedrag:

• WP Rocket: Optimize Critical Images staat standaard aan, leert de LCP-afbeelding van echte bezoeken, preloadt deze met fetchpriority="high" en houdt hem buiten LazyLoad. Test opnieuw nadat de cache opnieuw is opgebouwd.
• Perfmatters: zet Exclude Leading Images en Preload Critical Images op het aantal afbeeldingen in het eerste scherm op een telefoon, vaak één.
• LiteSpeed Cache: voeg de bestandsnaam van de foto toe aan Lazy Load Image Excludes, of zet Viewport Images aan.
• FlyingPress: controleer of de foto loading="eager" en een preload heeft; zo niet, sluit hem dan uit van lazy loading.

Upload een logo op het formaat waarop het wordt weergegeven, zodat het attribuut naar de foto gaat. Gebruik maar één lazy loader, anders blijft de foto alsnog lazy nadat je hem in de ene hebt uitgesloten. In het Cover-blok maakt Fixed background van de foto een achtergrond in een style-attribuut: zet dit uit en de foto is weer een <img>. Mijn plugin WP Core Web Vitals leert de LCP-afbeelding per schermformaat van je bezoekers en laadt deze als eerste, met hoge prioriteit.

Elementor en andere page builders

Een foto die is ingesteld als achtergrond van een Elementor Container of Section belandt in de CSS van Elementor, waardoor de browser hem pas vindt na die CSS en de layout. Gebruik een Image widget voor de hero image (een Elementor hero met een afbeelding); Optimized Image Loading (Settings, Performance) verwerkt hem dan zoals WordPress dat doet. Lazy Load Background Images, dat standaard aan staat, kan een achtergrond-hero vertragen die onder een notificatiebalk staat. Gebruik ook in andere builders een afbeeldingselement voor de eerste foto.

Sliders

De eerste slide moet een <img> in de HTML zijn, zonder loading="lazy", met fetchpriority="high"; de overige slides krijgen loading="lazy" en fetchpriority="low". Een slider die zijn slides opbouwt met JavaScript start de eerste slide pas nadat dat script heeft gedraaid: kies er een die de eerste slide direct in de HTML zet, of toon één foto op mobiel. In Elementors Image Carousel zet de Lazyload-schakelaar de URL van elke slide in data-src: zet die uit.

Shopify

Dawn, Horizon en thema's die daarop gebaseerd zijn geven de afbeelding in de eerste sectie van een template fetchpriority="high" en laden hem meteen, dus maak van de banner of slideshow de eerste sectie. Op een Dawn-productpagina ontbreekt fetchpriority op de hoofdafbeelding: voeg in snippets/product-thumbnail.liquid fetchpriority: 'high' toe aan de image_tag als lazy_load false is (de eerste foto). Een update van het thema kan dit bestand overschrijven: controleer het attribuut daarna. Een hero die een app opbouwt met JavaScript start altijd laat, wat het thema ook doet: gebruik een thema-sectie.

Kijk bij andere thema's in het sectiebestand naar loading: 'lazy' of een lazyload-class met data-src, en stem de prioriteit af op de positie van de sectie:

{%- 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 }}

Zonder loading-parameter past image_tag lazy loading toe op afbeeldingen vanaf de vierde sectie.

CSS-achtergrondafbeeldingen

Heeft je thema of builder geen afbeeldingsoptie, dan heb je een developer nodig. Zet de achtergrond eerst om naar een <img>: de browser vindt hem dan direct in de HTML, en met srcset kiest elk scherm zijn eigen bestand. object-fit zorgt ervoor dat hij de ruimte vult zoals de achtergrond dat deed:

<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; }

Moet het een achtergrond blijven, preload dan het bestand dat de CSS per schermformaat kiest, met de media queries uit de CSS en fetchpriority="high"; een preload voor een ander bestand downloadt de foto twee keer. Voeg dit alleen toe aan het template van die pagina. Voor CSS die onder 768 px overschakelt naar het bestand van 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 en React

next/image gebruikt standaard lazy loading. Sinds Next.js 15 maakt priority (preload in 16) de afbeelding eager en preloadt deze zonder fetchpriority, waardoor de check op rood blijft staan. Stel beide zelf in, zonder priority:

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

In Astro 5.10 en nieuwer stelt de priority-prop op <Image> beide in. Een hero die React in de browser rendert bestaat pas nadat de JavaScript heeft gedraaid: render hem op de server of prerender de pagina, zodat de <img> in de HTML staat.

Een hero die je niet kunt aanpassen

Een A/B-test die de foto verwisselt of een widget die de hero met JavaScript opbouwt, start hem te laat. Blijft de URL van de foto gelijk, dan zorgt een preload met fetchpriority="high" in je eigen template voor een vroege start. Bij een trage server kan 103 Early Hints een foto die op elk scherm hetzelfde bestand gebruikt al starten voordat de HTML binnen is. Voor beide heb je een developer nodig.

Start de LCP-afbeelding nu tegelijk met de HTML?

Draai Lighthouse opnieuw: drie groene checks, en je foto als LCP-element. In DevTools start het request voor de foto direct na de HTML. Geslaagd, maar is LCP nog steeds traag? Kijk naar de andere onderdelen van LCP: een trage server (time to first byte), een foto die langzaam downloadt (load duration), of stylesheets en scripts die de paint tegenhouden (render delay). Voor echte bezoekers houd je de load delay op telefoons in de gaten in CoreDash; Search Console heeft tot 28 dagen nodig.

Een Core Web Vitals power hour is er voor de foto waar je met deze pagina niet bij komt: eentje die geplaatst is door een page builder, slider of app zonder instelling hiervoor, of een foto die slaagt voor alle drie de checks terwijl LCP op telefoons traag blijft. We volgen hem door een trace van je eigen pagina, van de HTML tot het scherm, en achterhalen wat hem tegenhoudt.