Wer sich mit der Gestaltung von Webseiten beschäftigt, stößt über kurz oder lang auf den Begriff „lazy load“. Ich verstehe den Zweck, am Sinn habe ich Zweifel.
Der Zweck von „Lazy Load“ ist schnell erklärt. Sachen sollen erst dann auf eine Webseite geladen werden, wenn ein Besucher sie in den sichtbaren Bereich holt. Speziell große Bilder sollen so erst dann geladen werden, wenn es notwendig wird. Das mache die Webseiten schneller.
Was natürlich Quatsch ist. Die Ladezeiten für Inhalte werden lediglich besser verteilt, weshalb es sich schneller anfühlt und daher die Bereitschaft zum Verweilen steigt. Denn niemand mag langsame Webseiten.
Dafür werden diverse technische Kniffe und auch Webdienste angeboten. In Google Chrome soll es ab Version 75 einen versteckten Schalter geben, mit dem der Browser in die Lage versetzt wird, via CSS markierte Bilder mit Nachlade-Strategien zu behandeln:
chrome://flags/#enable-lazy-image-loading
Dieser Schalter wertet dann die (inoffizielle) CSS-Eigenschaft loading aus. Das sei dann „natives Lazy Load“, wen die HTML-Code so aussähe:
<img src="ein-dickes-bild.jpg" loading="lazy" alt="..." />
Mit den Parametern „lazy“, „eager“ oder „auto“ soll der Browser entscheiden, ob das Bild verzögert, doch lieber direkt oder wie er es für richtig hält geladen wird. Klappt allerdings nur, wenn …
- … es sich um einen Chrome-basierten Browser handelt,
- der Schalter vom Nutzer gesetzt wurde (Standard ist „Default“, was immer das ist),
- … die Webseite dafür vorbereitet ist.
In „meinem Vivaldi“ gibt es den Schalter – weil Chrome-basiert – ebenfalls. Dort vermittelt die Beschreibung den Eindruck, dass bei aktivem Schalter Bilder grundsätzlich erst geladen werden, wenn sie in den sichtbaren Bereich kommen. Aus dieser Sicht erscheint der Parameter loading womöglich überflüssig. Doch könnte man damit wahrscheinlich bei vielen großen Bildern eine Lastverteilung erreichen. Weil das in anderen Browsern keine Wirkung entfaltet, erscheint mir der Aufwand dafür fragwürdig. Denn konsequenterweise müsste für die Anderen eine alternative Methode zusätzlich implementiert werden.
Es geht einfacher und sparsamer
Vor „schnellen Seiten“ steht die Frage, was sie langsam macht. Dazu gehören unter anderem große Bilder. Wobei „groß“ allein auf die Dateigröße bezogen ist. Hier steckt die eigentliche Wahrheit von „lazy“: Viele Webseiten-Administratoren oder -Nutzer machen sich schlicht keine Gedanken über die (Datei-)Größe der Bilder, die sie auf einen Server laden. Diese Achtlosigkeit bremst Webseiten aus.
Bilder lassen sich mit sehr vertretbarem Aufwand hochwertig auf einer Webseite darstellen, ohne dass sie dafür megabyte-groß sein müssen.
Das beginnt bereits bei der Wahl des Dateityps und seiner Parameter. Hochwertige Digitalkameras machen üblicherweise Bilder mit hoher Auflösung und geringer (oder sogar keinerlei) Kompression. Vielleicht will ja irgendwer den Staub hinten auf dem Regal mit 1000%-Zoom genauer betrachten. Gebrauchsbilder für eine Webseite lassen sich jedoch bedenkenlos erheblich kleiner machen, ohne dass es dem Betrachter auffällt. Da kommt nämlich Physik ins Spiel.
Ein gesundes, menschliches Auge kann bei normalem Betrachtungsabstand von 30 cm keine einzelnen Punkte voneinander unterscheiden, die näher als 0,087 mm beieinander liegen. Bei einem Meter Betrachtungsabstand Verschmelzen Punkte bereits bei einem Abstand von 0,29 mm1.
Auf einem Bildschirm (egal ob Computer, Tablet oder Mobiltelefon) sieht bei einem „gesunden“ Betrachtungsabstand bei gleicher Anzeigegröße ein Bild mit einem Viertel der Bildpunkte deshalb unmerklich schlechter aus. Erst recht, wenn die direkte Vergleichsmöglichkeit fehlt. Allerdings ist der Datenbedarf signifikant kleiner.
Für die Darstellung auf der Webseite ist die physikalische Ausgabegröße irrelevant. Typischerweise orientiert sich die Bildgröße im Browser am verfügbaren Platz innerhalb des Fensters. Würde die vom Dateivolumen kleinste Variante („4. Änderung“) verwendet, wäre es als Hintergrundbild auf einem 52-Zoll 4K-Monitor ziemlich pixelig. Bei allem Ehrgeiz zum sparen gibt deshalb der Verwendungszweck die Grenzen für die Dateneinsparung vor. Wird es als WebP mit 40% Kompression gespeichert, mag ein sehr aufmerksamer Betrachter beim Vergrößern feststellen, dass es ein hochkomprimiertes Bild ist.
Anhand des dargestellten Handy-Schnappschusses sieht das in Zahlen so aus:
| Was | Dateigröße | Pixel | DPI | Ausgabegröße 100% |
|---|---|---|---|---|
| Original JPG 90% Kompression | 1.176 kB (100%) | 2956x3928 | 300 | 25x33cm |
| 1. Änderung: 70% Kompression | 485 kB (41%) | 2956x3928 | 300 | 25x33cm |
| 2. Änderung: 120 DPI | 108 kB (9%) | 1182x1571 | 120 | 25x33cm |
| 3. Änderung: Halbe Größe | 48 kB (4%) | 591x786 | 120 | 12,5x16,5cm |
| 4. Änderung: Dateiformat WebP | 15 kB (1%) | 591x786 | 120 | 12,5x16,5cm |
| Alternativ: Original als WebP, 40% Kompression | 166 kB (14%) | 2956x3928 | 300 | 25x33cm |
Bei kleinen Dateien, die trotzdem großflächig dargestellt werden können, kann ein einziges Bild für alle Darstellungen auf allen Geräten verwendet werden. Damit entfallen aufwändige CSS-Weichen, die passend zum Gerät und Platz ein anderes Bild laden. Die müssen natürlich auf dem Server vorliegen und werden wahlweise nachgeladen. Was zusätzlichen Datenverkehr und Verbindungen zum Server erfordert und die Webseite komplizierter sowie langsamer macht. Dazu kommt ein entsprechender Aufwand für die Erstellung der verschiedenen Bilder. Wer sich dafür auf die Automatismen von dafür angebotenen Server-Paketen verlässt, spart sich zwar selbst eventuell Arbeit. Mit ein wenig Arbeit lässt sich dagegen ein gut kontrolliertes und in der Wirkung sowohl für den Anbieter als auch den Besucher besseres Ergebnis erzielen.
Wer Seiten betreibt, auf die Nutzer Bilder hochladen können, ist bzgl. der Optimierung von Bildern auf Automation angewiesen. Hier lässt sich womöglich alternativ zu den verbreiteten Methoden der geschilderte Ansatz automatisieren: Umrechnung in WebP, Größenvergleich verschiedener Methoden, u.a.
Weil mit einer konsequenten Optimierung von Bildern die CSS-Dateien signifikant schlanker ausfallen können und keine zur Laufzeit startende Dienste womöglich noch fehlende Bilder in einen Cache generieren müssen, erübrigt sich sowohl der Dienst als auch eine „lazy load“-Strategie für die dadurch deutlich schlankere CSS-Datei.
Wenn Maschinen Vorschläge machen
Es gibt diverse Dienste, die eine Webseite analysieren und dann Verbesserungsvorschläge machen. Die sind objektiv erst einmal richtig. Wieviele Nano-Sekunden durch vergleichsweise komplexe und daher durchaus auch störanfällige Techniken beim Laden eingespart werden können, lässt sich damit objektiv kaum sagen. Weil relevantere Faktoren wie beispielsweise die verfügbare Bandbreite bei dieser theoretischen Betrachtung draußen bleiben.