Setzen Sie loading="lazy" ausschließlich für Bilder unterhalb des ersten Viewports ein. Das größte Element im sichtbaren Bereich, also Ihr LCP-Kandidat, gehört mit loading="eager" und fetchpriority="high" geladen, niemals lazy. Reservieren Sie für jedes Bild width und height oder eine CSS aspect-ratio, sonst verschiebt sich beim Nachladen das Layout und Ihr CLS-Wert leidet.

Kurz gesagt:

  • Bilder im sichtbaren Bereich sollten niemals mit loading="lazy" geladen werden, um das Largest Contentful Paint nicht zu beeinträchtigen.
  • Für Bilder unterhalb des Viewports ist loading="lazy" sinnvoll, bei LCP-Bildern gilt jedoch loading="eager" und fetchpriority="hoch".
  • Das Fehlen fester Dimensionen bei Bildern führt zu Layoutverschiebungen und verschlechtertem CLS-Wert, was beim Nachladen unbedingt vermieden werden sollte.
  • Konflikte entstehen häufig, wenn loading="lazy" und data-src gleichzeitig verwendet werden, was die Ladefunktion blockiert und den Ladevorgang verzögert.
  • Für Hintergrundbilder und komplexe Ladeanimationen ist der Einsatz eines IntersectionObserver anstelle des nativen Lazy-Loading sinnvoll.
Neomarketing
Datenbasierte Marketingentscheidungen treffen
Neomarketing verbindet Google Ads, GA4, Merchant Center und Data Layer Integration für fundierte Einblicke in Ihre digitalen Maßnahmen.

Inhaltsverzeichnis

Wie funktioniert Lazy Loading für Bilder im Browser?

Das Attribut loading="lazy" markiert ein Bild oder ein Iframe als nicht dringend. Der Browser verzögert die Netzwerkanfrage, bis das Element sich dem Viewport nähert, und schont so die Bandbreite auf langen Seiten, ganz ohne JavaScript. Anders als bei einem selbstgebauten Skript entscheidet hier die Rendering-Engine selbst, wann sie nachlädt, gesteuert über interne Heuristiken statt über einen festen Pixelwert.

Wichtig ist der Unterschied zwischen dem Preload-Scanner und einem JavaScript-Observer. Der Preload-Scanner liest das HTML-Dokument, noch bevor der DOM vollständig aufgebaut ist, und erkennt die Bild-URL direkt im Markup. Ein IntersectionObserver dagegen wartet, bis das Skript ausgeführt wird, was bei einem data-src-Muster spürbar Zeit kostet, weil die eigentliche URL zunächst gar nicht im Quellcode steht. Ergänzend signalisieren fetchpriority und decoding="async" dem Browser, wie dringend und wie synchron ein Bild verarbeitet werden soll. Ältere Browser ohne Unterstützung laden das Bild einfach sofort, ein Sicherheitsnetz ganz ohne Zusatzcode.

Vergleich zweier Bildladeprozesse im Browser

Wann sollten Sie lazy laden, wann nicht?

Die Faustregel ist simpel, die Umsetzung in der Praxis aber oft schlampig. Viele Projekte setzen loading="lazy" pauschal auf jedes <img>-Tag der Seite, inklusive des Hero-Bildes ganz oben. Genau das drückt den LCP-Wert nach oben, wie Feldtests zu Lazy-Loading-Regressionen zeigen.

Prüfen Sie zuerst, welches Element überhaupt Ihr LCP-Kandidat ist. Öffnen Sie die Chrome DevTools, Reiter „Performance“, und suchen Sie die LCP-Markierung im Trace. Alternativ liefert Lighthouse direkt den Namen des Elements im Bericht „Largest Contentful Paint element“.

Danach gilt eine klare Checkliste für den Rollout:

  • LCP-Bild: loading="eager", fetchpriority="high", kein decoding="async"
  • Bilder unterhalb des ersten Viewports: loading="lazy", decoding="async"
  • Jedes Bild bekommt width und height als Attribute oder eine CSS aspect-ratio
  • Kein globales Lazy Loading per Theme- oder Plugin-Default ohne Ausnahmeliste
  • Kein data-src-Polyfill parallel zum nativen Attribut auf demselben Element

Der häufigste Fehler ist die Kombination aus beidem: ein Bild trägt gleichzeitig data-src und loading="lazy", weil ein altes Skript nie entfernt wurde. Der Browser lädt dann nichts, bis das Skript eingreift, und Sie verlieren den gesamten Vorteil des nativen Attributs. Ein zweiter Klassiker: Bilder ohne feste Maße, die beim Nachladen den Text nach unten schieben, ein sichtbarer Sprung, der Nutzer irritiert und den CLS-Wert verschlechtert.

Profi-Tipp: Suchen Sie im Quellcode gezielt nach data-src in Kombination mit loading. Findet sich beides auf demselben Tag, ist das fast immer ein Überbleibsel einer alten JavaScript-Lösung, die den nativen Vorteil sabotiert.

Native Attribut oder IntersectionObserver: Was passt wann?

Für die meisten Websites reicht das native Attribut völlig aus. Es kostet keine zusätzliche Skriptlast, funktioniert ohne Framework und profitiert vom Preload-Scanner, der die Bild-URL schon vor der vollständigen DOM-Konstruktion kennt. Ein IntersectionObserver lohnt sich erst, wenn Sie mehr Kontrolle brauchen, als das Attribut bietet.

Drei Situationen sprechen für den Observer-Ansatz:

  1. CSS-Hintergrundbilder, weil loading="lazy" ausschließlich für <img> und <iframe> gilt und Hintergrundbilder in Stylesheets gar nicht erreicht.
  2. Aufwendige Ladeanimationen, etwa ein Blur-up-Effekt, bei dem ein unscharfes Platzhalterbild erst durch die volle Auflösung ersetzt wird, sobald das Element sichtbar wird.
  3. Feingranulare Steuerung der Ladedistanz, wenn Sie mit rootMargin bestimmen wollen, wie viele Pixel vor dem Viewport das Nachladen anspringt, etwa rootMargin: "200px" für ruckelfreies Scrollen auf langsamen Verbindungen.

Ein einfaches Beispiel für den Observer-Aufbau:

const bilder = document.querySelectorAll("img[data-src]");
const observer = new IntersectionObserver((einträge) => {
  einträge.forEach((eintrag) => {
    if (eintrag.isIntersecting) {
      const bild = eintrag.target;
      bild.src = bild.dataset.src;
      observer.unobserve(bild);
    }
  });
}, { rootMargin: "200px" });
bilder.forEach((bild) => observer.observe(bild));

Der Fehler, den viele hier machen: Sie bauen diesen Observer und lassen gleichzeitig loading="lazy" auf denselben Bildern stehen. Beides konkurriert um dieselbe Aufgabe und macht das Verhalten unvorhersehbar. Entscheiden Sie sich pro Bildtyp für genau einen Mechanismus, wie es MDN in der Beschreibung des Attributs empfiehlt.

Iframes, Hintergrundbilder und responsive Bildquellen

Iframes profitieren besonders stark von loading="lazy", weil damit nicht nur ein Bild, sondern ein ganzes Subressourcen-Paket verzögert wird. Bei eingebetteten YouTube-Videos oder Google-Maps-Karten bedeutet das oft mehrere hundert Kilobyte an Skripten, Stylesheets und Schriftdateien, die erst beim Erreichen des Viewports nachgeladen werden, ein Effekt mit messbarem LCP-Vorteil. Ein bewährter Workaround für besonders schwere Embeds ist das Facade-Pattern: ein statisches Platzhalterbild mit nativem Lazy Loading, das erst per Klick den eigentlichen Iframe nachlädt, was initiale Bytes spart und die Seite trotzdem indexierbar hält.

Darstellung des verzögerten Nachladens eines Iframes

Bei CSS-Hintergrundbildern greift das native Attribut nicht, weil es sich technisch nur auf <img> und <iframe> bezieht. Wollen Sie ein Hintergrundbild dennoch verzögern, bleiben zwei Wege: entweder ein IntersectionObserver, der die CSS-Eigenschaft background-image erst beim Sichtbarwerden setzt, oder die Umwandlung in ein reguläres <img>-Element mit object-fit: cover, das dann ganz normal loading="lazy" nutzen kann.

Responsive Bilder mit srcset und sizes lassen sich problemlos mit loading="lazy" kombinieren. Der Browser wählt weiterhin selbst die passende Bildquelle je nach Viewport-Breite und Pixeldichte aus, das Lazy-Loading-Verhalten ändert daran nichts. Wichtig ist nur, dass Sie bei jeder Quelle im srcset dieselben Seitenverhältnisse einhalten, sonst springt das Layout je nach ausgewählter Auflösung unterschiedlich stark.

WordPress und andere CMS: Lazy Loading gezielt steuern

WordPress lädt Bilder seit Version 5.5 standardmäßig nativ lazy. Das Problem entsteht dort meist bei Hero-Bildern im Theme-Header oder bei Bildern, die über Page-Builder-Plugins eingebunden werden und das native Attribut automatisch mitbekommen, obwohl sie über dem Viewport liegen.

Für ein einzelnes Bild lässt sich das Attribut gezielt entfernen:

add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
    if ($attachment->ID === 123) {
        unset($attr['loading']);
    }
    return $attr;
}, 10, 2);

Ein zusätzliches Plugin oder ein Polyfill lohnt sich nur noch selten, seit die Browserunterstützung für loading="lazy" breit ist. Sinnvoll bleibt ein Polyfill höchstens bei Projekten mit sehr altem Browser-Traffic, wo laut Can I Use noch Lücken in der Abdeckung bestehen.

Checkliste vor dem Rollout und Monitoring danach

Vor jedem Deploy steht die gleiche Reihenfolge: LCP-Element identifizieren, Dimensionen aller Bilder prüfen, sicherstellen, dass kein LCP-Bild lazy geladen wird.

  • Lab-Test: Lighthouse im mobilen Modus mit gedrosseltem 4G-Profil, Blick auf LCP und CLS im Bericht
  • Lab-Test: DevTools Performance-Trace mit sichtbarer LCP-Markierung zur genauen Zeitzuordnung
  • Field-Test: CrUX- oder RUM-Daten über mindestens 28 Tage beobachten, bevor Sie ein Ergebnis bewerten
  • Rollback-Trigger: spürbare LCP-Verschlechterung im Lab- oder Field-Test nach dem Rollout

Diese zweistufige Prüfung, Lighthouse für die Labor-Momentaufnahme, CrUX/RUM für echte Nutzerdaten, verhindert, dass ein isolierter Test-Erfolg über die tatsächliche Erfahrung Ihrer Besucher hinwegtäuscht.

Wann sich ein Performance-Audit für Ihre Bilder lohnt

Lazy Loading ist bei uns nie ein isoliertes Thema, sondern Teil größerer Tracking- und CRO-Projekte, weil Ladezeit und Conversion eng zusammenhängen. Ein Audit lohnt sich vor allem bei komplexen E-Commerce-Galerien mit vielen Produktbildern, bei Seiten mit zahlreichen Third-Party-Embeds oder wenn derselbe LCP-Fehler nach jedem Redesign wieder auftaucht. Aus der praktischen Arbeit mit Google-Tool-Integrationen wissen wir, wie oft ein einzelnes falsch konfiguriertes Bild ganze Kampagnenbudgets über schlechte Ladezeiten verschlingt.

— Patrick

Performance-Audit statt Rätselraten bei Ladezeiten

Diese Alternative zur klassischen Agenturbetreuung ermöglicht konkrete, umsetzbare Korrekturen an Ihren Bildern, Ihrem Tracking und Ihrer Google-Ads-Struktur aus einer Hand.

Neomarketing

Ein Performance-Audit deckt typischerweise genau die Stellen auf, die in diesem Artikel beschrieben sind: falsch eager oder lazy geladene Bilder, fehlende Dimensionen, kaputte data-src-Reste aus alten Themes. Für Online-Shops mit vielen Produktbildern und wiederkehrenden LCP-Problemen verbinden wir diese technische Prüfung direkt mit Conversion-Optimierung, weil eine schnellere Seite allein selten reicht, wenn die Kampagnensteuerung dahinter nicht stimmt. Wer zusätzlich zur reinen Bildoptimierung noch tiefer in Seitenladezeit und SEO einsteigen will, findet bei unserem Partner Babylovegrowth eine gute Ergänzung. Lassen Sie Ihre Google-Ads- und Tracking-Struktur einmal von außen prüfen, bevor der nächste Kampagnenstart wieder an derselben Stelle scheitert.

Quellen

Für die technische Validierung dieses Artikels lohnt sich der direkte Blick in die Primärquellen: web.dev zu Browser-Lazy-Loading, die MDN-Dokumentation zum loading-Attribut, die Browserabdeckung bei Can I Use und die Praxisanalyse von DebugBear. Ergänzend hilft die Lighthouse- und CrUX-Dokumentation für das laufende Monitoring nach dem Rollout.

FAQ

Was bedeutet Lazy Loading bei Bildern?

Lazy Loading verzögert das Herunterladen eines Bildes, bis es sich dem sichtbaren Bereich der Seite nähert, statt es sofort beim Seitenaufruf zu laden. Das spart Bandbreite und beschleunigt den ersten Seitenaufbau, sofern das LCP-Bild davon ausgenommen bleibt.

Verschlechtert Lazy Loading die SEO-Bewertung?

Suchmaschinen können lazy geladene Bilder normalerweise problemlos erfassen, solange das native Attribut oder ein korrekt implementierter Observer verwendet wird und keine reinen data-src-Lösungen ohne Fallback vorliegen. Schädlich für die Bewertung wird es nur indirekt, wenn Lazy Loading den LCP-Wert verschlechtert und damit die Core-Web-Vitals-Werte drückt.

Funktioniert Lazy Loading bei allen Bildschirmauflösungen gleich?

Ja, loading="lazy" arbeitet unabhängig von srcset und sizes zusammen, der Browser wählt weiterhin die passende Bildquelle je nach Viewport und Pixeldichte, das Nachladeverhalten bleibt davon unberührt.

Ist Lazy Loading mit Bildschirmlesern kompatibel?

Ja, solange Alternativtexte korrekt gesetzt sind, liest ein Screenreader den Alternativtext unabhängig davon vor, ob das Bild bereits geladen wurde. Fehlen jedoch feste Dimensionen, kann sich der Fokus bei Tastatursteuerung durch nachträgliche Layoutverschiebungen unerwartet verschieben.

Sollte ich Lazy Loading für Iframes genauso behandeln wie für Bilder?

Größtenteils ja, mit loading="lazy" lassen sich Iframes ebenso markieren wie Bilder, und der Effekt fällt hier oft noch stärker aus, weil ganze Subressourcen-Pakete verzögert werden. Für besonders schwere Embeds wie eingebettete Videos ist zusätzlich das Facade-Pattern mit Klick-zum-Laden eine bewährte Ergänzung.

Empfehlungen

KI-Hinweis: Dieser Beitrag wurde mit Unterstützung von künstlicher Intelligenz erstellt. Als KI-generiert gekennzeichnete Bilder wurden mit KI erzeugt. Mehr zum Einsatz von KI