Seite geladen, Bilder noch nicht …
Das Laden von Bildern zu verschieben, bis sie wirklich gebraucht werden, weil der Benutzer beim Scrollen in die Nähe kommt läßt den Anfang der Seite (over the fold) schneller »stehen« und wirkt am Ende nachhaltig.
Scrollt der Besucher nicht bis zum Bereich der Bilder, Video- oder iframe-Elemente, erspart loading lazy das Laden von Dateien, die nie sichtbar werden. Der Server wird ebenfalls entlastet, immerhin sind die Bilder auf vielen Webseiten die Hauptlast.
Lazy Loading lag früher voll in den Händen von Javascript, das erkennen musste, wie weit sich der Benutzer vorgearbeitet hatte. Ein EventListener für das Scroll-Event und getBoundingClientRect für die Berechnung der Position versetzen den Browser schnell ins Schwitzen und beim Scrollen hakelt es dann. Eine Erleichterung brachte schon der Intersection Observer, aber es bleibt beim Einsatz von Javascript.
loading eager, loading lazy
Für img und iframe gibt es das Attribut loading, das die Werte auto, eager und lazy annehmen kann. Mit auto ändert sich nichts: Der Browser entscheidet, was er in welcher Reihenfolge lädt.
- eager (eifrig bei der Sache) weist den Browser an, diese Bilder bevorzugt zu laden. Das wird vor allem bei Bildern over the fold eingesetzt.
- lazy weist den Browser an, ein Bild erst zu laden, wenn sich der Benutzer dem Bild beim Scrollen nähert. Die beste Übersetzung für lazy ist also »auf dem letzten Drücker«.
<img loading="lazy" src="black.jpg"
width="720" height="500"
alt="Erst laden, wenn das Bild sichtbar wird">
Safari, der Mac OS-Browser, hat erst spät das Nachladen von Bildern beigesteuert, Firefox hat sich bei iFrames Zeit gelassen. Aber heute unterstützen alle Browser das Nachladen »just in time«.
Lazy Loading Images und Drucken
U.U. waren nicht alle Bilder geladen, wenn die Webseite gedruckt wurde, obwohl der Benutzer noch nicht weit genug gescrollt war. Das haben die modernen Browser inzwischen aus dem Weg geräumt und Drucken auch die Bilder, die den Viewport des Browsers noch nicht erreicht haben.
Lazy Loading in WordPress 5.5
WordPress 5.5 hat das native loading=“lazy“ bereits implementiert und setzt das Attribut automatisch in das img-Tag, um Bandbreite sowohl beim Besucher als auch serverseitig zu sparen.
<figure class="wp-block-image alignwide size-large">
<img loading="lazy" width="1024" height="471"
src="…/null-eins-1024x471.jpg" alt="" class="wp-image-6726"
srcset="…/null-eins-1024x471.jpg 1024w,
…/null-eins-300x138.jpg 300w,
…/null-eins-768x353.jpg 768w,
…/null-eins-1536x707.jpg 1536w,
…/null-eins-1200x552.jpg 1200w,
…/null-eins.jpg 1960w"
sizes="(max-width: 1024px) 100vw, 1024px">
</figure>
Für die bereits vorhandenen Seiten führt WordPress das Attribut nach. Allerdings ist das native lazy loading nicht ganz ohne Nebenwirkungen. Der Browser kann das Layout erst korrekt rendern, wenn die Maße des Bildes feststehen. Ist das Bild ohne width- und height-Attribut gesetzt, kommt es zu einem CLS-Fehler (Layout Shift – das Layout ändert sich nachträglich), der Seiteninhalt verschiebt sich und ein Klick des Benutzers landet an der falschen Stelle.
WordPress setzt darum das loading-Attribut nur dann nachträglich in das img-Tag, wenn width und height-Attribut vorhanden sind.
In den folgenden Version hat WordPress dann das erste Bild der Seite vom lazy loading ausgenommen, denn das erste Bild ist oft das Logo der Seite oder aber erscheint direkt auf dem Screen, noch bevor der Benutzer die Seite scrollt.
decoding="async"
Seit Version 6.1 setzt WordPress nicht mehr nur auf loading=“lazy“, sondern fügt Bildern standardmäßig decoding=“async“ hinzu. Damit werden Bilder asynchron (wenn der Browser gerade mal Zeit hat) dekodiert – in Pixel umgewandelt.
loading=lazy oder decoding=async? Mit beiden Verfahren kann der Browser den sichtbaren Ausschnitt der Seite schneller darstellen. Eine Daumenregel sagt: Bei größeren Bildern hat decoding=async Vorteile, aber wenn width und height für das Bild angegeben sind, ist der Performance-Vorteil eher sehr gering. Bei vielen kleineren Bildern spart loading=lazy Bandbreite, wenn die Seite nicht bis zum Ende geschrollt wird.
Lazy Loading – background-image
Hintergrundbilder machen es dem Browser nicht so einfach. Zuerst muss der Browser anhand des CSS das Layout aufbauen – erst wenn er das HTML-Element für das Hintergrundbild findet, lädt er das Bild.
background-image verursacht keinen CLS-Fehler (Cumulative Layout Shift),
wenn die das Element eine feste Größe hat.
.hasBackgroundImage {
width: 75%;
aspect-ratio: 16:9;
}
Optimalerweise stehen dafür heute auch Container-Queries zur Verfügung. Wenn ein Hintergrundbild in einem Container liegt, der z. B. 75 % der Größe seines Eltern-Containers hat, dann kommt es nur darauf an, dass der Container beim Initial-Render eine definierte Größe hat.
.wrapper {
height: 800px;
}
.hero {
width: 75%;
height: 75%;
background-image: url(hero.jpg);
}
<div class="wrapper">
<div class="hero"></div>
</div>
Mit
.wrapper {
height: 800px;
}
hat der Block eine definierte Größe. Dann ist 75% sofort berechenbar →
kein CLS, weil der Platz reserviert ist. Aber wenn die Höhe nicht gekannt ist, kann tatsächlich ein CLS entstehen. Dagegen würde ein aspect-ratio: 16:9 helfen.
Mehr zu Fotos auf Webseiten
- Fotos und Grafik für das Web optimieren – welches Bilddatenformat für welches Bild JPG, PNG, SVG, WebP, AVIF
- Javascript: Prüfen, ob das Bild geladen ist – wenn die Seite geladen und aufgebaut ist, sind die Bilder noch unterwegs
- figure / figcaption wie geschaffen für Bilder und Bildunterschriften
