Was ist Lazy Loading?

Verzögertes Laden sagt dem Browser, ein Bild oder ein <iframe> erst zu laden, wenn der Nutzer sich nähert. Seit 2020 braucht es dafür keine Bibliothek mehr: loading="lazy" im Tag genügt. Der Gegenwert heißt eager und ist zugleich das Standardverhalten.

Wann der Download beginnt, entscheidet der Browser selbst über eine Entfernungsschwelle, die sich nach der Verbindung richtet: Bei langsamem Netz fängt er früher an, damit das Bild rechtzeitig da ist. Einen festen Pixelwert gibt es deshalb nicht, und deshalb bringt es auch nichts, daran im CMS zu drehen.

Vor dem Attribut löste jede Seite das mit einer eigenen JavaScript-Bibliothek: Man markierte das Bild mit einem erfundenen Attribut, ein Skript beobachtete das Scrollen und schrieb den Pfad im richtigen Moment ins echte src. Das funktionierte und kostete zweierlei. Erstens das Gewicht des Skripts selbst, zweitens blieb die Seite bei einem JavaScript-Fehler ganz ohne Bilder, und ein Crawler sieht das genauso leer wie ein Besucher.

Die native Fassung nimmt beide Probleme weg und fügt ein feineres hinzu: Weil das Einschalten nichts kostet, wird überall eingeschaltet. Eine globale Einstellung im CMS markiert jedes Bild der Seite mit einem Klick, und niemand sieht danach nach, welches das erste war. Diese Bequemlichkeit ist der Grund, warum das Attribut heute in vielen Prüfungen zum technischen SEO als Ursache eines Problems auftaucht statt als Lösung.

Die Regel passt in einen Satz: verzögertes Laden für alles außer dem ersten sichtbaren Bild. Unterhalb der Falz spart es Daten und gibt Bandbreite frei, oberhalb hält es genau das Element auf, das den LCP bestimmt.

Der Schaden ist nicht theoretisch. Google dokumentiert den Fall ausdrücklich, weil viele Redaktionssysteme das Attribut pauschal auf alle Bilder setzen, das Aufmacherbild eingeschlossen. Der Browser fordert dann die wichtigste Datei nicht mehr früh an und wartet ab, wo sie im Layout landet — was in einer Vorlage mit Responsive Design spät entschieden wird.

Es lohnt zu verstehen, warum der Schaden bei so kleiner Ursache so groß ist. Der Browser baut beim Lesen des HTML eine Prioritätenliste und beginnt mit dem Wichtigsten, bevor er zu Ende gelesen hat. Ein als verzögert markiertes Bild fällt per Definition aus dieser frühen Liste: Der Browser fordert es erst an, wenn er weiß, wo es landet, und dafür braucht er angewandtes CSS und ein berechnetes Layout.

In einer modernen Vorlage passiert das deutlich nach dem ersten Byte. Am Ende wird die wichtigste Datei der Seite als eine der letzten angefordert, und der LCP nimmt diese Wartezeit vollständig auf. Deshalb fällt der Effekt mobil stärker aus, wo die Mobile-First-Indexierung entscheidet und das Netz meist schlechter ist, als auf dem Schreibtisch des Teams, das die Änderung gemacht hat.

Ein verzögert geladenes Bild ohne deklarierte width und height erzeugt einen Layoutsprung, sobald es ankommt: Der Browser hat keinen Platz reserviert. Das verschlechtert eine weitere der Core Web Vitals und stört den Nutzer genau beim Lesen.

<iframe>-Elemente nehmen dasselbe Attribut, und dort liegt oft der größere Gewinn: Ein eingebettetes Video oder eine Karte zieht hunderte Kilobyte fremder Skripte nach. Für per CSS gesetzte Hintergrundbilder gibt es das Attribut nicht; da braucht es einen Intersection Observer in JavaScript, mit dem Pflegeaufwand, den das im technischen On-Page-SEO bedeutet.

Eine dritte Voraussetzung wird häufiger vergessen als die beiden anderen: Verzögert geladene Bilder müssen im HTML weiterhin als normale <img> stehen, mit gesetztem src und ALT-Attribut. Ersetzt das Redaktionssystem sie durch einen Platzhalter, den ein Skript später füllt, hängt der Inhalt an der Ausführung dieses Skripts, und das wirkt sich auf die Indexierung der Bilder in der Google-Bildersuche aus.

Für Seiten, die von Bildern leben, eine Produktseite im E-Commerce oder eine Galerie, entscheidet dieses Detail, ob die Fotos in den Bildergebnissen auftauchen. Messen sollte man es mit Daten statt nach Gefühl: Der Leistungsbericht in Search Console trennt Bildersuche von Websuche, der Rückgang wird also dort sichtbar, wo er entsteht.

Seite öffnen, in PageSpeed Insights nachsehen, welches Element den LCP bestimmt, und prüfen, ob dieses <img> ein loading="lazy" trägt. Trägt es eines, hat man Ursache und Korrektur in einem Schritt.

Danach lohnt der Blick auf die Felddaten in Google Search Console, die Wochen brauchen, statt nur auf den Labortest. Und wenn die Seite von E-Commerce lebt, lohnt der Abgleich mit der Conversion: Geschwindigkeit zeigt sich im Geschäft früher als im Bericht.

Die zweite Prüfung ist langweiliger und nützlicher: in den Code der Vorlage sehen, nicht in den einer Seite. Das Problem sitzt fast nie in einem einzelnen Beitrag, sondern in der Datei, die alle erzeugt. Die gerade betrachtete Seite zu korrigieren lässt den Rest unverändert, und eine Woche später steht der Bericht wieder auf Rot, nur mit einer anderen URL.

Bei vielen Vorlagen lohnt es, vor dem ersten Eingriff nach Traffic zu sortieren und danach mit demselben Maßstab erneut zu messen. Ein KPI, der in einer Vorlage steigt und in einer anderen fällt, sagt nichts, wenn man beide zusammen ansieht.

• Verzögertes Laden über eine globale Einstellung für die ganze Seite einschalten, ohne das erste Bild auszunehmen.
• width und height vergessen und ein Geschwindigkeits- gegen ein Stabilitätsproblem tauschen.
• Es auf winzige Bilder wie Symbole anwenden, wo die zusätzliche Anfrage mehr kostet als sie spart.
• Eine JavaScript-Bibliothek pflegen für etwas, das der Browser längst selbst kann.
• Annehmen, es helfe dem Crawler: Der Roboter scrollt nicht wie ein Mensch.

Und ein grundsätzliches Missverständnis, das mehrere der vorigen Fehler erklärt: Verzögertes Laden macht die Seite nicht schneller, es verteilt die Arbeit anders. Die während eines vollständigen Besuchs geladene Gesamtmenge kann gleich bleiben; was sich ändert, ist, wie viel davon vor dem ersten Anblick passiert. Wer erwartet, dass das Gesamtgewicht sinkt, wird enttäuscht, und wer nur das Gesamtgewicht misst, sieht die Verbesserung nicht, die es beim wahrgenommenen Page Speed durchaus gibt.