Lazy Loading im SEO

TL;DR – Lazy Loading weist den Browser an, Bilder und eingebettete Inhalte erst dann herunterzuladen, wenn Sie kurz davor sind, zu ihnen zu scrollen. So lädt die Seite anfangs schneller. Der einfache, codefreie Weg ist, loading="lazy" zu einem <img> oder <iframe> hinzuzufügen. Eine Regel sollten Sie beachten: Laden Sie das große Bild oben auf der Seite nicht lazy – das lässt die Seite langsamer wirken, nicht schneller.

Was Lazy Loading ist

Normalerweise versucht ein Browser beim Öffnen einer Seite, alles sofort herunterzuladen – jedes Bild, jede eingebettete Karte oder jedes Video. Bei einer langen Seite mit vielen Bildern ist das eine Menge Downloads für Inhalte, die Sie vielleicht nie zu Gesicht bekommen, wenn Sie nicht nach unten scrollen.

Lazy Loading behebt das. Es verschiebt das Laden von Bildern und eingebetteten Inhalten außerhalb des sichtbaren Bereichs, bis Sie kurz davor sind, sie in den Blick zu bekommen. Die Seite zeigt Ihnen schnell, was oben ist, und der Rest lädt, während Sie scrollen. Weniger Daten am Anfang bedeuten einen schnelleren ersten Eindruck, plus Einsparungen bei Bandbreite und Akku – das ist besonders auf Smartphones wichtig.

Der einfache Weg: das loading-Attribut

Früher brauchte man dafür eine JavaScript-Bibliothek. Das ist nicht mehr nötig. Moderne Browser haben das eingebaut. Sie fügen einfach ein Attribut hinzu:

<img src="photo.jpg" loading="lazy" alt="…">

Das war’s. Es funktioniert bei <img> und <iframe> (denken Sie an eingebettete YouTube-Videos, Google Maps, Social Widgets) in allen gängigen Browsern, ganz ohne JavaScript.

Der eine Fehler, den Sie vermeiden sollten

Laden Sie das große Bild oben auf der Seite nicht lazy – das Hero-Bild, das, was die Leute zuerst sehen. Lazy Loading sagt dem Browser: „Das kann warten.“ Dadurch lädt ein lazy geladenes Bild oben später als es sollte, und die Seite fühlt sich langsamer an. Googles eigene Empfehlung lautet, Lazy Loading für alles zu überspringen, das beim Öffnen der Seite sofort sichtbar ist.

Kurz gesagt: Laden Sie die Inhalte unterhalb des sichtbaren Bereichs lazy, die Inhalte oberhalb des sichtbaren Bereichs normal.

Schadet es dem SEO?

Für sich genommen nein. Google kann lazy geladene Bilder und Inhalte problemlos indexieren, wenn es auf die normale Weise gemacht wird. Probleme entstehen erst, wenn eine Seite Inhalte hinter Scrollen oder Klicken versteckt – denn Suchmaschinen scrollen und klicken nicht. Wenn Ihre Bilder einfach loading="lazy" verwenden, sind Sie auf der sicheren Seite. Möchten Sie die Details wissen, wie Google das tatsächlich sieht, und wie Sie es überprüfen können? Wechseln Sie zum Erweitert-Tab.

TL;DR – Lazy Loading verschiebt Bilder und Iframes außerhalb des sichtbaren Bereichs, bis sie sich dem Viewport nähern. Das reduziert das anfängliche Seitengewicht (hilft beim LCP) und die Haupt-Thread-Arbeit beim Start (hilft beim INP). Das native loading="lazy"-Attribut auf <img>/<iframe> hat die meisten JS-Bibliotheken ersetzt; nur lazy und eager sind sinnvolle Werte (auto ist veraltet). Die schädlichen Fehler: das LCP-Bild bzw. das Bild oberhalb des Folds lazy zu laden (verzögert genau die Metrik, die Sie verbessern wollen) und Inhalte hinter Scrollen/Klicken zu verstecken – was Googlebot nie auslöst, weil es nicht mit der Seite interagiert. Es ist kein direkter Ranking-Faktor; die Wirkung läuft über Core Web Vitals und Crawlbarkeit. Überprüfen Sie im URL-Inspektionstool der Google Search Console, dass Bild-URLs im src-Attribut des gerenderten HTML landen.

Was Lazy Loading tatsächlich bewirkt

Die Idee ist einfach: Ressourcen sollten erst geladen werden, wenn sie gebraucht werden, statt alle auf einmal. Auf einer medienlastigen Seite hält das sofortige Herunterladen jedes Bildes und eingebetteten Inhalts den Browser damit beschäftigt, Dinge zu holen, welche die besuchende Person vielleicht nie sieht – das verschwendet Bandbreite, Speicher und Akku. Das Verschieben der Inhalte außerhalb des sichtbaren Bereichs lässt den Inhalt oberhalb des Folds schneller erscheinen. Martin Splitt hat genau diesen Punkt in Googles Folge „Lazy Loading verständlich erklärt“ angesprochen: Das Ziel ist, Arbeit zu vermeiden, die nichts bringt, denn nicht-kritische Bilder, auf welche die Seite gut verzichten könnte, halten den Browser nur beschäftigt.

Dies steht im Zusammenhang mit den Core Web Vitals, auf die viele achten. Weniger Bytes, die anfangs um das Netzwerk konkurrieren, bedeuten, dass das Largest Contentful Paint-Element früher gerendert werden kann. Bei Iframes – Anzeigen, Social Widgets, Kommentarbereiche, Karten – reduziert das Aufschieben auch die Arbeit des Hauptthreads während des Starts, was ein Gewinn für Interaction to Next Paint ist, nicht nur für LCP. Die eigene web.dev-Anleitung von Google bezeichnet Lazy-Loading-Iframes als eine INP-Verbesserung während des Seitenladens.

Nativer vs. JavaScript-gesteuerter Lazy Loading

Vor einigen Jahren erhielten Browser ein natives loading-Attribut für Bilder und Iframes, so dass Sie die gesamte Aufgabe dem Browser überlassen können, anstatt eine JavaScript-API einzurichten. In meinem JavaScript-SEO-Leitfaden bei Ahrefs mache ich dieselbe Beobachtung: Seit ich diesen Beitrag ursprünglich geschrieben habe, hat sich Lazy Loading weitgehend von JavaScript-gesteuert zu browserbasiert entwickelt. Sie werden weiterhin auf JS-gesteuerte Setups stoßen, und bei Bildern sind diese in der Regel in Ordnung – ich prüfe, ob tatsächliche Inhalte (nicht nur Bilder) lazy geladen werden, denn diese Setups haben dazu geführt, dass Inhalte nicht korrekt erfasst wurden.

Die native Version:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Legen Sie bei Lazy-Bildern immer explizite width/height (oder ein Seitenverhältnis) fest, damit der Browser den Platz reserviert, bevor das Bild geladen wird – das ist das größte Layout-Shift-Risiko bei verzögerten Bildern. Reservierte Abmessungen sind jedoch keine absolute CLS-Garantie: Wenn sich das umgebende Layout oder ein responsiver Zuschnitt nach dem Laden des Bildes noch ändert, kann es weiterhin zu einem Shift kommen. Bestätigen Sie dies daher mit einer echten Layout-Shift-Aufzeichnung, anstatt anzunehmen, dass feste Abmessungen allein das Problem lösen.

Lazy Loading und Iframes benötigen eine weitere Unterscheidung: loading="lazy" auf einem <iframe> verzögert nur wann das Abrufen und Erstellen des Embeds erfolgt. Es legt nicht dessen title, Fokusverhalten, sandbox, allow/Permissions-Policy, referrerpolicy, Einwilligungshandhabung oder Abmessungen für Sie fest – diese benötigen weiterhin eigene Aufmerksamkeit, und ein Embed kann weiterhin Arbeit verrichten (Skripte, Tracking-Pixel, Layout), sobald es für das Laden in Frage kommt. Und gehen Sie nicht davon aus, dass “below the fold” überall gleich funktioniert: display: none-Inhalte, Offscreen-Karussellfolien, transformierte Elemente und verschachtelte Scroll-Container können den Viewport anders schneiden als ein einfaches Element unterhalb der Falz. Testen Sie daher das tatsächliche Layout und die Navigationssteuerung, anstatt Gleichheit anzunehmen.

Die Werte des loading-Attributs

Nur zwei Werte sind heute relevant:

• loading="lazy" – Ressource verzögern, bis sie sich in der Nähe des Viewports befindet.
• loading="eager" – sofort laden, das Standardverhalten. Verwenden Sie es, um Bilder oberhalb der Falz explizit zu kennzeichnen.

In älteren Artikeln sehen Sie möglicherweise loading="auto" – es ist in Chrome veraltet, also greifen Sie nicht darauf zurück. Es besteht keine Notwendigkeit; das Weglassen des Attributs liefert bereits das Standardverhalten (eager).

Wie nah ist “nah”? loading="lazy" ist ein Hinweis, keine vom Autor kontrollierte Garantie – die Spezifikation überlässt die tatsächliche Entscheidung über die Nähe zum Viewport dem Browser. Chromium versucht, eine Lazy-Ressource früh genug abzurufen, damit sie bereit ist, wenn Sie zu ihr scrollen, und die Auslöseentfernung variiert je nach Browser, Verbindungsgeschwindigkeit und Ressourcentyp; es ist kein fester Pixelwert, auf den Sie sich verlassen oder den Sie über Browser und Versionen hinweg reproduzieren können. Veröffentlichen Sie keine – und vertrauen Sie keiner – spezifischen Zahl wie “lädt N Pixel vor dem Viewport”; behandeln Sie das Fenster nahe dem Viewport als implementierungsdefiniert und bestätigen Sie das tatsächliche Verhalten mit einer Netzwerkaufzeichnung im Browser/bei der Verbindung, die Ihnen wichtig ist, anstatt eine Konstante anzunehmen.

Natives Lazy Loading funktioniert auch gut mit responsiven Bildern: Es gilt für die normale src- und srcset/sizes-Auswahl, sodass Sie durch das Hinzufügen von loading="lazy" kein responsives Bildverhalten verlieren. Wenn Sie die echte URL stattdessen nur in einem data-*-Attribut verstecken, damit ein Skript sie später austauscht, hängt das Laden nun von diesem Skript ab – testen Sie das gerenderte HTML und was passiert, wenn das Skript fehlschlägt (mehr dazu in den Tabs Skripte und Fehlerbehebung).

Der häufigste Fehler: Lazy Loading des LCP-Bildes / des Bildes über dem Falz

Das ist der Fehler, den ich am häufigsten sehe, und alle Quellen sind sich einig. Wenn Sie das Hero-Bild – oder ein beliebiges Bild, das wahrscheinlich das LCP-Element ist – per Lazy Loading laden, haben Sie dem Browser gesagt, er solle auf das wichtigste Pixel für die wahrgenommene Ladegeschwindigkeit warten. Der Browser kann ein Bild außerdem erst dann per Lazy Loading laden, wenn er weiß, wo das Bild auf der Seite platziert wird. Daher laden Bilder über dem Falz mit Lazy Loading tendenziell langsamer als ohne. Das verzögert direkt den Largest Contentful Paint, die Metrik, die Google zufolge innerhalb der ersten 2,5 Sekunden nach dem Laden erreicht werden sollte.

Splitt formulierte die Kehrseite in der SOTR-Episode deutlich: Wenn Sie Lazy Loading nicht dort einsetzen, wo Sie es sollten, wird das wahrscheinlich einen Aspekt der Core Web Vitals beeinträchtigen – höchstwahrscheinlich LCP. Es wirkt also in beide Richtungen. Die Regel:

• Wahrscheinlicher oder beobachteter LCP-Kandidat → eagerly laden (loading="lazy" weglassen oder eager setzen). Erwägen Sie fetchpriority="high" für das LCP-Bild.
• Unterhalb des Falzes → loading="lazy".

Nicht jedes Bild über dem Falz ist der LCP-Kandidat – identifizieren Sie das tatsächliche (ein Performance-Trace oder PageSpeed Insights nennt es) und überprüfen Sie dessen Anfragezeitpunkt, anstatt jedes Bild im ersten Bildschirm gleich zu behandeln. Und das sind getrennte Hinweise, keine einzelne Einstellung: loading="eager" (oder das Weglassen von loading) bedeutet nur, dass der Browser die Entdeckung der Ressource nicht aufschiebt – es erhöht selbst nicht die Abrufpriorität. fetchpriority ist ein separater, beratender Hinweis zusätzlich dazu. Ein <link rel="preload"> zusammen mit loading="lazy" für dieselbe Ressource sendet dem Browser widersprüchliche Absichten. Überprüfen Sie daher den tatsächlichen Netzwerk-Wasserfall, anstatt anzunehmen, dass die Kombination das tut, was Sie erwarten.

Das pauschale Anti-Pattern ist das Aktivieren von Lazy Loading für jedes Bild auf der gesamten Website – eine häufige CMS-Standardeinstellung. Wie Splitt anmerkte: Wenn jedes Bild per Lazy Loading geladen wird, werden auch Bilder, die sofort sichtbar sind (oder sein sollten), per Lazy Loading geladen – genau der Fall, den Sie vermeiden möchten.

Wie Googlebot lazy-geladene Inhalte rendert

Hier ist die Crawling-Realität, über die viele stolpern: Googlebot scrollt nicht und klickt nicht. Er rendert Ihre Seite mit einem Headless-Browser, simuliert aber keine Benutzerinteraktion. Google sagt das direkt – seine empfohlenen Lazy-Loading-Methoden verlassen sich bewusst nicht auf Benutzeraktionen wie Scrollen oder Klicken, weil Google Search nicht mit Ihrer Seite interagiert.

Deshalb ist das Wie Ihrer Implementierung entscheidend. Googles Dokumentation listet drei Implementierungen auf, die es als sicher betrachtet: das eingebaute Lazy Loading des Browsers für Bilder und Iframes, die IntersectionObserver-API (mit einem Polyfill) oder eine JavaScript-Bibliothek, die Daten lädt, sobald sie in den Viewport gelangen. Alle drei basieren auf der Viewport-Überschneidung – nicht auf einem Scroll- oder Klick-Ereignis, das Googlebot nie auslösen wird.

Das Hochrisikomuster ist eine eigene Skriptbibliothek oder eine Drittanbieterbibliothek für verzögertes Laden. Wenn die Bibliothek sich fehlerhaft verhält und die Bildadresse nie im src-Attribut landet, wird Google dieses Bild einfach nicht aufnehmen — Splitt beschrieb genau diesen Fehlermodus in der SOTR-Episode. Es gibt nichts zu indizieren, wenn die URL nicht vorhanden ist. Das ist dasselbe, was ich in meinem JavaScript-SEO-Leitfaden anspreche: Bild-Lazy-Loading ist in der Regel in Ordnung, aber bei lazy-geladenen Inhalten schleichen sich Indizierungsprobleme ein, und die Lösung ist, zu prüfen, was Google tatsächlich rendert. Google sagt es ausdrücklich: “Check the rendered HTML to make sure your content is in the rendered HTML.” (Übersetzung) „Prüfen Sie das gerenderte HTML, um sicherzustellen, dass Ihre Inhalte darin enthalten sind.“ Googles Dokumentation

Unendliches Scrollen ist ein anderes Problem

Verwechseln Sie das einfache Lazy Loading von Bildern/iframes nicht mit Infinite Scroll oder paginiertem Laden. Das Zurückstellen von Bildern ist eine Sache; das Laden neuer Inhaltsblöcke beim Scrollen des Nutzers ist eine andere und erfordert eine eigene Architektur. Die Anleitung von Google: Geben Sie jedem Block eine dauerhafte, eindeutige URL, halten Sie den Inhalt pro URL stabil (verwenden Sie absolute Seitennummern wie ?page=12, nicht relative Werte wie ?date=yesterday), und aktualisieren Sie die angezeigte URL über die History API, sobald ein Block zum primär sichtbaren Inhalt wird, damit er aktualisiert, geteilt und verlinkt werden kann. Wenn Sie das überspringen, wird der tiefere Inhalt hinter einem endlosen Scroll möglicherweise nie zuverlässig gecrawlt oder indexiert.

So testen Sie es

Der Verifizierungspfad ist in Googles Dokumentation und in meiner eigenen Methodik derselbe: Verwenden Sie das URL Inspection Tool der Search Console und prüfen Sie das gerenderte HTML. Wenn Ihre Bild- (oder Video-) URLs im src-Attribut der <img>/<video>-Elemente in diesem gerenderten HTML erscheinen, funktioniert Ihr Setup. Google sagt dies ausdrücklich — prüfen Sie das gerenderte HTML, um sicherzustellen, dass Ihr Inhalt darin enthalten ist. Wenn die URL in src fehlt, ist das Ihr Problem, und es führt in der Regel auf einen Scroll-/Klick-Trigger oder eine defekte Bibliothek zurück.

Für ein lazy-loadendes Produktraster gehen Sie über diese Präsenzprüfung hinaus. Führen Sie die Infinite Scroll SEO-Testmatrix mit Standard- und hohen Viewports durch, mit frischer Navigation und Größenänderung nach dem Laden, mit Läufen ohne Aktion und mit inkrementellem Scrollen, mit eindeutigen Produktlink-Zählungen und mit einer Prüfung des Accessibility-Baums. Das Ändern der Größe einer initialisierten Seite ist nicht gleichbedeutend mit der Navigation bei der endgültigen Viewport-Größe, da Observer und Batch-Berechnungen möglicherweise nur während des Startvorgangs registriert werden. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: 2026-07-14 Google Search Central: Lazy-load content

Sie können sich auch auf Ihre Werkzeuge zur Webleistung stützen: PageSpeed Insights markiert Bilder außerhalb des sichtbaren Bereichs, die Sie verschieben sollten. In meinem PageSpeed-Insights-Leitfaden bei Ahrefs weise ich darauf hin, dass der Audit „defer offscreen elements“ Ihnen sagt, Bilder lazy zu laden – ein praktischer Weg, die Diagnose, die Sie bereits ausführen, mit der Lösung zu verbinden.

Ranking-Signal-Ehrlichkeit

Machen Sie klar, was Lazy Loading ist und was nicht. Die Verwendung ist kein direkter Ranking-Faktor, und die Nichtverwendung ist keine Strafe. Der Zusammenhang zum Ranking ist indirekt: Er verläuft über die Core Web Vitals (hauptsächlich LCP, manchmal INP bei iframes) und über die Crawlbarkeit, wenn eine schlechte Implementierung Inhalte versteckt. Splitt charakterisierte den Ranking-Effekt über die Core Web Vitals in den meisten Fällen als winzigen, minimalen Faktor. Optimieren Sie Lazy Loading also für die Ladeerfahrung Ihrer Nutzer und für eine saubere Indexierung – nicht, weil Sie von dem Attribut selbst einen Ranking-Sprung erwarten.

Wo dies einzuordnen ist

Lazy Loading ist ein Hebel im breiteren Werkzeugkasten für die Webleistung. Es ergänzt sich mit Ressourcenhinweisen (Preload/Preconnect für die Ressourcen, die Sie früh möchten), der Schriftlade-Strategie, Caching und einem CDN – und wird letztlich über Core Web Vitals bewertet. Wenn die Aufteilung in Inhalte „oberhalb des sichtbaren Bereichs“ und „unterhalb des sichtbaren Bereichs“ stimmt, ist es einer der günstigsten verfügbaren Gewinne.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Lazy Loading verschiebt Bilder und Iframes außerhalb des Bildschirms, bis sie sich dem Viewport nähern – das reduziert das anfängliche Seitengewicht und die Startarbeit. Der native Weg ohne JavaScript ist loading="lazy" auf <img> und <iframe>; er hat JS-Bibliotheken weitgehend ersetzt. Es ist ein Browser-Hinweis, keine garantierte Entfernung oder Zeitsteuerung – der Auslösepunkt variiert je nach Browser, Verbindung und Ressourcentyp, verlassen Sie sich also nicht auf eine feste Pixelzahl.
• Werte: Nur lazy und eager sind relevant. auto ist in Chrome veraltet.
• Core-Web-Vitals-Zusammenhang: Weniger anfängliche Bytes helfen LCP; das Verschieben von Iframes reduziert die Haupt-Thread-Arbeit beim Start und hilft INP. Setzen Sie width/height, damit verschobene Bilder kein CLS verursachen – reservierte Abmessungen allein garantieren jedoch keine Nullverschiebung, wenn sich das umgebende Layout weiterhin ändert.
• Häufigster Fehler: Lazy Loading des wahrscheinlichen/beobachteten LCP-Bildes, nicht nur eines beliebigen Bildes über dem Falz. Es verzögert Largest Contentful Paint, das laut Google innerhalb von 2,5 s erreicht werden sollte. eager/das Weglassen von loading beeinflusst nur die Erkennung – es erhöht nicht selbst die Abrufpriorität; fetchpriority ist ein separater Hinweis, und das Stapeln von preload mit loading="lazy" auf derselben Ressource widerspricht sich. Pauschales Lazy Loading auf der gesamten Website ist das häufige CMS-Antimuster.
• Iframes haben ihren eigenen Vertrag: loading="lazy" verschiebt nur den Zeitpunkt des Abrufs/der Erstellung – Titel, Sandbox, Berechtigungsrichtlinie, Referrer-Richtlinie, Einwilligung und Abmessungen müssen weiterhin unabhängig gesetzt werden, und ausgeblendete/Karussell-/transformierte Layouts können den Viewport anders schneiden als ein einfaches Element unterhalb des Falzes.
• Googlebot scrollt nicht und klickt nicht. Inhalte, die hinter Scroll-/Klick-Ereignissen verborgen sind, können ungesehen bleiben. Googles sichere Methoden – natives Lazy Loading, IntersectionObserver oder eine gut funktionierende JS-Bibliothek – basieren alle auf der Viewport-Überschneidung.
• Höchstes Risiko: Benutzerdefinierte/Third-Party-JS-Lazy-Load-Bibliotheken. Wenn die URL nie in src landet, indexiert Google das Bild nicht (laut Martin Splitt).
• Unendliches Scrollen ist anders: Es benötigt eindeutige paginierte URLs + History API.
• Überprüfen Sie in der URL-Inspektion der Google Search Console → gerendertes HTML → Bild-URLs im src-Attribut vorhanden.
• Kein direkter Ranking-Faktor. Die Wirkung ist indirekt über Core Web Vitals und Crawlbarkeit, und Splitt nannte den Ranking-Effekt von Core Web Vitals winzig.

Offizielle Dokumentation

Primärquellen-Leitfaden von den Suchmaschinen und Googles web.dev.

Google – Search Central

• Lazy-geladene Website-Inhalte beheben – das maßgebliche Dokument: sichere Implementierungsmethoden, die Regel „Google interagiert nicht mit Ihrer Seite“, Anforderungen für unendliches Scrollen/paginiertes Laden und die Überprüfung im gerenderten HTML.
• JavaScript-SEO-Grundlagen verstehen – empfiehlt Lazy Loading von Bildern als Best Practice für Bandbreite/Leistung und verlinkt auf den speziellen Leitfaden.
• Core Web Vitals – warum Lazy Loading des LCP-Elements kontraproduktiv ist (LCP-Ziel ist 2,5 s).

Google – web.dev (Learn Performance)

• Bilder und <iframe>-Elemente verzögert laden – wann verschoben werden sollte und der INP-Vorteil von Lazy-Iframes.
• Browserseitiges Lazy Loading von Bildern im Web – das native Attribut und warum In-Viewport-/LCP-Bilder nicht lazy geladen werden sollten.
• Zeit, Iframes außerhalb des sichtbaren Bereichs verzögert zu laden – der iframe-spezifische Fall (Anzeigen, Widgets, Karten).
• Browserseitiges Lazy Loading für CMS – Leitfaden für CMS-Plattformen.

Audioangebot von Google

• Google-Suche im Gespräch – Folge 98: „Lazy Loading verständlich erklärt“ (21. Aug. 2025) — John Mueller und Martin Splitt über Lazy Loading, Rendering, Indexierung und Core Web Vitals. Auch auf Googles Podcast-Seite indexiert.

Entwicklerreferenz (nicht SEO-spezifisch, aber maßgeblich für die API)

• MDN — Lazy loading (Performance-Leitfaden)
• MDN — HTMLImageElement: loading-Eigenschaft
• caniuse — Lazy loading per Attribut für Bilder und Iframes

Bing / Microsoft

• Bing veröffentlicht kein eigenes Dokument zu Lazy Loading. Die allgemeinen Webmaster-Richtlinien decken Crawling und JS-Rendering breit ab. Bingbot rendert mit einem Chromium-basierten Headless-Browser und scrollt oder klickt – wie Googlebot – nicht. Daher sollte derselbe native loading="lazy"-/IntersectionObserver-Ansatz, der Google zufriedenstellt, auch Bing zufriedenstellen. Der letzte Punkt ist eine Schlussfolgerung aus dem allgemeinen Rendering-Verhalten von Bingbot, keine belegte Bing-Aussage zu Lazy Loading – entsprechend behandeln.

Zitate aus der Quelle

Aussagen aus Googles offizieller Dokumentation. Jeder Link ist ein Deep Link, der direkt zum zitierten Abschnitt auf der Quellseite springt.

Google — Search Central, „Fix Lazy-Loaded Website Content”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (Übersetzung) „Das verzögerte Laden von nicht kritischem oder nicht sichtbarem Inhalt, auch allgemein als ‚Lazy Loading’ bekannt, ist eine gängige Best Practice für Leistung und Benutzererfahrung.” Zum Zitat springen
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (Übersetzung) „Wenn diese Technik jedoch nicht korrekt implementiert wird, kann sie Inhalte versehentlich vor Google verbergen. Dieses Dokument erklärt, wie Sie sicherstellen, dass Google Lazy-Loaded-Inhalte crawlen und indexieren kann.” Zum Zitat springen
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (Übersetzung) „Die genannten Methoden verlassen sich nicht auf Benutzeraktionen wie Scrollen oder Klicken, um Inhalte zu laden, was wichtig ist, da die Google-Suche nicht mit Ihrer Seite interagiert.” Zum Zitat springen
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (Übersetzung) „Fügen Sie Lazy Loading nicht zu Inhalten hinzu, die wahrscheinlich sofort sichtbar sind, wenn ein Benutzer eine Seite öffnet. Das könnte dazu führen, dass Inhalte länger zum Laden und Anzeigen im Browser benötigen, was für den Benutzer sehr deutlich spürbar wäre.” Zum Zitat springen
• “Give each chunk its own persistent, unique URL.” — zu unendlichem Scrollen / paginiertem Laden. (Übersetzung) „Geben Sie jedem Abschnitt seine eigene dauerhafte, eindeutige URL.” Zum Zitat springen

Lazy-Loading-Checkliste

Führen Sie dies aus, bevor Sie eine Lazy-Loading-Änderung veröffentlichen:

• Das Hero-/LCP-Bild wird NICHT lazy geladen – es wird eagerly geladen (ohne loading="lazy"), idealerweise mit fetchpriority="high".
• loading="lazy" wird auf Bilder und Iframes angewendet, die unterhalb des Falzes liegen.
• Lazy geladene Bilder haben explizite width/height (oder aspect-ratio), damit sie keinen Layout-Shift (CLS) verursachen, wenn sie geladen werden.
• Keine Inhalte sind hinter einem Scroll- oder Klick-Ereignis verborgen – Googlebot löst diese nicht aus. Verwenden Sie stattdessen natives Lazy Loading oder IntersectionObserver.
• Sie verwenden nicht den veralteten Wert loading="auto" – nur lazy/eager.
• Off-Screen-Iframes (Embeds, Anzeigen, Karten, Widgets) verwenden loading="lazy", um die Haupt-Thread-Arbeit beim Start zu reduzieren.
• Lazy geladene Iframes haben weiterhin ihr eigenes title, sandbox, allow/Permissions- Policy, referrerpolicy und explizite Abmessungen – loading="lazy" verzögert nur den Fetch-Zeitpunkt, nicht diese Attribute.
• In der Search Console URL-Prüfung → gerendertes HTML wurde verifiziert, dass Bild-/Video- URLs im src-Attribut erscheinen.
• Wenn eine JS-Lazy-Load-Bibliothek von Drittanbietern verwendet wird, wurde bestätigt, dass src im gerenderten HTML weiterhin befüllt ist.
• Bei unendlichem Scrollen hat jeder Abschnitt eine eindeutige, persistente, paginierte URL und die History API aktualisiert die angezeigte URL.
• Die „Offscreen-Bilder verzögern“-Flags von PageSpeed Insights sind behoben.

Lazy-Loading-Anti-Patterns (Mythen und Fehler)

Jeder dieser Punkte ist ein häufiger Glaube oder eine häufige Gewohnheit, warum er falsch ist und was stattdessen zu tun ist.

„Lazy Loading ist immer gut, also wenden Sie es auf jedes Bild an.“ Warum es falsch ist: Pauschales, seitenweites Lazy Loading erfasst auch Ihr Hero-/LCP-Bild, was Largest Contentful Paint verzögert – das Gegenteil des gewünschten Geschwindigkeitsgewinns. Stattdessen: Nur unterhalb des Falzes lazy laden; Bilder oberhalb des Falzes eagerly laden.

„Google indiziert lazy geladene Inhalte überhaupt nicht.“ Warum es falsch ist: Google crawlt und indiziert lazy geladene Inhalte problemlos, wenn dies mit nativem Lazy Loading, IntersectionObserver oder einer gut funktionierenden Bibliothek erfolgt. Das Risiko ist spezifisch für scroll-/klick-gesteuerte oder fehlerhafte Setups – laut Googles eigener Formulierung liegt das Problem darin, wenn es „not implemented correctly“ ist. (Übersetzung) „nicht korrekt implementiert“ Stattdessen: Verwenden Sie eine Viewport-Intersection-Methode und verifizieren Sie im gerenderten HTML.

„loading='auto' ist eine gute Standardeinstellung.“ Warum es falsch ist: auto ist in Chrome veraltet; dies zu empfehlen ist veralteter Rat. Stattdessen: Verwenden Sie lazy für Off-Screen-Ressourcen, eager (oder nichts) für den Rest.

„Lazy Loading und unendliches Scrollen sind dieselbe Lösung.“ Warum es falsch ist: Sie sind unterschiedlich. Unendliches Scrollen benötigt zusätzlich eindeutige, paginierte URLs und History-API-Updates, sonst werden die tieferen Inhalte möglicherweise nie zuverlässig gecrawlt. Stattdessen: Behandeln Sie paginiertes/unendliches Laden als eigene Architektur mit URLs pro Abschnitt.

„loading='lazy' funktioniert auf jedem Element.“ Warum es falsch ist: Es ist für <img> und <iframe> spezifiziert. Die Unterstützung für andere Elemente ist nicht in gleicher Weise Teil des Kern-Specs. Stattdessen: Verwenden Sie das Attribut auf Bildern und Iframes; behandeln Sie andere Medien mit einer geeigneten Technik (bei Video ein Posterbild, welches das Video beim Betreten des Viewports lädt).

„Lazy Loading schadet SEO.“ Warum es falsch ist: Lazy Loading selbst ist keine Strafe. Der rankingrelevante Effekt läuft über Core Web Vitals und ist gering; eine schlechte Implementierung schadet, nicht die Technik. Stattdessen: Implementieren Sie es korrekt, schließen Sie das LCP-Bild aus und verifizieren Sie, was gerendert wird.

Lazy-Loading-Spickzettel

Das loading-Attribut

Welche Elemente es unterstützen

• <img> – ja
• <iframe> – ja
• Andere Elemente (Video/Audio) – nicht in gleicher Weise Teil des Kern-Specs; verwenden Sie für Video ein Posterbild + Laden-beim-Sichtbarwerden-Muster.

Oberhalb vs. unterhalb des Falzes

• Oberhalb des Falzes / wahrscheinliches LCP → eager (niemals lazy). Fügen Sie fetchpriority="high" zum LCP-Bild hinzu.
• Unterhalb des Falzes → lazy.

Auswirkungen auf Core Web Vitals

• Das Verschieben von Bildern außerhalb des Sichtbereichs → hilft LCP (weniger Bytes konkurrieren zu Beginn).
• Das Verschieben von Iframes außerhalb des Sichtbereichs → hilft INP (weniger Haupt-Thread-Arbeit beim Start).
• Fehlende width/height bei lazy geladenen Bildern → kann CLS beeinträchtigen (Layout-Verschiebung beim Laden).

Regeln, die Googlebot beachtet

• Googlebot scrollt nicht und klickt nicht — keine scroll- oder klickabhängigen Inhalte.
• Sichere Methoden: natives loading="lazy", IntersectionObserver, gut funktionierende JS-Bibliothek.
• Überprüfen: URL Inspection → gerendertes HTML → Bild-URL im src-Attribut.
• Unendliches Scrollen ≠ Bild-Lazy-Loading — benötigt eindeutige paginierte URLs + History API.

Vorher / Nachher

Konkrete Korrekturen in der Formulierung eines Audits.

1. Das Hero-Bild wird lazy geladen (LCP verzögert)

Vorher:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Nachher:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Warum: Das Hero ist das LCP-Element. Es eager zu laden (und den Abruf zu priorisieren) lässt es schneller rendern. Es lazy zu laden bewirkt das Gegenteil.

2. Seitenweites pauschales Lazy Loading durch eine CMS-Standardeinstellung

Vorher: Jedes <img> in der Vorlage trägt loading="lazy", einschließlich des Header- Logos und des Featured-Bilds oben auf der Seite. Nachher: Die Vorlage lädt Bilder oberhalb des Falzes eager und wendet loading="lazy" nur auf Bilder an, die unterhalb des anfänglichen Viewports gerendert werden. Warum: Pauschales Lazy Loading erfasst die Bilder, die sofort sichtbar sind, und verzögert das, was der Benutzer (und LCP) zuerst sieht.

3. Einbettung außerhalb des Sichtbereichs wird beim Seitenaufruf geladen

Vorher:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Nachher:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Warum: Die Karte befindet sich unterhalb des Falzes. Sie zu verschieben entfernt ihre Startkosten und hilft INP, da Einbettungen Haupt-Thread-Arbeit verrichten, während die Seite lädt.

4. Benutzerdefiniertes JS-Lazy-Load lässt src für Googlebot leer

Vorher: Eine Bibliothek speichert die echte URL in data-src und tauscht sie bei einem Scroll- Ereignis in src ein — das Googlebot nie auslöst, sodass das gerenderte HTML ein leeres/Platzhalter- src zeigt. Nachher: Verwenden Sie natives loading="lazy" (echte URL von Anfang an in src) oder eine IntersectionObserver-basierte Bibliothek, und bestätigen Sie dann in URL Inspection, dass die URL im gerenderten src vorhanden ist. Warum: Wenn die URL im gerenderten HTML nicht in src steht, kann Google das Bild nicht aufnehmen.

Bilder finden, die lazy geladen werden sollten (oder nicht)

Ein DevTools-Console-Snippet, das Sie auf jeder Seite einfügen können, um das loading-Attribut zu prüfen. Es listet Bilder mit ihrem loading-Wert auf und ob sie sich derzeit im Viewport befinden — so können Sie ein Bild oberhalb des Falzes mit lazy erkennen oder eines unterhalb des Falzes, das es nicht ist.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Durchsuchen Sie Ihren Quellcode nach riskanten Lazy-Load-Mustern

Überprüfen Sie Ihre Vorlagen/Build-Ausgabe auf den veralteten auto-Wert und auf data-src-basiertes JS-Lazy-Loading (das src für Googlebot leer lassen kann).

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Denken Sie daran: data-src ist nicht automatisch ein Problem — es ist ein Hinweis, zu bestätigen, dass die echte URL im gerenderten src landet, was Sie in der URL Inspection der Search Console überprüfen.

Hero-Bild startet später nach Aktivierung von Lazy Loading

Symptom: LCP wird langsamer und die Hero-Anfrage beginnt spät im Wasserfall.

Wahrscheinliche Ursache: Eine globale CMS-Regel hat loading="lazy" zu einem Bild oberhalb des Falzes oder LCP-Bild hinzugefügt.

Behebung und Bestätigung: Entfernen Sie das Lazy-Attribut von diesem Bild, fügen Sie optional fetchpriority="high" hinzu und bestätigen Sie, dass seine Anfrage in einem passenden Trace früher startet.

Lazy-Bild erscheint, verschiebt aber die Seite

Symptom: Inhalte springen, wenn ein verzögertes Bild in den Viewport gelangt.

Wahrscheinliche Ursache: Das Bild hat keine expliziten Abmessungen oder kein reserviertes Seitenverhältnis.

Behebung und Bestätigung: Fügen Sie width- und height-Attribute hinzu oder reservieren Sie dasselbe Seitenverhältnis in CSS. Laden Sie neu, während Layout-Shift-Regionen aktiviert sind, und verifizieren Sie, dass das Bild umgebende Inhalte nicht mehr verschiebt.

Google sieht verzögerte Inhalte nicht

Symptom: Eine gerenderte Inspektion vermisst die Bild-URL oder Inhalte, die nach einem menschlichen Scrollen erscheinen.

Wahrscheinliche Ursache: Ein Scroll-/Klick-Handler läuft für Googlebot nie, oder eine Lazy-Load- Bibliothek lässt die echte URL in data-src statt im gerenderten src.

Behebung und Bestätigung: Verwenden Sie natives Lazy Loading oder eine IntersectionObserver-basierte Implementierung, und prüfen Sie dann das gerenderte HTML, um zu bestätigen, dass die endgültige URL und die Inhalte ohne Interaktion vorhanden sind.

Off-Screen-Embed lädt trotzdem sofort

Symptom: Ein unterhalb des Faltbereichs liegendes iframe erscheint trotz einer Lazy-Loading-Änderung im anfänglichen Waterfall.

Wahrscheinliche Ursache: Das Attribut fehlt im bereitgestellten iframe, ein Wrapper erstellt das iframe eifrig, oder das Embed liegt nahe genug am Viewport für die Ladeschwelle des Browsers.

Behebung und Bestätigung: Prüfen Sie das Live-DOM und den Request-Initiator, testen Sie auf einer langen Seite mit kaltem Cache und verifizieren Sie, dass die Anfrage bis zur Near-Viewport-Schwelle des Browsers verzögert wird.

Tools für Implementierung und Nachweis

• Chrome DevTools Elements- und Network-Panels: Bestätigen Sie das bereitgestellte loading- Attribut, identifizieren Sie, welches Skript ein iframe erstellt hat, und vergleichen Sie die Anfragestartzeiten vor und nach einer Änderung.
• Chrome DevTools Performance-Panel: Nehmen Sie einen Ladevorgang auf und verifizieren Sie, dass das Verzögern eines Embeds die Main-Thread-Arbeit beim Start reduziert, ohne das LCP-Bild zu verzögern.
• PageSpeed Insights: Verwenden Sie die Off-Screen-Image-Diagnose als Ausgangsliste und trennen Sie dann tatsächliche Below-the-Fold-Kandidaten vom Hero oder anderen sofortigen Inhalten.
• Search Console URL Inspection: Prüfen Sie gerendertes HTML und verifizieren Sie, dass verzögerte Bild-URLs in src landen und dass lazy-geladene Inhalte ohne Scrollen oder Klicken vorhanden sind.
• Der Browser-Viewport und das Filmstrip: Testen Sie mehr als eine Viewport-Größe. Ein Bild unterhalb des Faltbereichs auf dem Desktop kann auf einem kleineren oder anders geformten Gerät oberhalb des Faltbereichs liegen.

Below-the-Fold-Bildverzögerung

Durchzuführender Test: Nehmen Sie einen Network-Trace bei kaltem Laden vor und nach dem Hinzufügen von nativem Lazy Loading zu einem Bild weit unterhalb des anfänglichen Viewports auf.

Erwartetes Ergebnis: Die Bildanfrage fehlt im anfänglichen kritischen Waterfall und beginnt, wenn sich der Viewport ihr nähert.

Fehlerinterpretation: Das bereitgestellte Markup enthält das Attribut nicht, JavaScript erstellt oder holt das Bild eifrig, oder das Testbild liegt innerhalb der Near-Viewport-Schwelle des Browsers.

Überwachungsfenster: Prüfen Sie unmittelbar nach der Bereitstellung über repräsentative mobile und Desktop-Viewport-Größen.

Rollback-Auslöser: Rollback, wenn ein beim initialen Laden sichtbares Bild verzögert wird oder wenn das Bild regelmäßig nicht erscheint, bevor der Benutzer es erreicht.

LCP-Bild-Ausnahme

Durchzuführender Test: Vergleichen Sie passende Performance-Traces und Request-Waterfalls für das LCP-Bild der Seite nach dem Entfernen von pauschalem Lazy Loading.

Erwartetes Ergebnis: Das LCP-Bild lädt eifrig, seine Anfrage startet früher und LCP regressiert nicht.

Fehlerinterpretation: Eine andere Vorlage oder Optimierungsebene fügt das Attribut erneut hinzu, oder die Entdeckung wird weiterhin durch CSS, JavaScript oder Markup verzögert.

Überwachungsfenster: Prüfen Sie wiederholte Lab-Läufe sofort und beobachten Sie dann das Feld-LCP über das folgende Berichtsfenster.

Rollback-Auslöser: Rollback des umgebenden Rollouts, wenn die Änderung andere kritische Ressourcen genug verzögert, um eine wiederholbare LCP-Regression zu verursachen.

Sichtbarkeit gerenderter Inhalte

Durchzuführender Test: Verwenden Sie die URL-Inspektion, um das gerenderte HTML anzuzeigen, ohne mit der Seite zu interagieren, und suchen Sie nach der verzögerten Bild-URL und den zugehörigen Inhalten.

Erwartetes Ergebnis: Die endgültige URL erscheint in src, und wichtige Inhalte sind im gerenderten HTML vorhanden.

Fehlerinterpretation: Die Implementierung hängt von einem Scroll-/Klick-Ereignis ab oder das Lazy-Load-Skript ist während des Renderns fehlgeschlagen.

Überwachungszeitraum: Testen Sie jede betroffene Vorlage nach der Veröffentlichung und nach Änderungen an der Lazy-Load-Bibliothek oder der CMS-Bild-Pipeline.

Rollback-Auslöser: Führen Sie ein Rollback durch, wenn indexierbare Inhalte oder Bild-URLs aus der gerenderten Ausgabe verschwinden.

Testen Sie sich selbst: Lazy Loading

Fünf kurze Fragen zum Verzögern von Bildern und Iframes, ohne Core Web Vitals oder die Indexierung zu beeinträchtigen. Wählen Sie für jede eine Antwort und überprüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• JavaScript-SEO-Probleme und Best Practices – hier behandle ich den Wandel vom JS-gesteuerten zum browser-nativen Lazy Loading und warum verzögert geladene Inhalte (nicht nur Bilder) das Indexierungsrisiko darstellen.
• Google PageSpeed Insights für SEOs und Entwickler – verbindet den Audit „Offscreen-Bilder verzögern“ mit Lazy Loading sowie dem Rest des PSI-Berichts.
• Der Anfängerleitfaden für technisches SEO – wo Performance und Rendering in das Gesamtbild passen.

Aus der Branche

• Verzögert geladene Website-Inhalte reparieren (Google Search Central) – das maßgebliche Dokument zu Implementierung und Tests.
• Browser-Level-Bild-Lazy-Loading für das Web (web.dev) – das native Attribut und der LCP-Hinweis, direkt vom Google-Performance-Team.
• Es ist Zeit, Offscreen-Iframes verzögert zu laden! (web.dev) – der Iframe-Fall und sein Startup-/INP-Vorteil.
• Lazy Loading entmystifiziert – Search Off the Record, Folge 98 (Google) – Muellers und Splitts vollständige Folge über Lazy Loading, Rendering, Indexierung und Core Web Vitals.
• Lazy Loading erklärt: Beschleunigen Sie Ihre Website und UX schnell (Search Engine Land) – ein gründlicher Branchenleitfaden mit CMS-spezifischen Hinweisen.
• Lazy Loading (Performance-Leitfaden) (MDN) – die Entwicklerreferenz zur API.
• Ein Lazy-Loading-Grundkurs für Crawlbarkeit und Indexierungserfolg (Oncrawl) – der Crawl-/Index-Aspekt im Detail.

Änderungsprotokoll