Lazy Loading

Kurzdefinition

Lazy Loading, auf Deutsch etwa „verzögertes Laden“, schiebt das Laden einer Ressource auf, bis sie tatsächlich gebraucht wird. Im Web betrifft das meist Bilder und iframes weiter unten auf der Seite: Der Browser holt sie kurz bevor sie in den sichtbaren Bereich scrollen, statt alles auf einmal herunterzuladen.

Die Idee ist einfach. Eine lange Kategorieseite enthält vielleicht 60 Produktbilder, ein Video und eine Karte. Die meisten Besucher scrollen nie bis ganz unten. Alles vorab zu laden kostet Datenvolumen und konkurriert mit den Ressourcen, die zuerst gebraucht werden. Mit Lazy Loading setzt der Browser seine frühe Netzwerkzeit für den sichtbaren Teil der Seite ein.

Die Technik hat zwei Seiten. Bei Medien außerhalb des Viewports spart sie Daten und entlastet die Leitung. Am falschen Element verzögert sie das Hauptbild, verursacht Layout-Verschiebungen oder versteckt Inhalte vor Crawlern, die sich nicht wie ein scrollender Mensch verhalten.

So funktioniert natives Lazy Loading

Moderne Browser unterstützen Lazy Loading direkt in HTML, über das Attribut loading an <img>- und <iframe>-Elementen:

html<img src="/bilder/trailschuh-seite.jpg"
     alt="Trailrunning-Schuh, Seitenansicht"
     width="800" height="600"
     loading="lazy">

<iframe src="https://www.youtube.com/embed/VIDEO_ID"
        title="Produktvideo"
        width="560" height="315"
        loading="lazy"></iframe>

Das Attribut kennt zwei Werte. lazy verzögert die Anfrage, bis das Element in die Nähe des Viewports kommt. eager lädt sofort, und genau das passiert auch, wenn das Attribut fehlt.

Was „in der Nähe“ bedeutet, entscheidet der Browser. Laut web.dev beginnt Chromium derzeit etwa 1.250 Pixel vor dem Viewport mit dem Laden, wenn die Verbindung schnell ist, und etwa 2.500 Pixel vorher bei langsameren Verbindungen. Andere Browser verwenden eigene Abstände. Der Puffer soll dafür sorgen, dass ein Bild in der Regel fertig ist, wenn der Besucher dort ankommt.

Natives Lazy Loading wird für Bilder und iframes in allen aktuellen großen Browsern unterstützt. Ältere Browser ignorieren das Attribut einfach und laden normal, es geht also nichts kaputt.

Natives Attribut oder JavaScript-Bibliothek

Bevor es das Attribut gab, lief Lazy Loading über JavaScript, und viele Websites nutzen bis heute Bibliotheken.

Ein typisches Muster speichert die echte Bild-URL in einem data-src-Attribut, zeigt im src einen Platzhalter und tauscht beides, sobald ein IntersectionObserver meldet, dass das Element nahe am Viewport ist. Das funktioniert, kostet aber zusätzliches Skript, und die echte URL steht erst im src, nachdem das Skript gelaufen ist.

Ältere Skripte haben stattdessen auf Scroll-Events gewartet. Diese sind für SEO riskant, denn ohne Scrollen lädt nichts.

Für Bilder und iframes ist das native Attribut die bessere Voreinstellung. JavaScript bleibt sinnvoll für das, was das Attribut nicht abdeckt:

• CSS-Hintergrundbilder, die kein loading-Attribut haben
• Komponenten oder Widgets, die erst geholt werden sollen, wenn sie sichtbar werden
• Inhalte, die in Abschnitten nachgeladen werden, etwa bei Infinite Scroll

Wenn du ein Skript brauchst, ist IntersectionObserver die richtige Grundlage. Es reagiert auf Sichtbarkeit im Viewport, nicht auf eine bestimmte Nutzeraktion.

Was Lazy Loading verbessert

Auf einer langen Seite mit vielen Bildern verringert Lazy Loading die beim ersten Aufruf geladenen Bytes, macht Netzwerkkapazität für die Ressourcen des ersten Viewports frei und spart Datenvolumen für alle, die nie scrollen. Auf Mobilverbindungen ist der Effekt größer.

Bei iframes ist der Gewinn oft am höchsten. Ein einzelnes Video- oder Karten-Embed kann viel Skript und weitere Ressourcen nachziehen. Embeds unterhalb des ersten Viewports verzögert zu laden oder bis zum Klick durch eine schlanke Vorschau zu ersetzen, hält diese Kosten aus dem ersten Ladevorgang heraus.

Lazy Loading ist ein Teil der Bildoptimierung, kein Ersatz dafür. Ein Titelfoto mit 2 MB bleibt ein Titelfoto mit 2 MB, ob verzögert oder nicht. Passende Abmessungen, moderne Formate, Kompression und responsive Größen über srcset bringen meist mehr.

Die LCP-Falle

Der häufigste Fehler beim Lazy Loading trifft ausgerechnet das wichtigste Bild. Largest Contentful Paint, einer der Core Web Vitals, misst, wann das größte sichtbare Element im Viewport gerendert ist. Auf vielen Seiten ist das ein Titelbild oder ein Produktfoto.

Ein verzögert geladenes Bild kann nicht so früh starten wie ein sofort geladenes. Der Browser braucht zuerst Layout-Informationen, um zu wissen, ob das Bild im oder nahe am Viewport liegt. Er kann es also nicht schon beim ersten Blick ins HTML anfordern. Bei einem Bild im ersten Viewport landet diese Verzögerung direkt im LCP.

Das war kein theoretisches Problem. WordPress hat ab Version 5.5 standardmäßig loading="lazy" an Bilder gehängt. Eine später auf web.dev veröffentlichte Auswertung ergab, dass verzögert geladene Bilder im ersten Viewport den LCP tendenziell verschlechterten, und WordPress setzt das Attribut seitdem nicht mehr an die ersten Bilder einer Seite.

Die Lösung ist überschaubar:

• Entferne loading="lazy" vom wahrscheinlichen LCP-Bild und von anderen Bildern im ersten Viewport.
• Erwäge fetchpriority="high" am LCP-Bild, damit der Browser es früh anfordert.
• Sorge dafür, dass die URL des LCP-Bilds im ursprünglichen HTML steht und nicht erst per JavaScript hinzukommt.

Lighthouse prüft das. In aktuellen Versionen markiert der Insight zur LCP-Anfrageerkennung (LCP request discovery) ein LCP-Bild, das verzögert geladen wird oder für den Browser schwer früh zu entdecken ist.

Lazy Loading und Layout-Verschiebungen

Wenn ein Bild ohne reservierten Platz lädt, rutscht alles darunter nach unten. Mit Lazy Loading passiert das oft, während der Besucher schon liest, und es zeigt sich als Cumulative Layout Shift.

Die Lösung hat mit der Ladestrategie selbst nichts zu tun: Gib jedem Bild und jedem iframe die Attribute width und height oder reserviere den Platz über die CSS-Eigenschaft aspect-ratio. Dann hält der Browser den richtigen Raum frei, bevor die Datei ankommt.

Wie Google mit nachgeladenen Inhalten umgeht

Googles Leitlinie zu Lazy Loading läuft auf eine Regel hinaus: Inhalte müssen laden, sobald sie im Viewport sichtbar werden, ohne Nutzeraktionen wie Scrollen, Klicken oder Tippen. Googlebot scrollt die Seite nicht so, wie ein Mensch es tut. Ein Skript, das auf ein Scroll-Event wartet, kann in der von Google gerenderten Fassung Bilder, Text oder Links ungeladen lassen.

Google nennt drei geeignete Wege: das browsereigene Lazy Loading für Bilder und iframes, die IntersectionObserver-API oder eine JavaScript-Bibliothek, die Inhalte lädt, wenn sie in den Viewport kommen. Alle drei reagieren auf Sichtbarkeit statt auf Interaktion.

Für die Bildersuche muss die Bild-URL auffindbar sein. Google indexiert Bilder aus <img>-Elementen, auch innerhalb von <picture>, aber keine CSS-Hintergrundbilder. Wenn eine Bibliothek die echte URL in data-src hält und im src nur einen Platzhalter, sieht Google das echte Bild nur, wenn beim Rendering der Tausch passiert. Prüfe das im gerenderten HTML.

Text oder Links verzögert zu laden ist riskanter als Bilder. Wenn ein Abschnitt mit Produktbeschreibungen oder eine Liste verwandter Artikel erst nach einer Interaktion erscheint, existieren Inhalt und Links für Google womöglich nicht. Das ist genauso ein Thema für JavaScript-Rendering wie für Performance.

Infinite Scroll und „Mehr laden“

Infinite Scroll ist Lazy Loading für ganze Inhaltsabschnitte. Es braucht besondere Sorgfalt, denn die Einträge weiter unten in einer Liste sind oft genau die Seiten, die gecrawlt werden sollen.

Google empfiehlt paginiertes Laden: Jeder Abschnitt bekommt eine eigene, dauerhafte URL, zum Beispiel ?page=2, und die Seite aktualisiert die URL beim Scrollen über die History-API. Jede dieser URLs sollte außerdem über normale Links erreichbar sein. Ein „Mehr laden“-Button, der nur ein Skript auslöst und auf keine echte Folgeseite verlinkt, lässt Crawler im ersten Abschnitt stecken.

Was du nicht verzögert laden solltest

Als Faustregel gilt: Alles, was Besucher ohne Scrollen sehen, lädt sofort.

• das Titelbild oder das Hauptfoto eines Produkts
• das Logo und Icons im ersten Viewport
• der eigentliche Textinhalt der Seite
• Navigation, einschließlich Menüs und Breadcrumb-Spuren
• strukturierte Daten und Metadaten

Der letzte Punkt erwischt manche JavaScript-Setups. Meta-Tags und Vorschaubilder gehören in die Serverantwort. Scraper für Linkvorschauen auf sozialen Plattformen führen meist gar kein JavaScript aus. Ein Teilen-Bild, das erst erscheint, nachdem ein Lazy-Loading-Skript gelaufen ist, wird dann womöglich nie gefunden. Wenn dein CMS das Open-Graph-Bild automatisch befüllt, prüfe, ob es auf die echte Datei zeigt und nicht auf einen Lazy-Loading-Platzhalter.

Ein durchgespieltes Beispiel

Eine Rezeptseite nutzt ein langes Artikel-Template: großes Titelfoto, Zutatenliste, zwölf Schrittfotos, ein Video und einen Kommentarbereich.

Die erste Version setzt über eine Theme-Einstellung loading="lazy" an jedes Bild. Die Felddaten zeigen einen schwachen mobilen LCP, und das LCP-Element ist das Titelfoto. Lighthouse bestätigt, dass das LCP-Bild verzögert geladen wird.

Die Korrektur: Das Titelfoto lädt sofort mit fetchpriority="high", die zwölf Schrittfotos bleiben verzögert, jedes Bild bekommt width und height, und das Video wird zu einer schlanken Vorschau, die den Player erst beim Klick lädt. Der Kommentarbereich lädt per IntersectionObserver, sobald er in den Viewport kommt, nicht über Scroll-Events. Die URL-Prüfung in der Search Console zeigt Schrittfotos und Kommentare im gerenderten HTML.

Häufige Fehler

• das Titelbild oder LCP-Bild verzögert laden
• alles über einen globalen Theme-Schalter verzögert laden
• sich auf Scroll-Events verlassen, die Crawler nie auslösen
• Text, Links oder Navigation erst nach einem Klick laden
• width und height weglassen und damit Layout-Verschiebungen erzeugen
• Infinite Scroll ohne paginierte URLs und echte Links
• Bild-URLs nur in data-src halten und das gerenderte HTML nie prüfen
• erwarten, dass Lazy Loading zu große Bilder repariert
• die URL des Teilen-Bilds aus einem Lazy-Loading-Platzhalter erzeugen

So prüfst du Lazy Loading

1. Bestimme das LCP-Element jedes wichtigen Templates mit Lighthouse oder PageSpeed Insights.
2. Prüfe, ob dieses Element oder etwas anderes im ersten Viewport loading="lazy" trägt.
3. Stelle sicher, dass Bilder und iframes außerhalb des Viewports Lazy Loading nutzen, wo es echte Bytes spart.
4. Kontrolliere, ob jedes Bild und jedes iframe Abmessungen oder ein reserviertes Seitenverhältnis hat.
5. Suche JavaScript-basiertes Lazy Loading und prüfe, ob es auf Sichtbarkeit oder auf Scroll-Events reagiert.
6. Vergleiche mit der URL-Prüfung in der Search Console das gerenderte HTML mit dem, was du im Browser siehst.
7. Teste Infinite Scroll und „Mehr laden“-Listen auf paginierte URLs, die normal verlinkt sind.
8. Vergleiche Felddaten vor und nach einer Änderung. Eine Verbesserung im Labor beweist noch keine im Feld.

Crawl-Foundry-Perspektive

Probleme mit Lazy Loading zeigen sich an zwei Stellen: in Performance-Messungen und im HTML, das ein Crawler zu sehen bekommt. Crawl Foundry deckt im Site Audit beide Seiten ab.

Für die Performance haben wir uns bewusst für den offiziellen Lighthouse-Runner entschieden, derzeit Lighthouse 13, auf unseren eigenen Servern, statt fremde Zahlen weiterzureichen. Jede Messung läuft als isolierte Aufgabe. Die Lighthouse-Messung selbst kostet dich nichts extra. Der Site Audit insgesamt ist eine kostenpflichtige Datenaktion, und den Preis siehst du, bevor du startest. Lighthouse liefert Labordaten. Es zeigt dir also, ob das LCP-Bild in einem bestimmten Lauf verzögert geladen wird. Ob echte Besucher betroffen sind, beantworten weiterhin die Felddaten.

Für Inhalte und Links prüft der Crawler das gerenderte HTML und zeigt die internen Links, die er im DOM gefunden hat, mit Quelle, Ziel, Ankertext und Position. Fehlt in diesen Links eine Produktliste oder eine Liste verwandter Artikel, prüfe, ob sie erst nach Scrollen oder Klicken lädt. Wie ein Crawl und sein Verlauf eingerichtet werden, erklärt die Feature-Seite zum Site Audit.

Verwandte Begriffe

• Seitengeschwindigkeit
• Page-Experience-Metriken
• Mobile SEO
• Video-SEO
• Google Search Console
• Crawling

Quellen für den Review

• Google Search Central: Lazy-Loading-Inhalte korrigieren
• Google Search Central: Best Practices für die Bilder-SEO
• web.dev: Browser-level image lazy loading for the web
• web.dev: The performance effects of too much lazy loading
• web.dev: Optimize Largest Contentful Paint
• MDN Web Docs: Lazy loading
• WHATWG HTML Standard: Lazy loading attributes