Lazy Loading richtig einsetzen, ohne die Ladezeit zu verschlechtern

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

Lazy Loading klingt nach einer einfachen Verbesserung: Bilder erst laden, wenn sie gebraucht werden. In der Praxis ist es genau das, sofern man eine Ausnahme kennt und konsequent beachtet. Wer Lazy Loading pauschal auf alle Elemente anwendet, landet mit einem schlechteren LCP-Wert als vorher. Wer es gezielt einsetzt, spart Bandbreite, reduziert die initiale Ladezeit und verbessert die wahrgenommene Geschwindigkeit für den Großteil seiner Besucher.

Dieser Artikel grenzt sich bewusst von drei verwandten Themen ab: Den LCP-Wert grundsätzlich verbessern erklärt Largest Contentful Paint verbessern, Bildoptimierung generell steht in Bilder fürs Web optimieren, und moderne Bildformate behandelt WebP und AVIF. Hier geht es ausschliesslich ums Lazy Loading: was das Attribut tut, wo es hilft und wo es schadet.

Was Lazy Loading tatsächlich macht

Eine normale Webseite lädt beim ersten Aufruf alle Ressourcen, die im HTML-Quelltext stehen: alle Bilder, alle eingebetteten Videos, alle iFrames. Ein Besucher, der eine Seite mit 20 Bildern aufruft und nach dem ersten Bild wieder geht, hat trotzdem alle 20 Bilder übertragen bekommen. Bei einer langen Produktseite oder einem Ratgeber-Artikel mit vielen Illustrationen summiert sich das schnell auf mehrere Megabyte.

Lazy Loading ändert dieses Verhalten für Ressourcen ausserhalb des sofort sichtbaren Bereichs. Der Browser lädt sie erst, wenn sie beim Scrollen in die Nähe des sichtbaren Bereichs kommen. Wie nah, hängt vom Browser und der Verbindungsgeschwindigkeit ab: Chrome beginnt bei schnellen Verbindungen bereits ab etwa 1.250 Pixeln Abstand unterhalb des Viewports mit dem Vorladen, bei langsamen 3G-Verbindungen sogar ab 2.500 Pixeln, damit kein sichtbares Nachladen entsteht. Das ergibt für die meisten Seiten ein ruckelfreies Scrollerlebnis, ohne dass alle Ressourcen vorab geladen werden müssen.

Das Ergebnis: weniger Datentransfer beim ersten Seitenaufruf, schnellerer Start, und Ressourcen werden nur dann übertragen, wenn der Besucher wirklich so weit scrollt. Die tatsächliche Bandbreiten-Ersparnis hängt stark von der Seitenstruktur ab: Auf langen Seiten mit vielen Bildern unterhalb des Viewports kann sie erheblich sein.

Natives loading=“lazy“: Bilder und iFrames

Das loading-Attribut wurde 2019 in Chrome eingeführt und ist seitdem von allen modernen Browsern übernommen worden. Laut Can I Use deckt natives Lazy Loading heute über 95 Prozent der globalen Browser-Nutzer ab. Für ältere Browser, die das Attribut nicht kennen, ist das Verhalten graceful: sie ignorieren das Attribut einfach und laden das Bild sofort, wie es ohne das Attribut ohnehin geschähe.

Die drei möglichen Werte des Attributs sind:

• loading="lazy": Bild oder iFrame wird verzögert geladen, erst wenn es sich dem Viewport annähert.
• loading="eager": Bild wird sofort geladen, unabhängig von seiner Position auf der Seite. Das ist explizit dasselbe wie kein Attribut zu setzen.
• loading="auto": Der Browser entscheidet selbst. In der Praxis verhält sich das wie eager, der Wert ist also nicht sinnvoll nutzbar.

Die praktische Regel ist damit einfach: Bilder unterhalb des sofort sichtbaren Bereichs bekommen loading="lazy". Alles darüber nicht.

WordPress: Lazy Loading ist seit Version 5.5 Standard

Wer WordPress nutzt, muss in den meisten Fällen nichts selbst tun. WordPress fügt seit Version 5.5 (August 2020) automatisch loading="lazy" an alle Bilder an, die per the_post_thumbnail() oder wp_get_attachment_image() eingebunden werden. Das LCP-Bild nimmt WordPress dabei seit Version 6.3 automatisch aus und setzt dort stattdessen fetchpriority="high". Diese Automatik greift aber nur für Bilder, die WordPress direkt kennt. Bilder aus Seitenbuildern, iFrame-Einbettungen und direkt ins HTML eingetragene Elemente müssen manuell geprüft werden.

Die kritische Falle: LCP-Bild und above-the-fold

Der Largest Contentful Paint misst, wann das grösste sichtbare Element der Seite fertig geladen ist. Google wertet einen LCP unter 2,5 Sekunden als gut, über 4 Sekunden als schlecht. Das LCP-Element ist auf den meisten Websites das Headerbild, ein grosses Hero-Foto oder das Beitragsbild oben im Artikel. Genau dort ist der Schaden durch loading="lazy" am grössten.

Was passiert konkret? Der Browser erkennt loading="lazy" und hält das Laden des Bildes zurück, bis der Nutzer nahe genug an den sichtbaren Bereich scrollt. Bei einem Bild, das von Anfang an sichtbar sein soll, bedeutet das: der Browser wartet, obwohl er sofort laden müsste. Das Bild erscheint erst mit Verzögerung, der LCP-Wert steigt. Google dokumentiert, dass LCP-Bilder mit loading="lazy" im Median um bis zu 21 Prozent mehr Zeit für das Laden benötigen als solche ohne das Attribut (bei WordPress-Seiten rund 8 Prozent). In konkreten Projekten haben wir gesehen, wie ein LCP-Wert von knapp unter 3 Sekunden durch diesen einzelnen Fehler auf über 5 Sekunden kletterte.

Das Problem tritt in der Praxis häufiger auf, als man erwarten würde. Wer das Attribut global setzt („alle Bilder bekommen lazy“) oder ein Plugin verwendet, das nicht intelligent zwischen above-the-fold und below-the-fold unterscheidet, produziert diesen Fehler auf jeder Seite. WordPress macht es seit Version 6.3 besser, aber Seitenbuilder wie Divi generieren das erste Bild oft als direkte <img>-Tag-Einbettung ausserhalb des WordPress-Thumbnail-Systems, und dort greift die Automatik nicht.

Die Lösung ist eindeutig: Das LCP-Bild bekommt kein loading-Attribut oder explizit loading="eager". Alle Bilder, die ohne Scrollen sichtbar sind, ebenso. Alles darunter bekommt loading="lazy".

Wie man das LCP-Element findet

In Chrome: DevTools öffnen, Reiter Performance, einen Profil-Durchlauf starten und beenden. Im Timeline-Abschnitt „Timings“ ist der LCP-Zeitpunkt markiert. Ein Klick darauf zeigt das betroffene Element direkt. Schneller: PageSpeed Insights (pagespeed.web.dev) analysiert die Seite und weist das LCP-Element mit Screenshot und Elementbeschreibung aus. Mehr zur Interpretation der Core-Web-Vitals-Werte steht in Core Web Vitals einfach erklärt.

fetchpriority: die ergänzende Stellschraube

Neben dem Lazy-Loading-Attribut gibt es eine zweite Stellschraube, die direkt auf die Ladereihenfolge wirkt: das Attribut fetchpriority. Es teilt dem Browser mit, wie wichtig eine Ressource im Verhältnis zu anderen ist. Die drei Werte sind high, low und auto (Standardwert).

Für das LCP-Bild ist fetchpriority="high" die stärkste verfügbare Massnahme. Der Browser schiebt das Bild in der internen Warteschlange nach vorne und beginnt damit zu laden, bevor andere Ressourcen abgearbeitet sind. Chrome unterstützt Priority Hints seit Version 102 (Mai 2022), Firefox ab Version 132 und Safari ab Version 17.2. Die Kombination aus fehlendem loading="lazy" und gesetztem fetchpriority="high" ist die wirkungsvollste Methode, um den LCP-Wert zuverlässig zu verbessern.

Umgekehrt ist fetchpriority="low" sinnvoll für dekoratives Bildmaterial im Footer, in langen Galerien oder für Bilder, die erfahrungsgemäss selten angesehen werden. Kombiniert mit loading="lazy" signalisiert das dem Browser: diese Ressource hat keine Eile, und sie soll auch erst spät geladen werden.

Eine vollständige LCP-Bild-Einbettung sieht so aus:

<img
  src="hero-foto.webp"
  alt="Beschreibender Alternativtext"
  width="1200"
  height="630"
  fetchpriority="high"
  loading="eager"
>

Und ein Bild tief auf der Seite:

<img
  src="galerie-bild.webp"
  alt="Bildtitel aus der Galerie"
  width="800"
  height="600"
  loading="lazy"
  fetchpriority="low"
>

iFrames und Videos richtig lazy loaden

Ein eingebettetes YouTube-Video lädt beim Seitenaufruf mehrere hundert Kilobyte JavaScript und CSS von YouTube-Servern, zusätzlich zum eigentlichen Video-Stream. Eine eingebettete Google-Karte zieht ähnlich viel nach. Wer auf einer Kontaktseite eine Karte einbettet, verdoppelt damit in manchen Fällen die initiale Datenlast der Seite.

Das loading="lazy"-Attribut am <iframe> verhält sich genau wie an einem <img>-Element: der Browser lädt den iFrame erst, wenn er sich dem Viewport annähert. Das ist bei einer Karte am Seitenende eine echte Entlastung des ersten Seitenaufrufes.

<iframe
  src="https://www.google.com/maps/embed?pb=..."
  width="600"
  height="450"
  loading="lazy"
  allowfullscreen=""
  referrerpolicy="no-referrer-when-downgrade"
></iframe>

Das Facade-Pattern für YouTube

Für YouTube-Videos ist ein Facade-Pattern die wirkungsvollere Alternative. Dabei wird anstelle des vollständigen iFrames zunächst nur ein statisches Vorschaubild mit Play-Button gezeigt. Das eigentliche YouTube-iFrame wird erst per JavaScript eingebunden, wenn der Nutzer auf den Play-Button klickt. Das spart die gesamte initiale YouTube-Ladestrecke von mehreren hundert Kilobyte vollständig ein, nicht nur bis zum Scrollen.

Eine fertige, schlanke Komponente dafür ist lite-youtube-embed von Paul Irish. Sie braucht minimales CSS und JavaScript, hat kein Framework als Abhängigkeit und verhält sich semantisch wie ein normales YouTube-iFrame. Der Einbau ist eine Zeile HTML:

<lite-youtube videoid="VIDEO_ID" playlabel="Video abspielen"></lite-youtube>

Selbst gehostete Videos

Bei selbst gehosteten Videos im <video>-Tag gibt es kein natives loading-Attribut. Hier hilft das Attribut preload="none", das dem Browser sagt, er soll weder Metadaten noch Videodaten vorab laden. Das Poster-Attribut zeigt dem Besucher derweil ein Standbild:

<video
  src="demo.mp4"
  poster="demo-vorschau.webp"
  preload="none"
  controls
></video>

Für vollständiges Lazy Loading eines <video>-Elements (also erst laden, wenn in der Nähe des Viewports) braucht man eine kurze JavaScript-Lösung mit dem IntersectionObserver. Das ist aber nur nötig, wenn das Video weit unten auf der Seite liegt und die Metadaten-Last vermieden werden soll. Die meisten Fälle löst preload="none" ausreichend.

JavaScript-Bibliotheken: wann noch sinnvoll?

Vor 2019, als natives Lazy Loading noch nicht verfügbar war, haben JavaScript-Bibliotheken wie lazysizes oder lozad.js das Problem gelöst. Sie funktionieren typischerweise so: das src-Attribut bleibt leer oder wird auf einen Platzhalter gesetzt, der echte Bildpfad steht in einem data-src-Attribut, und ein Script setzt src erst, wenn das Element in den Viewport scrollt.

Heute ist dieser Ansatz in den meisten Fällen überflüssig. Natives loading="lazy" deckt mehr als 95 Prozent der aktiven Browser ab und braucht kein JavaScript. Drei Situationen sprechen aber noch für eine JavaScript-Lösung:

• Sehr spezifische Anforderungen an den Vorladeabstand, die sich mit dem Standardverhalten des Browsers nicht erreichen lassen.
• Komplexe Lazy-Loading-Szenarien mit dynamisch gerenderten Inhalten, bei denen Bilder per JavaScript nachgeladen werden und loading="lazy" nicht greift, weil das Element beim ersten Rendern noch nicht im DOM ist.
• Ältere Browser-Unterstützungsanforderungen (unter einem Prozent Marktanteil).

Wer noch eine ältere JavaScript-Bibliothek im Einsatz hat, sollte ausserdem deren rootMargin-Konfiguration prüfen. Manche ältere Versionen setzen rootMargin: 0px als Standard, was bedeutet: das Bild wird erst geladen, wenn es tatsächlich den Viewport berührt. Das Ergebnis ist sichtbares Nachladen beim Scrollen. Der native Browser-Vorladeabstand von 1.250 Pixeln ist hier erheblich nutzfreundlicher. Ein Upgrade auf rootMargin: '1200px' oder besser noch die Umstellung auf natives Lazy Loading löst das Problem.

Lazy Loading und Suchmaschinen

Der Googlebot verarbeitet Seiten in zwei Schritten: erst den statischen HTML-Quelltext, dann nach JavaScript-Ausführung das gerenderte Ergebnis. Bei nativem loading="lazy" steht der Bildpfad im src-Attribut bereits im ersten Schritt im HTML. Der Bot sieht das Bild also sofort und kann es indexieren, auch wenn er es nicht physisch lädt.

Anders verhält es sich bei JavaScript-Implementierungen mit data-src: Im rohen HTML steht kein echter Bildpfad, nur ein Platzhalter. Ob der zweite, gerenderte Durchlauf des Bots folgt und wann, ist nicht garantiert. Für Produktbilder im Shop oder Illustrationen, die in der Bildsuche erscheinen sollen, ist das ein echtes Risiko. Google selbst empfiehlt daher die Umstellung auf natives Lazy Loading, wo immer möglich.

Übersicht: Was lazy loaden, was nicht

Praxisbeispiel

In einem Projekt für einen regionalen Handwerksbetrieb haben wir eine WordPress-Seite mit Divi übernommen, deren PageSpeed-Score bei 42 von 100 auf Mobilgeräten lag. Einer der Hauptbefunde in Lighthouse: das Beitragsbild auf der Startseite hatte loading="lazy" gesetzt, weil ein Performance-Plugin das Attribut pauschal auf alle Bilder des gesamten Seitenlayouts angewendet hatte. Das Bild war das LCP-Element, es lud mit mehr als 4 Sekunden Verzögerung.

Der Fix war minimal: das Plugin so konfigurieren, dass das erste Bild von Lazy Loading ausgenommen wird, und dort zusätzlich fetchpriority="high" setzen. Gleichzeitig haben wir das eingebettete Google-Maps-iFrame auf der Kontaktseite mit loading="lazy" versehen, was dort 340 KB beim ersten Aufruf einsparte. Nach der Korrektur war der LCP-Wert unter 2 Sekunden, der PageSpeed-Score stieg auf 76.

Das zeigt das typische Muster: Performance-Plugins mit aggressiven Einstellungen verursachen denselben Fehler, den sie beheben sollen. Wer Lazy Loading über ein Plugin konfiguriert, sollte prüfen, ob das Plugin eine „Exclude first image“ oder eine „LCP exclude“ Option hat, und diese aktivieren.

Sofort-Checkliste

• LCP-Element in Chrome DevTools oder PageSpeed Insights identifiziert?
• LCP-Bild hat kein loading="lazy", stattdessen fetchpriority="high"?
• Alle Bilder, die ohne Scrollen sichtbar sind, haben kein loading="lazy"?
• Bilder unterhalb des Viewports haben loading="lazy"?
• Performance-Plugin geprüft: gibt es eine „LCP exclude“ oder „first image skip“ Einstellung?
• Google-Maps-iFrame und andere schwere iFrames haben loading="lazy"?
• YouTube-Einbettungen auf Facade-Pattern oder natives loading="lazy" umgestellt?
• Selbst gehostete Videos haben preload="none" plus poster?
• JavaScript-Bibliotheken mit data-src identifiziert und Migrationsbedarf geklärt?
• WordPress-Version mindestens 6.3 (automatische LCP-Erkennung aktiv)?
• PageSpeed Insights oder Lighthouse nach den Änderungen erneut ausgeführt?

Häufige Fragen

Kann ich loading=“lazy“ einfach auf alle Bilder meiner Seite setzen?

Nein. Das LCP-Bild und alle Bilder, die beim ersten Seitenaufruf ohne Scrollen sichtbar sind, dürfen kein loading="lazy" bekommen. Pauschal angewendet verschlechtert das Attribut den LCP-Wert messbar. Nur Elemente ausserhalb des initialen Viewports profitieren davon.

Wie finde ich heraus, welches Bild mein LCP-Element ist?

In Chrome DevTools: Reiter Performance, Profil starten und stoppen, im Bereich „Timings“ auf das LCP-Ereignis klicken. Alternativ zeigt PageSpeed Insights das LCP-Element mit Screenshot an. Bei WordPress ist es häufig das Beitragsbild oder das erste grosse Bild in einem Seitenbuilder-Hero-Bereich.

Was bringt fetchpriority=“high“ am LCP-Bild?

Das Attribut weist den Browser an, dieses Bild in der Ladereihenfolge bevorzugt zu behandeln, noch bevor andere Ressourcen abgearbeitet sind. Kombiniert mit fehlendem loading="lazy" ist das die wirkungsvollste Massnahme für den LCP-Wert. Chrome unterstützt es seit Version 102, Safari seit 17.2, Firefox seit Version 132.

Verbessert Lazy Loading den LCP-Wert?

Lazy Loading allein verbessert den LCP-Wert nicht und kann ihn, falsch eingesetzt, verschlechtern. Der LCP-Wert verbessert sich durch fetchpriority="high" am LCP-Element, optimierte Bildformate und das bewusste Weglassen von loading="lazy" am LCP-Bild. Lazy Loading verbessert andere Ladezeit-Kennzahlen und spart Bandbreite, beeinflusst aber den LCP nur indirekt.

Ist natives Lazy Loading für Google-Indexierung unbedenklich?

Ja. Bei nativem loading="lazy" steht der Bildpfad im src-Attribut bereits im statischen HTML-Quelltext. Der Googlebot sieht das Bild beim ersten Crawl. Problematisch sind nur JavaScript-Lösungen, die den Bildpfad erst zur Laufzeit in das src-Attribut schreiben, weil der zweite, gerenderte Crawl-Durchlauf nicht garantiert ist.

Soll ich ein Performance-Plugin für Lazy Loading verwenden?

Nur wenn das Plugin LCP-Bild-Erkennung hat und das erste Bild korrekt ausnimmt. Plugins wie WP Rocket oder Flying Images beherrschen das. Plugins, die pauschal alle Bilder mit loading="lazy" versehen, ohne das LCP-Element auszunehmen, verursachen genau den Fehler, den dieser Artikel beschreibt. Die Einstellung „Exclude first image“ oder „LCP exclude“ muss aktiviert sein.

Funktioniert loading=“lazy“ auch an iFrames?

Ja, an allen <iframe>-Elementen. Das Attribut verhält sich identisch wie bei <img>: der Browser lädt den iFrame erst, wenn er sich dem Viewport annähert. Für YouTube-Videos gibt es mit dem Facade-Pattern eine noch wirkungsvollere Alternative, weil dort die gesamte YouTube-JavaScript-Last ausgespart wird, nicht nur das Laden bis zum Scroll-Ereignis.