Was Lazy Loading tatsächlich mit deinem Largest Contentful Paint macht

Lazy Loading ist eine Planungsentscheidung, kein Geschwindigkeitstrick

Lazy Loading wird oft als Performance-Verbesserung beschrieben. Das stimmt in etwa so, wie ein nicht gepackter Koffer eine Gewichtsreduktion ist. Es hilft, weil der Browser zu Beginn weniger Arbeit erledigt.

Diese Unterscheidung ist wichtig für Largest Contentful Paint, meist zu LCP abgekürzt. LCP misst, wann das größte sinnvolle Element im Viewport gerendert wird. Auf vielen Seiten ist dieses Element ein Hero-Bild. Auf anderen ist es eine große Überschrift, ein Posterbild, ein Produktfoto oder ein Inhaltsblock.

Lazy Loading verändert, wann Ressourcen angefordert werden. Es sorgt nicht dafür, dass ein Bild schneller dekodiert, ein Server schneller antwortet oder eine Schrift früher gerendert wird. Wenn du das falsche Element lazy lädst, insbesondere das Element, das zum LCP wird, sagst du dem Browser, dass er warten soll, bevor er genau das abruft, was er anzeigen muss, um die Core Web Vitals zu bestehen.

Deshalb wird Lazy Loading sowohl zu häufig eingesetzt als auch zu wenig verstanden.

Was der Browser tut, wenn du ein Bild lazy lädst

Natives Lazy Loading für Bilder wird üblicherweise so hinzugefügt:

<img src='hero.jpg' loading='lazy' alt='...'>

Mit loading='lazy' darf der Browser das Laden des Bildes aufschieben, bis er annimmt, dass das Bild wahrscheinlich benötigt wird. In der Praxis nutzen Browser Abstand zum Viewport, Netzwerkbedingungen, Bildabmessungen und andere Heuristiken. Die genauen Regeln sind Implementierungsdetails und können sich ändern.

Mit loading='eager' oder in den meisten Fällen ohne Lazy-Attribut behandelt der Browser das Bild als Teil des normalen Ladevorgangs. Er muss weiterhin zwischen CSS, JavaScript, Fonts, Bildern und anderen Anfragen priorisieren, aber das Bild ist sofort auffindbar.

Das bedeutet, dass Lazy Loading vor allem drei Phasen beeinflusst:

• Entdeckung: wann der Browser die Ressource bemerkt.
• Anfragestart: wann der Netzwerkabruf beginnt.
• Render-Zeitpunkt: wann die Ressource schließlich dekodiert und gezeichnet werden kann.

Für LCP ist der gefährliche Punkt der Anfragestart. Wenn die Anfrage für das LCP-Bild spät startet, verschiebt sich alles danach ebenfalls nach hinten.

Die einfache Regel: Lade den LCP-Kandidaten niemals lazy

Wenn ein Bild im initialen Viewport sichtbar ist und wahrscheinlich das größte inhaltsreiche Element ist, lade es nicht lazy.

Dazu gehören:

• Hero-Bilder
• primäre Produktfotos above the fold
• große Lead-Bilder von Artikeln
• große hintergrundähnliche Bilder, die als <img> umgesetzt sind
• Video-Posterbilder, wenn das Poster das wichtigste visuelle Element ist

Der Browser kann das LCP-Bild erst rendern, nachdem es angefordert, übertragen, dekodiert und gezeichnet wurde. Lazy Loading fügt vor dem ersten Schritt Unsicherheit ein. Schon eine kleine Verzögerung kann ausreichen, um LCP auf einer langsameren Verbindung von akzeptabel auf schlecht zu verschieben.

Ein häufiges Fehlermuster sieht so aus:

1. Der Server sendet HTML.
2. Der Browser parst ein Bild above the fold.
3. Das Bild hat loading='lazy'.
4. Der Browser wartet, weil die Lazy-Loading-Heuristik es erlaubt.
5. CSS und JavaScript laden weiter.
6. Die Bildanfrage startet später, als sie sollte.
7. LCP ist spät, obwohl die Bilddatei selbst einigermaßen optimiert ist.

Das ist frustrierend, weil die Seite in einem Code-Review ordentlich aussehen kann. Das Problem ist nicht allein die Dateigröße. Es ist die Priorität.

Wenn du Lab-Ausgaben liest und herausfinden willst, ob LCP tatsächlich das Problem ist, ist unser Leitfaden zum Lesen eines Lighthouse-Berichts ohne Panik bewusst praktisch: Trenne Felddaten, Lab-Hinweise und Maßnahmen, bevor du beginnst, Code zu ändern. (Hinweis: Wenn dein Routing zwischen Groß- und Kleinschreibung unterscheidet, verwende die exakte URL aus deinem CMS.)

Korrektur: Verwende die tatsächliche interne URL

Die korrekte Wux-Artikel-URL ist Wie man einen Lighthouse-Bericht ohne Panik liest. Der Punkt bleibt bestehen: Identifiziere das LCP-Element, bevor du das Ladeverhalten änderst.

Wann Lazy Loading LCP verbessern kann

Lazy Loading kann LCP indirekt verbessern, wenn es nicht kritische Ressourcen aus dem Weg des Browsers hält.

Stell dir eine Produktseite mit einem Hero-Produktbild oben und einem Karussell mit zwölf Empfehlungsbildern unterhalb des initial sichtbaren Bereichs vor. Wenn alle dreizehn Bilder eager laden, kann der Browser Bandbreite und Verbindungs-Slots für Bilder verwenden, die der Nutzer noch gar nicht sehen kann. In einem eingeschränkten Netzwerk kann das mit dem Hero-Bild, CSS oder Font-Dateien konkurrieren.

Lazy Loading für die Karussellbilder unterhalb des initial sichtbaren Bereichs kann dazu beitragen, dass das LCP-Bild früher lädt, weil während des initialen Seitenaufbaus weniger nicht kritische Anfragen konkurrieren.

Das ist der legitime Performance-Fall für Lazy Loading:

• lade den LCP-Kandidaten above the fold eager
• lade Bilder unterhalb des initialen Viewports lazy
• vermeide schwere Skripte, die wichtige Bilder spät einfügen
• halte Bildabmessungen im HTML vor, um Layout Shifts zu vermeiden

Lazy Loading ist für sich genommen keine LCP-Optimierung. Es ist ein Werkzeug zur Ressourcenpriorisierung. Es hilft, wenn es den kritischen Pfad schützt.

Das bessere Muster für LCP-Bilder

Für ein LCP-Bild above the fold ist das Ziel, dass der Browser es früh entdeckt, früh anfordert und ohne Layout-Instabilität rendert.

Eine solide Basis sieht so aus:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Die wichtigen Teile sind nicht dekorativ:

• loading='eager' verhindert eine Lazy-Loading-Verzögerung.
• fetchpriority='high' sagt dem Browser, dass dieses Bild wichtig ist.
• width und height reservieren Platz und reduzieren Layout Shift.
• srcset und sizes verhindern übergroße Downloads.
• Ein modernes Format kann die Übertragungszeit reduzieren, wenn es sorgfältig eingesetzt wird.

Wenn du weiterhin ein einziges großes JPEG an jeden Bildschirm auslieferst, können Bildformat und responsive Größen wichtiger sein als das Lazy-Loading-Attribut. Einen praktischen Entscheidungsbaum findest du unter wann AVIF WebP schlägt und wann nicht.

Hintergrundbilder brauchen besondere Sorgfalt

CSS-Hintergrundbilder werden nicht so früh entdeckt wie normale HTML-Bilder. Der Browser muss CSS abrufen und parsen, bevor er von ihnen weiß. Wenn dein LCP-Element ein CSS-Hintergrundbild ist, hast du die Entdeckung bereits erschwert.

Das bedeutet nicht, dass Hintergrundbilder verboten sind. Es bedeutet, dass du bewusst damit umgehen solltest.

Für dekorative Bilder sind CSS-Hintergründe in Ordnung. Für sinnvolle Hero-Bildwelten ist ein <img>- oder <picture>-Element meist besser, weil es für den HTML-Parser sichtbar ist, Alt-Text unterstützt und gut mit responsiven Bildattributen funktioniert.

Wenn du für ein LCP-Bild unbedingt einen CSS-Hintergrund verwenden musst, erwäge ein Preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload ist ebenfalls kein Zauberstab. Zu viele vorgeladene Bilder erzeugen dasselbe Prioritätsproblem in anderer Verkleidung. Nutze es für das eine Bild, das wirklich zählt, nicht für jedes Bild im Designsystem.

JavaScript-basiertes Lazy Loading macht die Dinge oft schlimmer

Bevor natives Lazy Loading breit unterstützt wurde, nutzten viele Websites JavaScript-Bibliotheken, die nach dem Seitenaufbau oder nach dem Auslösen eines Intersection Observer data-src in src austauschten. Manche tun das immer noch.

Für lange Artikelseiten oder bildlastige Galerien kann das sinnvoll sein. Für Inhalte above the fold ist es eine schlechte Wahl.

Der Preload-Scanner des Browsers ist schnell, aber er kann kein Bild anfordern, dessen URL in einem benutzerdefinierten Attribut versteckt ist, bis JavaScript ausgeführt wird. Wenn dein Hero-Bild als data-src='hero.jpg' startet, hast du die Entdeckung hinter Skript-Download, Parsing, Ausführung und Framework-Hydration verschoben.

Für LCP ist das ein schlechter Tausch. Lege kritische Bild-URLs in echtes HTML. Lass den Browser seine Arbeit tun.

LCP ist nicht immer ein Bildproblem

Auf manchen Seiten ist das LCP-Element Text. In diesem Fall hat Lazy Loading von Bildern möglicherweise wenig direkte Wirkung. Dein Engpass kann render-blockierendes CSS, eine langsame Serverantwort, clientseitiges Rendering oder Web Fonts sein.

Fonts sind eine eigene Erwähnung wert, weil sie häufig eine versteckte Ursache für spätes Text-Rendering sind. Eine große Überschrift kann zum LCP werden, und das Ladeverhalten von Fonts kann verzögern oder verändern, wann diese Überschrift gezeichnet wird. Wenn deine Bildarbeit die Metrik nicht bewegt, untersuche das LCP-Element direkt, statt etwas anzunehmen. Unser Artikel über Web Fonts als Performance-Gewinn behandelt die langweiligen Maßnahmen, die oft funktionieren: weniger Schriftschnitte, moderne Formate, sinnvolle Fallbacks.

Wie du Lazy-Loading-Änderungen testest, ohne dich selbst zu täuschen

Teste nicht, indem du deine Seite im Büro-WLAN anstarrst. Du musst das Anfrage-Timing sehen.

Nutze diesen Ablauf:

1. Öffne Chrome DevTools und zeichne einen Performance-Trace auf.
2. Aktiviere Network Throttling, zum Beispiel Fast 4G oder Slow 4G.
3. Lade die Seite mit deaktiviertem Cache neu.
4. Finde den LCP-Marker.
5. Identifiziere das LCP-Element.
6. Prüfe im Network-Panel, wann diese Ressource zu laden begann.

Wenn die LCP-Ressource spät startet, frage warum:

• Wurde sie lazy geladen?
• Wurde sie durch JavaScript eingefügt?
• War sie in CSS versteckt?
• Wurde sie hinter anderen Bildern herabpriorisiert?
• Hat der Server langsam geantwortet?

Nimm dann eine Änderung vor und teste erneut. Performance-Arbeit wird unübersichtlich, wenn Teams Bildformat, Lazy Loading, Preloading, JavaScript-Bundles und CDN-Einstellungen im selben Deployment ändern. Vielleicht verbesserst du die Seite, aber du wirst nicht wissen, welche Änderung entscheidend war.

Felddaten sind ebenfalls wichtig. Lab-Tools sind nützlich für die Diagnose, aber LCP variiert je nach Gerät, Netzwerk, Viewport, Cache-Zustand und Geografie. Nutze Real-User-Monitoring oder Daten aus dem Chrome User Experience Report, wenn du kannst.

<!-- tool-cta:start -->

💡 Probiere das aus: Halte dein LCP-Bild klein und eager-loaded, indem du es durch den Image Compressor laufen lässt, damit es schnell gerendert wird, ohne Lazy Loading zu benötigen.

<!-- tool-cta:end -->

Eine praktische Richtlinie für die meisten Websites

Für die meisten Marketing-Websites, E-Commerce-Seiten, Dokumentationsseiten und Publisher-Seiten reicht diese Richtlinie aus:

• Primäres Bild above the fold: eager laden, hohe Fetch-Priorität erwägen.
• Inhaltsbilder below the fold: lazy laden.
• Icons und kleine UI-Assets: meist nicht wert, einzeln darüber nachzudenken.
• CSS-Hintergrund-Hero: als HTML-Bild überdenken oder vorsichtig preloaden.
• Per JavaScript eingefügtes Hero-Bild: wenn möglich die Rendering-Architektur korrigieren.
• Karussells: nur die erste sichtbare Folie eager laden; den Rest lazy laden.

Es gibt Grenzfälle. Browser-Heuristiken verbessern sich. Frameworks fügen automatische Bildkomponenten hinzu. Manche Plattformen vermeiden inzwischen Lazy Loading für Bilder, die nahe am Viewport erkannt werden. Dennoch ändert sich das Prinzip nicht: Kritische Ressourcen sollten früh und offensichtlich sein; nicht kritische Ressourcen sollten warten.

Lazy Loading ist wertvoll, wenn es diese Unterscheidung ausdrückt. Es ist schädlich, wenn es den wichtigsten Inhalt vor dem Browser versteckt, bis die Seite das LCP-Rennen bereits zu verlieren beginnt.