Lazy Loading in WordPress: was der Browser schon kann, und wo ein Plugin bremst

Lazy Loading war lange ein Grund, ein Plugin zu installieren. Ein Skript tauschte Platzhalter gegen echte Bilder, sobald jemand nach unten scrollte, und die Seite fühlte sich schneller an. Diese Arbeit übernimmt heute der Browser, mit einem einzigen HTML-Attribut. WordPress schreibt es dir ungefragt in den Quelltext.

Wer trotzdem noch einen Lazy-Loader aus alten Tagen mitschleppt, hat zwei Mechanismen für dieselbe Aufgabe. Im besten Fall ist das bloß überflüssig. Im schlechtesten hält es das Bild auf, auf das deine Besucher am längsten warten.

Was loading="lazy" eigentlich tut

Das Attribut ist eine Bitte an den Browser, ein Bild nicht sofort zu holen. Laut MDN-Referenz zum img-Element verschiebt der Browser das Laden, bis das Bild eine von ihm selbst berechnete Entfernung zum sichtbaren Bereich erreicht. Wie groß diese Entfernung ist, bestimmst nicht du. Der Browser entscheidet, und das ist gut so: Er kennt Verbindung und Bildschirm, du nicht.

Für eingebettete Seiten gilt dasselbe, denn auch das iframe-Element kennt loading="lazy" und wird dann erst geholt, wenn es in die Nähe des sichtbaren Bereichs kommt. Das betrifft eingebettete Videos, Karten und Formulare von Drittanbietern.

<img src="hafen.jpg" width="1200" height="800" loading="lazy" alt="Containerschiff am Kai">

Achte auf width und height. Ohne Maße weiß der Browser nicht, wie viel Platz das Bild einnehmen wird, bevor es da ist, und der Text darunter springt, wenn es ankommt. Bei verzögert geladenen Bildern fällt das stärker auf, weil das Nachladen mitten im Lesen passiert. WordPress zieht daraus eine harte Konsequenz, dazu gleich mehr.

Was WordPress seit Jahren automatisch macht

Du musst das Attribut nicht selbst setzen. Der Kern erledigt das seit 2020 und hat die Regeln seitdem mehrfach nachgeschärft. Jede Zeile stützt sich auf die jeweilige Entwicklernotiz auf make.wordpress.org.

Praktisch heißt das: Ein aktuelles WordPress mit einem ordentlich gebauten Theme lädt Bilder weiter unten verzögert und das Hauptbild oben mit Vorrang, ohne dass du einen Schalter umlegst.

Es bleibt eine Schätzung. WordPress entscheidet auf dem Server, welches Bild vermutlich oben steht, und kennt dabei weder die Bildschirmgröße deines Besuchers noch das, was dein Theme per CSS aus dem Inhalt macht. Bei einem einspaltigen Blog passt das in aller Regel. Bei Startseiten mit Kachelraster, Slider oder Page-Builder lohnt sich ein Blick, ob die Schätzung stimmt.

Warum das LCP-Bild nie lazy laden darf

LCP steht für Largest Contentful Paint: der Moment, in dem das größte Element im ersten Bildschirm sichtbar ist. Meist ist das ein Titelbild, ein Hero-Foto oder das Vorschaubild eines Videos, manchmal ein großer Textblock. Google zählt den Wert zu den Core Web Vitals, und als gut gilt ein LCP von 2,5 Sekunden oder weniger.

Ein Bild mit loading="lazy" fordert der Browser erst an, wenn er das Layout berechnet hat und weiß, wo es steht. Für ein Bild weit unten ist das richtig. Für das wichtigste Bild der Seite ist es die falsche Reihenfolge: Es wartet auf einen Rechenschritt, den es nicht bräuchte, und startet später, als es könnte. Googles Leitfaden zur LCP-Optimierung sagt es ohne jede Einschränkung: das LCP-Bild nie lazy laden, weil das immer zu unnötiger Verzögerung führt.

Wie real das Problem ist, hat WordPress am eigenen Kern erlebt. In der ersten Fassung von 2020 bekam fast jedes Bild das Attribut, auch das oberste. Felix Arntz und Rick Viscomi haben die Folgen für web.dev ausgewertet (Stand der Auswertung: März 2022): 84 Prozent der Seiten mit browsereigenem Lazy Loading liefen auf WordPress, und im Labortest mit dem Standard-Theme Twenty Twenty-One wurde der LCP auf Archivseiten um 13 bis 15 Prozent besser, sobald Lazy Loading abgeschaltet war, während es auf Einzelbeitragsseiten kaum einen Unterschied machte. Die Korrektur kam mit Version 5.9, siehe Tabelle.

Warum ein zusätzliches Lazy-Load-Plugin meist nichts bringt

Klassische Lazy-Load-Skripte arbeiten nach einem Muster, das du im Quelltext sofort erkennst. Die echte Bildadresse wandert aus src in ein Ersatzattribut wie data-src, an ihrer Stelle steht ein Platzhalter, und ein Skript setzt die Adresse zurück, sobald das Bild in Sichtweite kommt. Bevor das Attribut 2020 zum Webstandard wurde, war das der einzige Weg. Heute hat es vier Nachteile:

• Der Browser sieht das Bild zu spät. Normalerweise beginnt er mit dem Herunterladen, sobald er das HTML liest. Steht dort nur ein Platzhalter, wartet das Bild auf das Skript, und das Skript wartet auf alles, was vor ihm lädt.
• Das oberste Bild trifft es am härtesten. Ein Skript, das jedes Bild gleich behandelt, verzögert auch das LCP-Bild. Diesen Fehler hat WordPress mit 5.9 und 6.3 im eigenen Kern behoben.
• Zwei Mechanismen für eine Aufgabe. Je nach Plugin bleibt das Attribut des Kerns zusätzlich stehen oder wird entfernt. Lädt etwas nicht, suchst du an zwei Stellen.
• Ohne JavaScript kein Bild. Fällt das Skript aus, etwa wegen eines Fehlers in einem ganz anderen Plugin, bleibt der Platzhalter stehen, sofern kein noscript-Ersatz mitgeliefert wird.

Wie teuer ein per Skript nachgeladenes Hauptbild werden kann, haben wir in unserer Fallstudie zum Theme-Wechsel gemessen. Nach dem Umstieg auf ein schnelles WordPress-Theme stand der LCP mobil immer noch bei 4 bis 6 Sekunden, weil das größte Element auf den wichtigsten Seiten ein Video-Poster war, das erst per JavaScript nachgeladen wurde. In einer zweiten Runde wurde dieses Vorschaubild per preload mit hoher Priorität geholt und sofort als CSS-Hintergrund gezeigt, statt auf das Einbettungsskript zu warten.

Auf der Kursseite fiel der LCP danach von 5,2 auf 4,0 Sekunden, mobil gemessen mit Lighthouse. Zur Ehrlichkeit gehören zwei Einschränkungen. In derselben Runde kamen weitere Maßnahmen dazu, den Anteil des Posters allein haben wir nicht getrennt gemessen. Und 4,0 Sekunden liegen weiter über der Grenze von 2,5.

Unsere Empfehlung für ein aktuelles WordPress: Lazy-Load-Funktionen in Plugins abschalten, dem Kern das Feld überlassen, nachmessen. Nutzt du ein Optimierungs-Plugin, dessen Lazy Load du behalten willst, sieh nach, ob es Bilder im oberen Bereich ausnehmen kann, und nimm mindestens das Hauptbild heraus.

So prüfst du, ob dein LCP-Bild versehentlich lazy lädt

Der schnelle Blick: Untersuchen

1. Seite in Chrome öffnen, F12 drücken und mit Strg+Umschalt+M die Geräteansicht einschalten. Auf dem Handy kann ein anderes Element das größte sein als am Desktop.
2. Rechtsklick auf das große Bild im ersten Bildschirm, dann Untersuchen.
3. Im img-Tag nachsehen. Steht dort loading="lazy", oder fehlt src und es gibt nur data-src samt einer Klasse wie lazyload, dann lädt dein wichtigstes Bild verzögert.
4. Steht dort fetchpriority="high", haben WordPress oder dein Theme es richtig erkannt.

Der gründliche Blick: Performance-Panel und Lighthouse

Im Performance-Panel der Entwicklerwerkzeuge und in Lighthouse gibt es den Hinweis „LCP request discovery“ (so heißt er in der englischen Oberfläche). Laut Chrome-Dokumentation prüft er, ob das LCP-Bild direkt im HTML auffindbar ist, ob es fetchpriority="high" trägt und ob es ohne loading="lazy" auskommt.

Für Neugierige: eine Zeile in der Konsole

new PerformanceObserver(l => { const e = l.getEntries().at(-1); console.log(e.element, e.element?.loading, Math.round(e.startTime) + ' ms'); }).observe({ type: 'largest-contentful-paint', buffered: true });

In die Konsole der Entwicklerwerkzeuge einfügen und Enter drücken. Ausgegeben werden das LCP-Element, sein loading-Wert und der Zeitpunkt in Millisekunden. Steht dort lazy, hast du den Fehler gefunden. Der Zeitwert stammt aus deinem Rechner und deiner Leitung, er ersetzt keine Messung unter gleichen Bedingungen.

Wenn du fündig wirst

• Lazy-Loader im Plugin: Ausnahme für das Hauptbild eintragen oder die Funktion ganz abschalten.
• Bild im Theme-Template: Wer es mit wp_get_attachment_image() ausgibt, übergibt 'loading' => false, dann lässt WordPress das Attribut weg.
• Hero als CSS-Hintergrund: Den sieht der Browser erst, wenn er das Stylesheet gelesen hat. Hier hilft ein Vorladen mit Vorrang im Kopf der Seite, wie in unserer Fallstudie:

<link rel="preload" as="image" href="/bilder/hero.webp" fetchpriority="high">

Wann ein Plugin oder ein paar Zeilen Skript doch sinnvoll sind

Hintergrundbilder aus dem CSS

Das Attribut gibt es für img und iframe. Auf die Frage, ob CSS-Hintergrundbilder es nutzen können, antwortet Googles Leitfaden zum browsereigenen Lazy Loading mit einem knappen Nein. Für große Hintergrundbilder weit unten, wie sie Page-Builder gern in Abschnitte setzen, gibt es also keine eingebaute Bremse.

Hier hat ein Skript seine Berechtigung, das die Klasse mit dem Hintergrundbild erst setzt, wenn der Abschnitt in Sichtweite kommt, per IntersectionObserver. Oft ist der Umbau die bessere Lösung. Wo ein Hintergrundbild in Wahrheit Inhalt ist, gehört es als img ins HTML, und der Browser übernimmt wieder selbst.

Eingebettete Videos: eine Fassade statt des Players

Bei YouTube-Videos setzt WordPress seit 5.7 loading="lazy" an das iframe, wenn die Maße stimmen. Das verschiebt das Laden, verhindert es aber nicht. Kommt das Video in die Nähe des Bildschirms, lädt der Browser den kompletten Player samt Verbindung zu YouTube, auch wenn niemand auf Abspielen drückt.

Auf hafenstudios.com binden wir Videos deshalb als Fassade ein. Im HTML steht kein iframe, sondern ein Link auf das Video bei YouTube mit einem Vorschaubild von unserem eigenen Server. Erst der Klick ersetzt den Link per Skript durch ein iframe auf youtube-nocookie.com, das sofort abspielt. Bis dahin lädt die Fassade nichts von YouTube, und ohne JavaScript bleibt ein gewöhnlicher Link, der zu YouTube führt. Vereinfacht und ohne Gestaltung sieht das so aus wie im Beitrag mit unserem ersten Video:

<a class="yt-facade" href="https://youtu.be/VIDEO-ID" data-ytid="VIDEO-ID">
  <img src="/assets/blog/vorschau.jpg" width="1280" height="720" decoding="async" alt="…">
</a>
<script>
document.querySelector('.yt-facade').addEventListener('click', function (e) {
  e.preventDefault();
  var i = document.createElement('iframe');
  i.src = 'https://www.youtube-nocookie.com/embed/' + this.dataset.ytid + '?autoplay=1';
  i.allow = 'autoplay; encrypted-media; picture-in-picture';
  i.allowFullscreen = true;
  this.innerHTML = '';
  this.appendChild(i);
});
</script>

Das Vorschaubild ist ein gewöhnliches img und folgt denselben Regeln wie jedes andere Bild. In den Video-Beiträgen steht die Fassade direkt nach dem ersten Absatz und trägt kein loading-Attribut. Auf der Produktseite unseres Werbe-Plugins Adjet steht sie erst im dritten Abschnitt. Im Labor-Befund vom 28. September 2026 lag diese Seite mobil bei einem LCP von 2,5 bis 2,6 Sekunden, als einzige von 14 gemessenen Seiten über 2,5 Sekunden, und notiert war ein 129 KB großes Vorschaubild, das sofort lud. Seit dem 29. September trägt es loading="lazy" und kommt als WebP. Eine Nachmessung steht in dem Befund nicht, deshalb nennen wir hier keine Nachher-Zahl.

Galerien mit vielen Bildern

In Galerien spart Lazy Loading am meisten. Eine Seite mit 60 Fotos lädt beim Aufruf nur die, die in der Nähe des Bildschirms liegen, der Rest folgt beim Scrollen. Dafür brauchst du keinen eigenen Lazy-Loader im Galerie-Plugin. Drei Dinge sollten aber stimmen:

• Breite und Höhe an jedem Bild. Ohne beides setzt WordPress das Attribut gar nicht, und das Raster springt beim Nachladen.
• srcset und sizes. Lazy Loading spart die Bilder, die niemand sieht. Bei denen, die geladen werden, entscheidet die passende Größe: Ein Handy braucht für eine schmale Kachel keine Datei in voller Breite. Bilder aus der Mediathek bekommen srcset von WordPress.
• Die erste Reihe nicht verzögern. Steht die Galerie ganz oben, sind ihre ersten Bilder Kandidaten für das LCP-Bild. WordPress nimmt seit 6.3 die ersten drei Inhaltsbilder aus. Zeigt deine erste Reihe vier oder fünf Bilder, hebst du die Schwelle für diese Seite an:

add_filter( 'wp_omit_loading_attr_threshold', function ( $schwelle ) {
	return is_page( 'galerie' ) ? 8 : $schwelle;
} );

Der Filter stammt aus WordPress 5.9 und gehört in die functions.php eines Child-Themes oder in ein Snippet-Plugin. Die Zahl entspricht den Bildern, die bei dir im ersten Bildschirm stehen. Nicht mehr, sonst verlierst du die Ersparnis weiter unten.

Liegen die Bilder außerhalb der Mediathek, etwa in eigenen Tabellen und Ordnern eines Galerie-Plugins, ergänzt der Kern weder srcset noch fehlende Maße, denn beides kann er nur für Mediathek-Anhänge ermitteln. Bei unserem Galerie-Plugin Heckgalerie ist eine Galerie eine Liste gewöhnlicher Mediathek-Anhänge: srcset und Bildgrößen kommen von WordPress, Raster und Logoleisten kommen ohne JavaScript aus, und Skripte lädt es nur auf Seiten, die einen Slider oder eine Lightbox enthalten (so steht es im Eintrag im WordPress-Verzeichnis, Stand 4. Oktober 2026). Wer gerade von einem schweren Galerie-Plugin weg will, findet die Kandidaten im Vergleich der Alternativen zu NextGEN Gallery.

In dieser Reihenfolge vorgehen

1. WordPress aktuell halten, ab 6.3 erledigt der Kern die Grundarbeit.
2. Doppelte Lazy-Loader abschalten. Einer reicht, und der Kern ist schon einer.
3. LCP-Element auf Handy und Desktop prüfen: kein loading="lazy", kein data-src.
4. Hintergrundbilder und Videos gezielt lösen.
5. Vorher und nachher messen, mit derselben Methode. Was sonst noch Tempo kostet, steht in der Anleitung, wie du eine langsame WordPress-Seite beschleunigst.

Häufige Fragen