LCP-Request-Discovery in Lighthouse: Prüfungen und die Lösung

Was sagt dir LCP-Request-Discovery über dein LCP-Bild?

LCP-Request-Discovery ist der Lighthouse-13-Insight, der „Preload Largest Contentful Paint image“ und „Largest Contentful Paint image was lazily loaded“ ersetzt hat. Er prüft, ob dein LCP-Bild – das große Foto, auf das deine Besucher warten – direkt im HTML auffindbar ist: Konnte der Browser den Download mit hoher Priorität starten, sobald das HTML ankam? Die Lösung: das Foto als <img> im HTML, ohne loading="lazy", mit fetchpriority="high".

Du willst nur die schnelle Lösung? Spring direkt zu WordPress, Page-Buildern, Shopify oder Next.js.

Was bedeuten die drei Prüfungen von LCP-Request-Discovery?

In Lighthouse 13 und PageSpeed Insights lautet der Hinweis: „Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading“. Darunter stehen drei Prüfungen, jeweils grün oder rot.

Der Hinweis für die Startseite eines Hotels, deren großes Foto loading="lazy" nutzt. Lighthouse 13.6 mit DevTools-Drosselung.

• fetchpriority=high should be applied: Der Browser hat dein LCP-Bild ohne fetchpriority="high" angefordert. Kam das Foto über einen Preload, lautet die Prüfung „fetchpriority=high should be applied to the image preload request“: Auch der Preload braucht das Attribut. Wenn sie besteht, lautet der Text „fetchpriority=high applied“.
• Request is discoverable in initial document: Die URL des Fotos steht direkt im HTML, in einem <img> oder einem Preload. Dort findet der Preload-Scanner (der Teil des Browsers, der das HTML vorausliest) die Datei. Ein Hintergrundbild in einem Stylesheet, ein Slider, der seine Slides per JavaScript baut, oder ein Lazy-Load-Skript, das die URL nach data-src verschoben hat, färbt diese Prüfung rot.
• LCP resources shouldn’t use loading=lazy: Das Foto nutzt loading="lazy". Der Browser fordert es deshalb erst an, sobald das Layout zeigt, dass es im Viewport liegt.

Eine rote Prüfung färbt den gesamten Hinweis rot. Das LCP-Element unten – ein Thumbnail samt HTML – zeigt, welches Element Lighthouse auf dem Smartphone gemessen hat. „Unscored“ bedeutet: Der Hinweis bringt für sich allein keine Punkte. Aber der LCP macht ein Viertel deines Performance-Scores aus, und Google bewertet die Daten deiner echten Besucher. Der Hinweis erscheint nur, wenn dein LCP-Element ein Bild ist: ein <img>, ein CSS-Hintergrund oder ein Video-Poster.

Warum macht ein spätes LCP-Bild die Seite langsam?

Auf dem Smartphone sieht dein Besucher die Überschrift und den Text um einen leeren Kasten herum, in den das große Foto gehört – für eine Sekunde oder länger.

Während das HTML herunterlädt, liest Chromes Preload-Scanner den Code voraus. Er fordert jedes Bild in einem <img>-src oder -srcset ohne loading="lazy" sofort an: Früher kann ein Download nicht starten. Jedes andere Foto startet später: Im Stylesheet wartet es auf diese Datei und das Layout. In einem Style-Attribut oder mit loading="lazy" wartet es auf das Layout – und das braucht vorher jedes render-blocking Stylesheet. Ein Slider oder Lazy-Load-Skript muss erst herunterladen und laufen, bevor es nach dem Foto fragt.

Diese Wartezeit, der Resource Load Delay, dauert meist länger als der eigentliche Download: Im Median wartet das Bild bei Websites mit schlechtem LCP 1.290 ms und lädt dann in 350 ms herunter (web.dev).

Für die Startseite eines Hotels – gebaut wie eine WordPress-Site mit Page-Builder – habe ich dasselbe Foto auf sieben Arten eingebunden und jeweils auf einem gedrosselten Smartphone geladen:

Median aus fünf Ladevorgängen in Sekunden auf Slow 4G mit 4-fach gedrosselter CPU. Das HTML traf jedes Mal nach 0,58 s ein.

Jede Version lud dasselbe 63-kB-Foto – außer das Style-Attribut, das nicht auf die kleinere Smartphone-Datei wechseln kann. Wann der Request startete, machte den Unterschied: Das Foto im HTML wurde angefordert, sobald das HTML eintraf. Die anderen warteten auf den First Paint bei 1,7 s oder die Skripte bei 2,4 s.

Die Hotel-Seite nach 2,5 Sekunden Ladezeit auf demselben gedrosselten Smartphone.

fetchpriority="high" sagt Chrome vom ersten Moment an, dass dieses Bild wichtig ist. Es bekommt mehr von der Verbindung. Auf einer vollen Seite, auf der das Foto mit Dutzenden Skripten und Stylesheets konkurriert, macht das den LCP schneller: Google maß auf Google Flights einen Rückgang von 2,6 s auf 1,9 s. Das hilft aber nur Bildern, die der Browser bereits gefunden hat: Ein Foto im Stylesheet oder Skript braucht zuerst die Änderung im HTML.

Warum bleibt fetchpriority=high rot, obwohl das Bild das Attribut hat?

Die Prüfung bewertet den Request, der dein LCP-Bild geladen hat. Suche im Quelltext – abgemeldet – nach dem Dateinamen des Fotos. Die typischen Ursachen (Lösungen unten):

• Ein Preload, den du nicht selbst geschrieben hast. Ein Theme, Hoster oder CDN kann einen Preload für das Foto im Link-Header oder in 103 Early Hints mitsenden; ein Cache-Plugin oder Next.js fügt ein <link rel="preload"> in den Head ein. Für einen Header öffnest du das Network-Panel in den DevTools, klickst auf den ersten Request (die Seite selbst) und liest die Headers.
• Ein Lazy-Load-Plugin hat das Bild umgeschrieben. Wenn auch die Prüfung auf Auffindbarkeit rot ist, prüfe das Foto auf data-src oder data-lazy-src: Ein Plugin hat die URL dorthin verschoben, und ein Skript fordert das Foto erst später an.
• WordPress hat das Attribut einem anderen Bild gegeben. WordPress setzt fetchpriority="high" auf das erste große Bild im sichtbaren Bereich (ab 50.000 Pixel). Ein Logo, das in doppelter Größe hochgeladen wurde – etwa 600 mal 200 Pixel –, kommt zuerst und schnappt sich das Attribut.
• Lighthouse hat ein anderes Bild gemessen. Das LCP-Element unten im Hinweis zeigt dir, welches. Auf dem Smartphone kann das ein separates Mobile-Hero-Bild sein, während das Desktop-Foto per CSS ausgeblendet ist und das Attribut trägt.

Die Hotel-Seite mit Lazy-Load-Skript: zwei rote Prüfungen. Lighthouse 13.6 mit DevTools-Drosselung.

Wie lange warten deine Besucher auf das LCP-Bild?

Deine field data zeigt, wie lange echte Besucher warten. Öffne in CoreDash den LCP Breakdown für Mobile und wähle LCP Priority unter More dimensions: Jede Zeile zeigt eine Ladeart des LCP-Bilds, aufgeschlüsselt nach dem p75-LCP. Der grüne Teil ist der Load Delay – die Wartezeit zwischen dem Eintreffen des HTML und dem Start des Bild-Downloads. Gruppiere nach URL, um Templates mit langen Verzögerungen zu finden.

CoreDash auf Mobile, p75: Vergleiche den grünen Bereich jeder LCP-Priority-Zeile.

Wie siehst du in den DevTools, wie spät das Bild gestartet ist?

Zeichne einen Trace auf im Performance-Panel der Chrome DevTools und öffne LCP request discovery in der Insights-Seitenleiste. Auf meiner Hotel-Testseite – mit dem Foto als Hintergrund im Stylesheet des Page-Builders – zeigt der Insight, wie lange nach dem ersten Byte des HTML (dem „earliest start point“) der Request des Fotos startete. Der gestreifte Balken im Network-Track markiert diese Wartezeit.

Der Request für das Foto startet erst nach den Stylesheets. Chrome DevTools, Performance-Panel, gedrosseltes Smartphone.

Im Network-Panel nennt die Spalte Initiator neben dem Foto die Datei, die es angefordert hat: ein Stylesheet, ein Slider-Skript oder das HTML, wenn es pünktlich gestartet ist.

Wie behebst du LCP-Request-Discovery?

Suche den Dateinamen des Fotos im Quelltext. In einem <img>-src oder -srcset findet der Browser das Bild früh. Steht es in data-src, einem Stylesheet oder gar nicht im Code: Genau das musst du ändern. Das Ziel ist überall gleich: das Foto als <img> im HTML, ohne loading="lazy", mit fetchpriority="high" auf genau diesem einen Bild. Ergänze fetchpriority="high" bei einem Preload, den du nicht selbst geschrieben hast, oder schalte ihn ab. Ersetze ein separates Mobile-Hero-Bild durch ein Foto für beide Bildschirmgrößen – oder nutze ein <picture> mit einem <source> für die Smartphone-Datei und fetchpriority="high" auf dem <img>.

WordPress und Lazy-Load-Plugins

WordPress schließt die ersten Bilder vom Lazy Loading aus und gibt dem ersten großen Bild fetchpriority="high". Wenn der Hinweis trotzdem rot ist, überschreibt meist ein Plugin dieses Verhalten:

• WP Rocket: Optimize Critical Images ist standardmäßig aktiv. Die Funktion ermittelt das LCP-Bild anhand echter Besuche, lädt es per Preload mit fetchpriority="high" vor und nimmt es aus dem LazyLoad heraus. Teste nach dem Neuaufbau des Caches erneut.
• Perfmatters: Setze Exclude Leading Images und Preload Critical Images auf die Anzahl der Bilder im ersten Viewport auf dem Smartphone – meist eins.
• LiteSpeed Cache: Trage den Dateinamen des Fotos in Lazy Load Image Excludes ein oder aktiviere Viewport Images.
• FlyingPress: Prüfe, ob das Foto loading="eager" und einen Preload hat. Falls nicht, schließe es vom Lazy Loading aus.

Lade ein Logo genau in der Größe hoch, in der es angezeigt wird, damit das Attribut an das Foto geht. Nutze nur einen einzigen Lazy-Loader – sonst bleibt das Foto verzögert geladen, obwohl du es in einem Tool ausgeschlossen hast. Im Cover-Block macht „Fester Hintergrund“ das Foto zu einem Hintergrund im Style-Attribut: Schalte die Option aus, und das Foto ist wieder ein <img>. Mein Plugin WP Core Web Vitals lernt das LCP-Bild pro Bildschirmgröße von deinen Besuchern und lädt es zuerst mit hoher Priorität.

Elementor und andere Page-Builder

Ein Foto als Hintergrund eines Elementor-Containers oder einer Section landet im CSS von Elementor. Der Browser findet es deshalb erst nach diesem CSS und dem Layout. Nutze ein Image-Widget für das Hero-Foto (ein Elementor-Hero mit Bild). Optimized Image Loading (Einstellungen, Performance) handhabt es dann wie WordPress. Lazy Load Background Images (standardmäßig aktiv) kann ein Hintergrund-Hero-Bild zusätzlich ausbremsen, wenn darüber noch eine Hinweisleiste liegt. Nutze auch in anderen Buildern ein Bild-Element für das erste Foto.

Slider

Der erste Slide muss als <img> im HTML stehen: ohne loading="lazy", mit fetchpriority="high". Die restlichen Slides erhalten loading="lazy" und fetchpriority="low". Ein Slider, der seine Slides per JavaScript aufbaut, startet den ersten Slide erst nach Ausführung des Skripts: Nutze einen Slider, der den ersten Slide direkt im HTML ausgibt, oder zeige auf Smartphones nur ein einzelnes Foto. Im Image Carousel von Elementor verschiebt der Schalter Lazyload jede Slide-URL nach data-src: Schalte ihn aus.

Shopify

Dawn, Horizon und darauf aufbauende Themes vergeben für das Bild in der ersten Section eines Templates fetchpriority="high" und laden es sofort. Mach das Banner oder die Slideshow also zur ersten Section. Auf einer Dawn-Produktseite fehlt dem Hauptbild fetchpriority: Ergänze in snippets/product-thumbnail.liquid fetchpriority: 'high' im image_tag, wenn lazy_load false ist (beim ersten Foto). Ein Theme-Update kann diese Datei überschreiben: Prüfe das Attribut danach. Ein Hero-Bereich, den eine App per JavaScript aufbaut, startet immer spät, egal was das Theme tut: Nutze eine Theme-Section.

In anderen Themes suchst du in der Datei der Section nach loading: 'lazy' oder einer lazyload-Klasse mit data-src und machst die Priorität von der Position der Section abhängig:

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

Ohne loading-Parameter lädt image_tag Bilder ab der vierten Section per Lazy Loading.

CSS-Hintergrundbilder

Gibt es in deinem Theme oder Builder keine Bild-Option, braucht das einen Entwickler. Wandle das Hintergrundbild zuerst in ein <img> um: Der Browser findet es dann direkt im HTML, und srcset lässt jeden Bildschirm die passende Datei wählen. object-fit füllt die Fläche wie zuvor das Hintergrundbild:

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

Muss es ein Hintergrundbild bleiben, lade die Datei per Preload vor, die das CSS je nach Bildschirmgröße auswählt – mit den Media Queries des CSS und fetchpriority="high". Ein Preload für eine andere Datei lädt das Foto doppelt herunter. Binde ihn nur im Template dieser Seite ein. Für CSS, das unter 768 px zur 768-px-Datei wechselt:

<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 und React

next/image nutzt standardmäßig Lazy Loading. Seit Next.js 15 setzt priority (preload in Version 16) das Bild auf eager und lädt es per Preload ohne fetchpriority – die Prüfung bleibt also rot. Setze beides selbst, ohne priority:

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

In Astro 5.10 und neuer setzt die priority-Prop an <Image> beides. Ein Hero-Bereich, den React erst im Browser rendert, existiert erst nach Ausführung des JavaScripts: Rendere ihn auf dem Server oder erstelle ein Prerendering der Seite, damit das <img> im HTML steht.

Ein Hero-Bereich, den du nicht ändern kannst

Ein A/B-Test, der das Foto austauscht, oder ein Widget, das den Hero-Bereich per JavaScript baut, verzögert den Start. Bleibt die URL des Fotos gleich, stößt ein Preload mit fetchpriority="high" in deinem eigenen Template den Download früh an. Bei einem langsamen Server kann 103 Early Hints ein Foto, das auf jedem Bildschirm dieselbe Datei nutzt, schon vor dem Eintreffen des HTML anfordern. Beides braucht einen Entwickler.

Startet das LCP-Bild jetzt zusammen mit dem HTML?

Starte Lighthouse erneut: drei grüne Haken und dein Foto als LCP-Element. In den DevTools beginnt der Request des Fotos direkt nach dem HTML. Bestanden und der LCP ist trotzdem langsam? Prüfe die anderen LCP-Anteile: ein langsamer Server (Time to First Byte), ein Foto mit langer Ladedauer (Load Duration) oder Stylesheets und Skripte, die das Rendering verzögern (Render Delay). Für echte Besucher beobachtest du den Load Delay auf Smartphones in CoreDash; die Search Console braucht bis zu 28 Tage.

Eine Core Web Vitals Power Hour ist für Fotos da, an die du auf dieser Seite nicht herankommst: eingebunden durch Page-Builder, Slider oder Apps ohne passende Einstellung – oder wenn alle drei Prüfungen grün sind, der LCP auf Smartphones aber langsam bleibt. Wir verfolgen das Bild in einem Trace deiner eigenen Seite vom HTML bis zum Bildschirm und finden heraus, was es ausbremst.