Lazy Loading

Lazy Loading bedeutet, nicht kritische Assets aufzuschieben, bis sie sich dem Viewport nähern. Für SEO ist der Vorteil simpel: weniger anfängliche Requests, leichtere Seiten und bessere Core Web Vitals. Der Haken ist genauso simpel. Lade das falsche Asset lazy, insbesondere das LCP-Bild, und du machst die Seite langsamer – nicht schneller.

Was für SEO tatsächlich zählt

Bei templates mit vielen Bildern kann Lazy Loading die anfänglichen Bild-Requests um 30–80 % reduzieren und die übertragenen Bytes um 500 KB bis mehrere MB senken. Das hilft in der Regel dem LCP, INP indirekt sowie der Crawl-Effizienz auf großen Websites. Nutze Google Search Console für Core-Web-Vitals-Trends, Lighthouse oder DebugBear für Labortests und Screaming Frog im JavaScript-Rendering-Modus, um zu prüfen, ob die nachgeladenen Assets noch im gerenderten HTML erscheinen.

Google unterstützt natives Lazy Loading seit Jahren, und Googles John Mueller hat wiederholt gesagt, dass Google Lazy-Content verarbeiten kann, wenn er korrekt implementiert ist. Dieser Zusatz ist entscheidend. Korrekt heißt: Das Asset wird noch im gerenderten DOM geladen, ohne dass dafür eine ungewöhnliche Nutzerinteraktion, eigene Scroll-Events oder defekte JS-Abhängigkeiten nötig sind.

So implementierst du es, ohne Rankings zu gefährden

• Nutze natives loading="lazy" für img- und iframe-Elemente unterhalb des sichtbaren Bereichs.
• Kein Lazy Loading für das Hero-Image oder ein mutmaßliches LCP-Asset. Setze dieses auf eager loading und erwäge fetchpriority="high".
• Reserviere Abmessungen mit width/height oder CSS aspect-ratio, um CLS zu vermeiden.
• Halte die echte Bild-URL im Markup. Vermeide Setups, bei denen die URL erst nach komplexer JS-Ausführung erscheint.
• Teste das gerenderte Ergebnis in Screaming Frog und die URL-Inspektion in GSC – nicht nur im Browser.

Ahrefs und Semrush zeigen dir nicht, ob Lazy Loading kaputt ist. Sie können allenfalls Traffic-Verluste im Nachhinein aufzeigen. Die Diagnose erfolgt in Rendering-Tools, Browser-Waterfalls und der Seitenebenen-Inspektion in GSC.

Wo Teams es falsch machen

Der häufigste Fehler ist, Lazy Loading als pauschale Regel zu behandeln. Das ist es nicht. Produktgitter, Artikel-Bodytexte, Module für verwandte Inhalte und eingebettete Videos sind gute Kandidaten. Bilder oberhalb der Falz, CSS-Backgrounds, die als Hero-Visual eingesetzt werden, sowie kritische Review-Widgets sind in der Regel keine.

Ein weiteres Problem: Hintergrundbilder. Natives Lazy Loading bringt für CSS-Backgrounds gar nichts. Deshalb glauben Teams, sie hätten die Seite optimiert, obwohl das schwerste visuelle Element das Rendering weiter blockiert. Dafür brauchst du eine andere Strategie – oft Template-Änderungen oder das Ersetzen dekorativer Backgrounds durch echte Bildelemente.

Das ehrliche Fazit

Lazy Loading ist nicht per se eine Ranking-Strategie. Es ist eine Auslieferungsstrategie. Wenn dein Engpass TTFB ist, aufgeblähtes JavaScript oder ein 1,5-MB-CSS-Bundle, wird Lazy Loading von Bildern die Seite nicht retten. Außerdem werden Crawl-Budget-Gewinne oft überbewertet. In den meisten Websites mit unter 100.000 URLs ist der größere SEO-Gewinn die nutzerseitige Geschwindigkeit – nicht die Effizienz der Bots.

Nutze es dort, wo es wirklich Requests spart. Überspringe es dort, wo es kritischen Content verzögert. Das ist das ganze Spiel.