'Defer Offscreen Images' beheben: Lazy-Loading-Guide für Core Web Vitals

Offscreen-Bilder aufschieben und die Core Web Vitals verbessern

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-27

'Defer offscreen images' in Kürze

Beim Laden einer Seite mit Offscreen-Bildern muss ein Browser oft mehr Bilder herunterladen als unbedingt nötig. Dies führt zu einer Verzögerung beim Rendern der Seite.

Beheben Sie dies, indem Sie loading="lazy" zu allen Below-the-Fold-Bildern hinzufügen. Natives Lazy Loading wird von allen gängigen Browsern mit einer weltweiten Abdeckung von 95 % unterstützt.

Zuletzt überprüft von Arjen Karel im Februar 2026

Website Speed Audit

Was bedeutet 'defer offscreen images'?

Lighthouse-Warnung zu Defer offscreen images

Die Warnung defer offscreen images war ein Lighthouse-Audit, das Seiten mit Bildern markierte, die per Lazy Loading geladen werden könnten. Lighthouse markierte Bilder, die alle folgenden Kriterien erfüllten:

  • Das Bild endet unterhalb des Dreifachen der Viewport-Höhe.
    Wenn ein Bild nicht per Lazy Loading geladen wird und unterhalb der dreifachen Höhe des sichtbaren Teils der Seite endet sowie unterhalb des sichtbaren Teils der Seite beginnt.
  • Das Bild ist größer als 0,02 MB oder lädt länger als 50 ms.
    Bilder, die entweder klein oder eingebettet (inlined) sind, werden ignoriert. Lazy-Loading-Skripte verwenden oft kleine Platzhalterbilder, die unter diesen Schwellenwert fallen.
  • Für das Bild ist kein Loading-Attribut definiert.
    Lighthouse ignoriert Bilder, die entweder das Attribut loading="lazy" oder loading="eager" haben.

Dieses Audit wurde in Lighthouse 13 entfernt

Mit Lighthouse 13 (Oktober 2025) wurde dieses Audit vollständig entfernt. Das Chrome-Team hat festgestellt, dass moderne Browser Offscreen-Bilder bereits depriorisieren, weshalb das Audit mehr Rauschen als nützliches Feedback erzeugte.

Aber hier ist der Punkt: Die Optimierung an sich ist nach wie vor wichtig. Das Lazy Loading von Offscreen-Bildern reduziert die Bandbreite, gibt Netzwerkverbindungen für kritische Ressourcen frei und verbessert Ihren Largest Contentful Paint (LCP). Dass Lighthouse dies nicht mehr bemängelt, bedeutet, dass Sie es selbst überprüfen müssen. Nutzen Sie Real User Monitoring oder prüfen Sie Ihre Seiten manuell auf Bilder, die ohne loading="lazy" geladen werden.

Eine kurze Erinnerung: Was ist Lazy Loading?

Lazy Loading bedeutet, dass Bilder, die sich nicht im sichtbaren Teil der Seite befinden, zu einem späteren Zeitpunkt geladen werden, meist kurz bevor sie in den sichtbaren Bereich gescrollt werden. Der Browser ruft das Bild erst ab, wenn der Nutzer sich ihm nähert. Dies spart Bandbreite und ermöglicht es dem Browser, sich auf die Ressourcen zu konzentrieren, die für das anfängliche Rendern tatsächlich wichtig sind.

Was verursacht Eager-Loaded Offscreen-Bilder?

Bilder werden standardmäßig nicht aufgeschoben. Offscreen-Bilder, die nicht aufgeschoben werden, landen auf der Seite, weil das Loading-Attribut fehlt oder das Bild nicht von einer Lazy-Loading-Bibliothek verarbeitet wird. Häufige Ursachen:

  • Schlecht programmierte Plugins in Ihrem CMS.
  • Plugins, die natives Lazy Loading deaktivieren.
  • Hintergrundbilder (diese erfordern einen anderen Ansatz als loading="lazy").
  • Page Builder, die schlechtes HTML generieren (zum Beispiel: Elementor oder WP Bakery).
  • Text, der kopiert und in einen WYSIWYG-Editor (wie TinyMCE) eingefügt wird.
  • Schlechte Template-Programmierung.

Wie wirken sich Offscreen-Bilder auf Ihre Core Web Vitals aus?

Offscreen-Bilder wirken sich nicht direkt auf Lighthouse-Metriken aus. Sie machen das Rendern einer Webseite jedoch unnötig kompliziert. Ihr Browser muss mehr Ressourcen herunterladen, bevor die Seite auf dem Bildschirm angezeigt werden kann. Es gibt 3 Probleme mit sofort geladenen (eager loaded) Offscreen-Bildern:

  • Mehr Downloads vor dem Rendern. Ihr Browser muss Bilder herunterladen, die der Nutzer noch gar nicht sehen kann.
  • Kritische Ressourcen werden depriorisiert. Die Bilder konkurrieren um Bandbreite mit Ressourcen, die tatsächlich für das Rendern benötigt werden, wie Ihr CSS und Ihr LCP-Bild.
  • Höhere Speichernutzung. Das Dekodieren von Bildern, zu denen der Nutzer noch nicht gescrollt hat, verschwendet Arbeitsspeicher, insbesondere auf leistungsschwächeren mobilen Geräten.

Laut dem Kapitel über Seitengewicht im Web Almanac 2025 lädt die mediane mobile Seite 15 Bilder. Beim 90. Perzentil springt diese Zahl auf 52. Bei bildlastigen Seiten kann das Lazy Loading der Offscreen-Bilder einen echten Unterschied machen. Über alle von CoreDash überwachten Websites hinweg bestehen 76 % der Seiten, die Offscreen-Bilder ordnungsgemäß per Lazy Loading laden, den LCP, verglichen mit 59 % der Seiten, die dies nicht tun.

So beheben Sie 'defer offscreen images'

Um Eager-Loaded Offscreen-Bilder zu beheben, fügen Sie loading="lazy" zu jedem Bild hinzu, das sich Below-the-Fold (im nicht sofort sichtbaren Bereich) befindet. Natives Lazy Loading wird mittlerweile weltweit von 95 % der Browser unterstützt, einschließlich Chrome, Firefox, Safari und Edge. Sie benötigen dafür keine Bibliothek.

<img loading="lazy"
     src="image.webp"
     alt="ein natives per Lazy Loading geladenes Bild"
     width="300" height="300">

Verfolgen Sie die Ursprünge Ihrer Eager-Loaded Bilder zurück. Prüfen Sie, welche Bilder ohne ein loading-Attribut geladen werden, und finden Sie heraus, was sie auf der Seite platziert. Es gibt 5 übliche Verdächtige:

  1. Schlecht programmierte Plugins in Ihrem CMS.
    Einige Plugins fügen HTML direkt in die Seite ein und nutzen nicht die korrekten Hooks, die Lazy Loading aktivieren.
  2. Plugins, die natives Lazy Loading deaktivieren.
    Einige Plugins deaktivieren natives Lazy Loading standardmäßig. Überprüfen Sie Ihre Plugin-Einstellungen.
  3. Page Builder, die schlechtes HTML generieren.
    Page Builder wie Elementor oder WP Bakery erzeugen oft aufgeblähten Code, der alles andere als perfekt ist. Dafür gibt es keine einfache Lösung. Die Lösung besteht darin, Ihren Code zu bereinigen und Ihren Workflow zu ändern.
  4. Text, der kopiert und in einen WYSIWYG-Editor eingefügt wird.
    Die meisten WYSIWYG-Editoren wie TinyMCE leisten schlechte Arbeit bei der Bereinigung von eingefügtem Code, insbesondere wenn dieser aus einer anderen Rich-Text-Quelle wie Microsoft Word eingefügt wird. Diese Editoren fügen Ihren Bildern möglicherweise kein Lazy Loading hinzu.
  5. Schlechte Template-Programmierung.
    Selbst wenn Lazy Loading aktiviert ist, werden fest programmierte (hardcoded) Bilder in Ihren Templates möglicherweise trotzdem nicht per Lazy Loading geladen. Überprüfen Sie Ihre Templates auf Offscreen-Bilder und laden Sie diese per Lazy Loading.

Laden Sie Ihr LCP-Bild nicht per Lazy Loading

Dies ist die wichtigste Regel beim Lazy Loading: Wenden Sie loading="lazy" niemals auf Ihr Largest Contentful Paint-Bild an. Das LCP-Bild ist fast immer das Hero-Bild oder das größte sichtbare Element im Viewport. Laut dem Web Almanac 2025 laden immer noch 16 % der mobilen Seiten ihr LCP-Bild per Lazy Loading. Dieses einzige Attribut kann Ihren LCP um 200 bis 500 Millisekunden verlängern.

Tun Sie stattdessen für Ihr LCP-Bild genau das Gegenteil. Stellen Sie sicher, dass es so schnell wie möglich geladen wird, indem Sie fetchpriority="high" verwenden:

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Hero-Bild"
     width="1200" height="600">

Wenn Sie Ihr LCP-Bild versehentlich per Lazy Loading geladen haben, lesen Sie, wie Sie ein per Lazy Loading geladenes LCP-Bild korrigieren. Einen vollständigen Leitfaden zur Optimierung von Bildern finden Sie unter Bilder für Core Web Vitals optimieren.

Cheatsheet zum Laden von Bildern

Nicht jedes Bild sollte auf die gleiche Weise behandelt werden. Hier ist die Vorgehensweise für die 4 häufigsten Szenarien:

Bildtyp loading fetchpriority Warum
LCP- / Hero-Bild eager high Dies ist das wichtigste Bild. Laden Sie es zuerst.
Above the Fold (nicht LCP) eager (Standard) Sichtbar beim Laden, aber nicht das LCP-Element.
Below the Fold lazy (Standard) Noch nicht sichtbar. Aufschieben, bis der Nutzer scrollt.
CSS-Hintergrundbild IntersectionObserver loading="lazy" funktioniert nicht bei Hintergrundbildern. Verwenden Sie einen anderen Ansatz.

Natives Lazy Loading vs. Lazy-Loading-Skripte

Nutzen Sie natives loading="lazy". Im Jahr 2026 gibt es keinen Grund mehr, eine JavaScript-Lazy-Loading-Bibliothek für standardmäßige <img>-Elemente hinzuzufügen. Natives Lazy Loading wird von allen wichtigen Browsern, einschließlich Safari (seit Version 15.4), unterstützt und deckt weltweit 95 % der Nutzer ab. Es benötigt kein JavaScript, fügt keinen Overhead hinzu und funktioniert out of the box.

Bibliotheken wie lazysizes waren unverzichtbar, bevor Browser natives Lazy Loading unterstützten. Sie werden nicht mehr gepflegt und sind für die meisten Websites nicht mehr notwendig. Die einzigen Szenarien, in denen Sie möglicherweise noch eine JavaScript-Lösung benötigen:

  • CSS-Hintergrundbilder. Natives Lazy Loading funktioniert nur bei <img>- und <iframe>-Elementen. Für Hintergrundbilder benötigen Sie IntersectionObserver oder content-visibility: auto.
  • Benutzerdefinierte Ladeschwellenwerte. Chrome beginnt mit dem Laden von "lazy"-Bildern etwa 1250px unterhalb des Viewports bei schnellen Verbindungen und 2500px bei langsamen Verbindungen. Sie können diese Distanz nicht anpassen. Wenn Sie eine genauere Kontrolle benötigen, bietet Ihnen ein IntersectionObserver mit einem benutzerdefinierten rootMargin diese Möglichkeit.

Wenn Sie dennoch eine Bibliothek benötigen, verwenden Sie vanilla-lazyload anstelle von lazysizes. Sie wird aktiv gepflegt, verwendet IntersectionObserver und unterstützt Hintergrundbilder.

Verhindern Sie Layout Shifts bei per Lazy Loading geladenen Bildern

Geben Sie bei per Lazy Loading geladenen Bildern immer die Attribute width und height an. Ohne explizite Abmessungen weiß der Browser nicht, wie viel Platz er reservieren muss. Wenn das Bild schließlich geladen wird, schiebt es den umgebenden Inhalt nach unten und verursacht so einen Cumulative Layout Shift (CLS). Laut dem Web Almanac 2025 haben 62 % der mobilen Seiten immer noch mindestens ein Bild ohne Abmessungen.

<!-- Schlecht: verursacht Layout Shift -->
<img loading="lazy" src="photo.webp" alt="Foto">

<!-- Gut: Abmessungen reservieren den Platz -->
<img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">

Workarounds, wenn Lazy Loading nicht möglich ist

Manchmal ist es nicht möglich, Offscreen-Bilder aufzuschieben. Möglicherweise haben Sie keinen Zugriff auf das Template oder Ihr CMS unterstützt kein Lazy Loading. Es gibt ein paar Workarounds, um die Auswirkungen abzuschwächen. Diese sind weit entfernt von perfekt und könnten neue Herausforderungen mit sich bringen.

  • Komprimieren Sie Ihre Bilder. Kleinere Bilder wirken sich weniger auf die Lade-Performance aus als große Bilder. Verwenden Sie moderne Komprimierungstechniken, um die Dateigröße zu reduzieren.
  • Verwenden Sie schnellere Bildformate. Wechseln Sie von PNG und JPEG zu WebP oder AVIF. Laut dem Kapitel über Medien im Web Almanac 2024 komprimiert WebP auf etwa 1,3 Bits pro Pixel im Vergleich zu 2,0 bei JPEG.
  • Teilen Sie große Seiten auf mehrere Seiten auf. Die Aufteilung großer Seiten reduziert die Anzahl der Bilder, die gleichzeitig geladen werden müssen.
  • Implementieren Sie Infinite Scroll. Infinite Scroll ist im Grunde Lazy Loading, nur eben nicht für Bilder, sondern für ganze Teile der Webseite. Bei Seiten mit vielen sich wiederholenden Elementen (denken Sie an Pinterest) kann Infinite Scroll das anfängliche Laden erheblich beschleunigen.

Bei mobilspezifischen Überlegungen sind Offscreen-Bilder ein noch größeres Problem, da mobile Verbindungen langsamer und mobile Viewports kleiner sind, was bedeutet, dass mehr Bilder Offscreen landen.

Egal welchen Ansatz Sie wählen, stellen Sie sicher, dass er bei echten Nutzern funktioniert. Richten Sie Real User Monitoring ein, um zu verfolgen, ob Ihre Änderungen den LCP und die gesamten Core Web Vitals in der Praxis tatsächlich verbessern.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

I built CoreDash for my own audits.

Under 1KB. EU hosted. No consent banner. Now with MCP support.

Try CoreDash free
'Defer Offscreen Images' beheben: Lazy-Loading-Guide für Core Web VitalsCore Web Vitals 'Defer Offscreen Images' beheben: Lazy-Loading-Guide für Core Web Vitals