Kritische Bild-Extraktion für LCP und SEO

Zuletzt aktualisiert: June 28, 2026

Kritische Bildextraktion bedeutet, das eine einzige Bild zu finden, das den ersten visuellen Eindruck einer Seite steuert. Auf vielen Produktseiten, Landingpages und Blogbeiträgen ist dieses Bild der Hero, das Hauptproduktfoto oder eine große Illustration oberhalb des sichtbaren Bereichs (above-the-fold). Wenn Sie es frühzeitig identifizieren, können Sie die richtige Datei vorladen (preload) oder priorisieren, anstatt alle Bilder gleichmäßig zu beschleunigen.

Kurzantwort: Wie extrahiert man das kritische Bild?

Verwenden Sie die kritische Bildextraktion, um das Bild zu benennen, das am wahrscheinlichsten zum Largest Contentful Paint Element wird, und behandeln Sie diese Datei entsprechend besonders beim Laden. Normalerweise bedeutet dies, dass das größte sichtbare Bild im initialen Viewport fetchpriority="high" erhält, kein Lazy Loading verwendet wird, stabile Dimensionen aufweist und manchmal ein <link rel="preload"> hinzugefügt wird.

Laden Sie nicht alle großen Dateien vorab. Preloaden Sie das Hero- oder Produktbild nur dann, wenn der Browser es sonst verspätet entdecken würde – beispielsweise innerhalb von CSS, einem Karussell, einer clientseitig gerenderten Komponente oder einem responsiven <picture> Stack mit komplexer Quellenauswahl.

Überprüfen Sie nach der Änderung das Ergebnis. Googles Largest Contentful Paint documentation definiert LCP rund um das größte sichtbare Inhaltselement, und PageSpeed Insights zeigt an, welches Element gemessen wurde. Auch Chrome DevTools sollten die Anfrage für das kritische Bild frühzeitig im Waterfall anzeigen.

Verwenden Sie diese Reihenfolge:

1. Laden Sie die Seite bei einem realistischen mobilen Viewport.
2. Finden Sie das größte oberhalb des sichtbaren Bereichs liegende Bild oder Poster.
3. Überprüfen Sie, ob PageSpeed oder Lighthouse es als LCP meldet.
4. Entfernen Sie loading="lazy" von diesem Bild.
5. Fügen Sie Dimensionen oder ein Seitenverhältnis hinzu.
6. Fügen Sie fetchpriority="high", wenn es sich um ein <img> handelt.
7. Preloaden Sie nur, wenn die Entdeckung verspätet ist.
8. Behalten Sie Bilder unterhalb des sichtbaren Bereichs (below-fold) als Lazy.
9. Testen Sie nach Änderungen am Layout, CMS oder Hero-Text erneut.

Was gilt als kritisches Bild?

Ein kritisches Bild ist das Bild, auf das ein Besucher wartet, bevor die Seite nützlich erscheint. Es ist oft, aber nicht immer, das LCP Element. Ein kleines Logo oben auf der Seite kann zuerst geladen werden, steuert aber selten die wahrgenommene Bereitschaft. Ein Hero-Bild, das die Hälfte des Handybildschirms einnimmt, tut dies normalerweise.

Verwenden Sie zusammen gerenderte Größe, Viewport-Position und Zweck. Eine Miniaturansicht in einem Navigationsmenü ist sichtbar, aber sie ist nicht der Hauptinhalt. Ein Hintergrundbild hinter der Überschrift kann kritisch sein, wenn es das größte sichtbare Element ist. Ein Social Card Bild in Metadaten ist wichtig für das Teilen, wird aber nicht für die gerenderte Seite abgerufen, es sei denn, das Template zeigt es ebenfalls an.

Googles LCP-Richtlinien nennen <img> Elemente, Bildelemente innerhalb von SVG, Video-Posterbilder und CSS Hintergrundbilder als mögliche Kandidaten. Das bedeutet, dass die Extraktion nicht bei der Suche nach dem ersten <img> Tag enden kann. Sie müssen die gerenderte Seite inspizieren.

Für verwandte Arbeiten behalten Sie die allgemeine image optimization for SEO Checkliste griffbereit. Die kritische Bildextraktion entscheidet über die Priorität; Kompression, Dateinamen, Alt-Text und strukturierter Inhalt entscheiden immer noch darüber, ob das Bild nützlich ist, nachdem es geladen wurde.

Welches Bild sollte Preload oder hohe Priorität erhalten?

Geben Sie nur einem Bild hohe Priorität: dem wahrscheinlichen LCP-Bild der aktuellen Seite. Wenn zwei Kandidaten nah beieinander liegen, wählen Sie den größten auf Mobilgeräten zuerst, da die Core Web Vitals für mobile Geräte normalerweise schwieriger zu bestehen sind.

Verwenden Sie fetchpriority="high", wenn das kritische Bild ein normales <img> oder das Fallback-<img> in einem <picture> Element ist. Googles fetch priority guidance erklärt, dass dieser Hinweis die Ressourcenpriorität des Browsers ändert, ohne den Pfad der Markup-Entdeckung zu ändern.

Verwenden Sie Preload, wenn die Entdeckung das Problem ist. MDN's rel="preload" reference beschreibt Preload als eine Möglichkeit, Ressourcen früher beim Seitenladen anzufordern. Das hilft, wenn die Bild-URL in CSS erscheint, nach der Hydratation eintrifft oder hinter Markup liegt, das der Browser nicht schnell genug entdecken kann.

Für ein normales responsives Bild kann das Markup wie folgt aussehen:

<img
  src="/images/product-hero-960.webp"
  srcset="/images/product-hero-480.webp 480w, /images/product-hero-960.webp 960w, /images/product-hero-1440.webp 1440w"
  sizes="(max-width: 640px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="Black leather backpack shown open with laptop sleeve visible"
>

Wenn das Bild ein CSS Hintergrund ist und Sie es noch nicht in HTML verschieben können, preloaden Sie dasselbe Asset, das der initiale Viewport verwenden wird:

<link
  rel="preload"
  as="image"
  href="/images/home-hero-960.webp"
  imagesrcset="/images/home-hero-480.webp 480w, /images/home-hero-960.webp 960w"
  imagesizes="100vw"
>

Die image preloading guide behandelt die Syntax detaillierter. Die wichtige Regel hier ist enger gefasst: Preloaden Sie nach der Extraktion, nicht davor.

Wie vermeidet man das Lazy-Loading des falschen Bildes?

Lazy Loading gehört unterhalb des ersten Viewports. Es ist ein Fehler beim kritischen Bild, weil es dem Browser mitteilt, bis zu warten, bis Layout- und Distanzprüfungen durchgeführt wurden. Googles browser-level lazy loading guide warnt vor dem Lazy Loading von Bildern, die sofort sichtbar sind.

Überprüfen Sie globale Image Components sorgfältig. Viele Frameworks machen Lazy Loading zum Standard, da die meisten Bilder unterhalb des sichtbaren Bereichs liegen. Dieser Standard bricht Seiten, bei denen das Hero-Bild in derselben Komponente wie Galerie-Miniaturansichten verpackt ist.

Prüfen Sie diese Stellen:

1. CMS rich-text image renderers.
2. Product gallery components.
3. Blog cover image components.
4. Homepage hero background utilities.
5. Sliders, die alle Slides ausblenden, bis JavaScript läuft.
6. Placeholder components, die data-src in src austauschen.
7. Third-party personalization blocks.
8. A/B testing wrappers, die das Hero Markup verzögern.

Die Lösung ist meist klein. Fügen Sie der Komponente eine Option wie priority, aboveFold oder isLcp hinzu und lassen Sie den Template-Betreiber diese explizit wählen. Bilder unterhalb des sichtbaren Bereichs sollten weiterhin natives Lazy Loading verwenden, insbesondere lange Guides mit Screenshots und Diagrammen.

Für mobillastige Seiten kombinieren Sie dies mit dem mobile image optimization guide. Ein korrekt priorisiertes Hero leistet immer noch schlechte Arbeit, wenn das Handy einen 2400 px Desktop-Ausschnitt für einen 390 px Slot herunterlädt.

Wie sollte man Bilder von einer echten Seite extrahieren?

Beginnen Sie im Browser, nicht in der Asset Library. Die Asset Library sagt Ihnen, was existiert; der Browser sagt Ihnen, was die Benutzer erhalten.

Verwenden Sie diesen manuellen Workflow:

1. Öffnen Sie die Seite bei 390 px Breite und laden Sie sie mit deaktiviertem Cache neu.
2. Notieren Sie das größte sichtbare Bild vor dem Scrollen.
3. Inspizieren Sie dieses Element und protokollieren Sie dessen finale URL.
4. Überprüfen Sie, ob es sich um ein <img>, <picture>, Video-Poster oder CSS Hintergrund handelt.
5. Bestätigen Sie die gerenderte Breite und Höhe.
6. Vergleichen Sie die heruntergeladene Dateibreite mit dem gerenderten Slot.
7. Suchen Sie nach loading="lazy" oder JavaScript-verzögerter src-Zuweisung.
8. Überprüfen Sie DevTools Network auf Startzeitpunkt und Priorität der Anfrage.
9. Führen Sie PageSpeed Insights aus und protokollieren Sie das LCP Element.
10. Wiederholen Sie dies für den Desktop, falls sich das Hero beim Breakpoint ändert.

Für Template-Audits erstellen Sie eine kleine Extraktionstabelle, bevor Sie Code bearbeiten:

Ich habe die Diagramme in diesem Artikel als WebP Dateien generiert und jedes unter 40 KB gehalten. Das ist kein universelles Ziel für Fotos, aber es ist eine nützliche Erinnerung: das extrahierte Bild sollte vor der Priorisierung richtig dimensioniert sein. Ist die Datei immer noch riesig, verwenden Sie den image compression deep dive und den batch resize guide, bevor Sie es veröffentlichen.

Wie verifiziert man das kritische Bild in Tools?

Die Verifizierung hat zwei Aufgaben. Erstens, beweisen Sie, dass das ausgewählte Bild tatsächlich das LCP Element oder ein ernster LCP Kandidat ist. Zweitens, beweisen Sie, dass der Browser es früh genug entdeckt.

Verwenden Sie PageSpeed Insights für Feld- und Laborkontext. Das Diagnosepanel benennt normalerweise das LCP Element, und der Screenshot hilft zu bestätigen, ob das gemeldete Element mit dem visuellen Hero der Seite übereinstimmt. Verwenden Sie Lighthouse oder DevTools Performance, wenn Sie einen lokalen Trace benötigen.

Verwenden Sie DevTools Network für das Anforderungsverhalten:

1. Filtern Sie nach Bildanfragen (image requests).
2. Laden Sie die Seite mit deaktiviertem Cache neu.
3. Bestätigen Sie, dass das kritische Bild nahe dem oberen Ende des Waterfall beginnt.
4. Überprüfen Sie, ob die Priorität hoch ist oder frühzeitig erhöht wird.
5. Bestätigen Sie, dass Bilder unterhalb des sichtbaren Bereichs nicht alle gleichzeitig konkurrieren.
6. Überprüfen Sie den Statuscode, den Inhaltstyp, die Übertragungsgröße und die Cache-Header.

Verwenden Sie gerenderte HTML-Inspektion für Markup-Fehler:

1. Das kritische Bild hat src oder ein entdeckbares srcset im initialen Markup.
2. Es hat kein loading="lazy".
3. Es hat width und height oder ein stabiles CSS Seitenverhältnis.
4. Sein Alt-Text beschreibt das sichtbare Motiv, wenn das Bild Inhalt ist.
5. Die CDN URL gibt eine crawlable 200 Antwort zurück.

Für die Suche betonen Googles image SEO best practices ebenfalls deskriptive Dateinamen, Alt-Text und nützlichen umgebenden Text. Die kritische Bildextraktion verbessert die Ladepriorität, aber das gleiche Bild benötigt immer noch einen Suchkontext.

Was stört die kritische Bildextraktion?

Das häufigste Versagen ist die Behandlung jeder Seite so, als hätte sie denselben Hero. Ein Blog-Index, eine Produktseite und eine Preissetzungsseite können unterschiedliche LCP Kandidaten haben. Der Extraktionsschritt muss auf Template-Ebene und auf Breakpoint-Ebene erfolgen.

Achten Sie auf diese Fallen:

1. Preloading des Open Graph Bildes. Das Social Card Bild wird auf der Seite möglicherweise nie gerendert.
2. Lazy-Loading des ersten Produktfotos. Produktgalerien erben oft Miniaturansicht-Standardeinstellungen.
3. Priorisieren jedes Karussell-Slide. Nur das erste sichtbare Slide kann beim Laden kritisch sein.
4. Ignorieren von mobilen Crops. Desktop und Mobil können unterschiedliche LCP Bilder auswählen.
5. Verwendung von CSS Backgrounds für bedeutungsvollen Inhalt. Sie sind schwieriger zu priorisieren und weniger zugänglich.
6. Vergessen der Dimensionen. Priorität verhindert nicht Layout Shift.
7. Versenden eines überdimensionierten Sources. Ein hochpriorisiertes 3 MB Bild ist immer noch langsam.
8. Testen nur im lokalen WLAN. Langsames 4G legt Entdeckungsverzögerungen offen.

Wenn das Problem hauptsächlich die Dateigewicht sind, beginnen Sie mit der complete image optimization checklist. Wenn das Problem die Formatwahl ist, vergleichen Sie AVIF vs WebP, bevor Sie die Lieferregeln ändern.

Zusammenfassung: Checkliste zur kritischen Bildextraktion

Die kritische Bildextraktion ist eine Entscheidung über die Seitenleistung, kein Asset-Namensgebungsgewinnspiel. Finden Sie das Bild, das den ersten Viewport steuert, geben Sie nur diesem Bild eine frühe Ladebehandlung und verhindern Sie, dass der Rest der Seite mit ihm konkurriert.

Bestätigen Sie vor der Veröffentlichung:

1. Das wahrscheinliche LCP Bild ist im Template oder in den Audit-Notizen benannt.
2. Mobile und Desktop Kandidaten werden separat geprüft.
3. Das kritische Bild wird nicht lazy-loaded.
4. fetchpriority="high" wird für einen sichtbaren <img> LCP Kandidaten verwendet.
5. Preload wird nur verwendet, wenn die Entdeckung verspätet ist.
6. Die ausgewählte Datei wird skaliert und komprimiert.
7. Breite und Höhe oder ein Seitenverhältnis reservieren den Layout-Platz.
8. Bilder unterhalb des sichtbaren Bereichs bleiben lazy.
9. PageSpeed Insights meldet das erwartete LCP Element.
10. DevTools zeigt die kritische Bildanfrage frühzeitig im Waterfall.
11. Die CDN URL gibt 200 mit dem erwarteten Bildtyp zurück.
12. Das Bild hat einen nützlichen Alt-Text und nahegelegenen erklärenden Inhalt.

Image credits

• Cover, LCP candidate diagram, priority decision tree, and verification trace were generated for this article with ImageMagick and exported as WebP.