Bilder machen auf vielen Webseiten den größten Teil des übertragenen Datenvolumens aus. Wer alle Grafiken bereits beim Seitenaufruf herunterlädt, zwingt den Browser dazu, auch Bilder zu laden, die der Besucher vielleicht nie zu Gesicht bekommt. Lazy Loading dreht dieses Prinzip um: Bilder werden erst dann geladen, wenn sie tatsächlich in die Nähe des sichtbaren Bereichs rücken. Das verkürzt die anfängliche Ladezeit, spart Bandbreite und verbessert messbare Kennzahlen wie die Core Web Vitals. In diesem Ratgeber erfährst du, wie du Lazy Loading sauber umsetzt, welche Stolperfallen es gibt und wann verzögertes Laden ausnahmsweise schadet.
Was Lazy Loading konkret bedeutet
Beim klassischen Laden fordert der Browser jede im HTML referenzierte Ressource sofort an. Bei Lazy Loading werden Bilder hingegen aufgeschoben: Erst wenn der Nutzer scrollt und ein Bild sich dem Viewport nähert, beginnt der Download. Der Effekt ist besonders bei langen Seiten mit vielen Grafiken deutlich – etwa Blogs, Online-Shops oder Bildergalerien. Statt dutzender paralleler Anfragen beim ersten Aufruf konzentriert sich der Browser zunächst auf das, was wirklich auf dem Bildschirm zu sehen ist. Die restlichen Bilder folgen nach und nach, gesteuert durch das Scrollverhalten.
Der Vorteil zeigt sich vor allem auf mobilen Geräten und langsamen Verbindungen. Weniger gleichzeitige Downloads bedeuten, dass die wichtigen Inhalte schneller verfügbar sind und die Seite früher interaktiv wirkt.
Die einfachste Lösung: natives loading="lazy"
Moderne Browser unterstützen Lazy Loading direkt im HTML – ganz ohne JavaScript-Bibliothek. Dazu genügt ein einziges Attribut am Bild:
- loading="lazy" – das Bild wird verzögert geladen, sobald es sich dem sichtbaren Bereich nähert.
- loading="eager" – das Bild wird sofort geladen (Standardverhalten, wenn nichts angegeben ist).
Ein typisches Inhaltsbild sieht damit so aus: <img src="foto.jpg" loading="lazy" width="800" height="600" alt="Beschreibung">. Diese native Variante ist robust, wartungsarm und kostet keine zusätzliche Rechenzeit im Browser. Sie sollte deshalb immer die erste Wahl sein, bevor man zu komplexeren Skript-Lösungen greift. Das Attribut funktioniert auch für eingebettete iframes und lässt sich problemlos mit responsiven Bildtechniken kombinieren.
Layout-Sprünge vermeiden: width und height setzen
Ein häufig unterschätztes Problem beim verzögerten Laden sind Layout-Sprünge. Kennt der Browser die Maße eines Bildes nicht, reserviert er keinen Platz dafür. Sobald das Bild später nachgeladen wird, schiebt es den darunter liegenden Text nach unten. Dieses Verhalten verschlechtert den Wert Cumulative Layout Shift (CLS) – eine der Core-Web-Vitals-Kennzahlen, die unruhige Layouts bestraft.
Die Lösung ist simpel: Gib jedem Bild die Attribute width und height mit den tatsächlichen Pixelmaßen mit. Moderne Browser berechnen daraus das Seitenverhältnis und halten den Platz frei, auch wenn das Bild per CSS skaliert wird. Alternativ lässt sich über die CSS-Eigenschaft aspect-ratio dasselbe Ziel erreichen. Wichtig ist nur, dass der Browser von Anfang an weiß, wie viel Raum ein Bild beanspruchen wird.
Above-the-fold und LCP nicht lazy laden
So nützlich Lazy Loading ist – beim wichtigsten Bild der Seite kann es nach hinten losgehen. Der Bereich, der ohne Scrollen sichtbar ist, wird Above-the-fold genannt. Bilder in diesem Bereich sind ohnehin sofort zu sehen; sie zu verzögern bringt keinen Vorteil, sondern verzögert nur ihren Aufbau.
Besonders kritisch ist das LCP-Bild. LCP steht für Largest Contentful Paint und misst, wann das größte sichtbare Element fertig geladen ist – oft ein Hero-Bild ganz oben. Wird ausgerechnet dieses Bild mit loading="lazy" versehen, kann der Browser es später anfordern, und der LCP-Wert verschlechtert sich spürbar. Die Faustregel lautet deshalb:
- Bilder oberhalb der Falz: eager laden (kein
loading="lazy"). - Das vermutete LCP-Bild zusätzlich priorisieren, etwa mit
fetchpriority="high". - Alle Bilder weiter unten auf der Seite:
loading="lazy".
Responsive Bilder mit srcset und sizes
Lazy Loading entfaltet seine volle Wirkung erst zusammen mit passend dimensionierten Bildern. Es bringt wenig, ein riesiges Foto verzögert zu laden, wenn auf einem schmalen Smartphone nur eine kleine Version nötig wäre. Hier helfen die Attribute srcset und sizes: Du hinterlegst mehrere Bildvarianten in unterschiedlichen Breiten, und der Browser wählt anhand der Bildschirmgröße und Pixeldichte die am besten geeignete aus.
Ein Beispiel: <img src="bild-800.jpg" srcset="bild-400.jpg 400w, bild-800.jpg 800w, bild-1600.jpg 1600w" sizes="(max-width: 600px) 100vw, 800px" loading="lazy" width="800" height="500" alt="Beschreibung">. So lädt ein Mobilgerät nur die kleine Datei, während ein großer Monitor die hochauflösende Variante bekommt. Kombiniert mit modernen Formaten wie WebP oder AVIF lassen sich Dateigrößen oft deutlich reduzieren. Wer Bildmaße oder Seitenverhältnisse schnell prüfen möchte, findet im Bereich Webtools passende Helfer.
IntersectionObserver als Fallback für Sonderfälle
Für die meisten Seiten reicht das native Attribut vollkommen aus. Es gibt jedoch Situationen, in denen mehr Kontrolle gewünscht ist – etwa Hintergrundbilder, die per CSS gesetzt werden, oder Inhalte, die erst nach einer Benutzerinteraktion erscheinen. CSS-Hintergrundbilder werden vom nativen loading-Attribut nicht erfasst, da dieses nur für <img> und iframes gilt.
Hier kommt der IntersectionObserver ins Spiel, eine Browser-Schnittstelle, die meldet, wann ein Element in den sichtbaren Bereich eintritt. Mit wenigen Zeilen JavaScript lässt sich damit ein eigenes Lazy-Loading-System bauen: Sobald ein Platzhalter in den Viewport rückt, tauscht das Skript die echte Bildquelle ein. Der IntersectionObserver ist effizient, weil er nicht bei jedem Scroll-Ereignis rechnet, sondern den Browser die Beobachtung übernehmen lässt. Als Strategie gilt: native Lösung zuerst, eigenes Skript nur dort, wo es wirklich nötig ist.
Lade-Strategie nach Bildposition
Welche Methode für ein Bild richtig ist, hängt stark von seiner Position auf der Seite ab. Die folgende Übersicht fasst eine praxistaugliche Strategie zusammen.
| Bildposition | Empfohlene Lade-Strategie | Begründung |
|---|---|---|
| Hero / Above-the-fold | Eager laden, ggf. fetchpriority="high" |
Sofort sichtbar und meist das LCP-Element; Verzögerung würde die wahrgenommene Ladezeit verschlechtern. |
| Inhaltsbilder im Fließtext | loading="lazy" + srcset/sizes |
Erst beim Scrollen relevant; spart Bandbreite und beschleunigt den ersten Aufbau. |
| Galerie / lange Listen | loading="lazy" |
Viele Bilder unterhalb der Falz; verzögertes Laden verhindert eine Flut paralleler Downloads. |
| Footer / ganz unten | loading="lazy" |
Wird oft gar nicht erreicht; sofortiges Laden wäre reine Verschwendung. |
| CSS-Hintergrundbild | IntersectionObserver | Natives Attribut greift nicht; eigenes Skript steuert das Nachladen gezielt. |
Typische Fehler und wie du sie vermeidest
- Alle Bilder lazy laden: Das Hero-Bild gehört nicht dazu, sonst leidet der LCP-Wert.
- Fehlende Maße: Ohne
widthundheightdrohen Layout-Sprünge und ein schlechter CLS-Wert. - Zu große Originaldateien: Lazy Loading ersetzt keine Bildkomprimierung – beides ergänzt sich.
- Komplexe Skripte ohne Not: Wenn das native Attribut genügt, braucht es keine zusätzliche Bibliothek.
Wer diese Punkte beachtet, holt mit überschaubarem Aufwand spürbar mehr Geschwindigkeit aus seiner Seite. Weitere praxisnahe Anleitungen rund um Web und Technik findest du im News-Bereich, und einen Überblick über alle Angebote gibt die Startseite.
Häufige Fragen
Brauche ich für Lazy Loading überhaupt JavaScript?
In den allermeisten Fällen nicht. Das native Attribut loading="lazy" wird von modernen Browsern direkt unterstützt und deckt normale Inhaltsbilder zuverlässig ab. JavaScript brauchst du nur für Sonderfälle wie CSS-Hintergrundbilder oder feinere Steuerung.
Verbessert Lazy Loading mein Google-Ranking?
Lazy Loading wirkt indirekt: Es kann die Core Web Vitals verbessern, die Teil der Bewertung von Seitenerlebnis sind. Eine schnellere, stabilere Seite ist für Besucher angenehmer, was sich positiv auswirken kann. Eine Garantie für ein besseres Ranking ist es allein jedoch nicht.
Warum soll das oberste Bild nicht lazy geladen werden?
Bilder oberhalb der Falz sind sofort sichtbar. Wird gerade das größte davon – meist das LCP-Element – verzögert, lädt der Browser es später, und der gemessene Ladezeitpunkt verschlechtert sich. Above-the-fold-Bilder sollten daher eager geladen werden.
Was hat Lazy Loading mit Layout-Sprüngen zu tun?
Wenn der Browser die Maße eines nachgeladenen Bildes nicht kennt, reserviert er keinen Platz. Beim späteren Erscheinen springt das Layout. Mit korrekten width- und height-Angaben oder aspect-ratio hältst du den Platz frei und vermeidest das.
Funktioniert Lazy Loading auch für iframes?
Ja. Das Attribut loading="lazy" lässt sich auch an <iframe>-Elementen verwenden, etwa für eingebettete Videos oder Karten. So werden auch diese Ressourcen erst geladen, wenn sie in die Nähe des Viewports kommen.
Ersetzt Lazy Loading die Bildkomprimierung?
Nein, beide Maßnahmen ergänzen sich. Lazy Loading verschiebt den Zeitpunkt des Ladens, ändert aber nichts an der Dateigröße. Erst die Kombination aus verzögertem Laden, komprimierten Dateien und modernen Formaten wie WebP oder AVIF bringt das beste Ergebnis.