Natives Lazyloading im Browser

Mittlerweile unterstützen alle relevanten Browser das native Lazyloading für Bilder. Daher wurde das Lazyloading vom fCMS-eigenen Javascript auf die native Browserfunktionalität umgestellt. Stattdessen werden die Bildtags nun mit einem Attribut "loading=lazy" versehen.

Betroffen sind alle Bilder welche z.B. über die Tokenfunktion "imgtag" ausgespielt werden. In diesem Tag haben Sie auch die Möglichkeit, Bilder vom Lazyloading auszunehmen (Attribut "nolazy").

 {:bild-id|imgtag('detailelement-top',):} = < img loading="lazy" src="/design/pics/natur.jpg" alt="Alt Text!" width="500" height="320" />

 {:bild-id|imgtag('detailelement-top', 'nolazy'):} = < img src="/design/pics/natur.jpg" alt="Alt Text!" width="500" height="320" />

Wie wählt der Browser aus, welches Bild wann geladen wird?

• Wann die Bilder geladen werden, entscheidet der Browser aufgrund verschiedener Kriterien. Unterschiedliche Browser (z.B. Chrome, Firefox, Safari) können also "entscheiden" in welchem Abstand zum sichtbaren Viewport Bilder dem nativen Lazyloading unterliegen und wann sie gleich beim Aufruf der Seite geladen werden.

• Im Chrome ist z.B. der Schwellenwert gemäß dem Chrome Bilder lazyloaded oder nicht, nicht fix, sondern hängt auch von der Art der Verbindung und der Verbindungsgeschwindigkeit ab.

• Beispiel:
  • Bei einer schnellen (z.B. 4G) Verbindung lädt Chrome Bilder bis ca. 1250px unterhalb des sichtbaren Viewports.
  • Bei einer langsameren Verbindung (z.B. 3G oder langsamer), werden Bilder bis ca. 3000px unterhalb des sichtbaren Viewports geladen.
  • Somit werden bei einer langsameren Verbindung mehr Bilder nicht mit Lazyloading versehen.

Bildquelle: web.dev

• Dies scheint zunächst einmal widersinnig, doch Google selbst erklärt, dass dieses Verhalten von Chrome sicherstellen soll, dass Bilder ausserhalb des sichtbaren Viewport früh genug geladen werden, damit der Ladevorgang bereits beendet ist, wenn der Nutzer zur Stelle des Bildes scrollt. Daher müssen bei langsamen Verbindungen mehr Bilder bereits frühzeitig im Hintergrund geladen werden, um zu vermeiden, dass beim Scrollen anstelle der Bilder leere Flächen erscheinen. Die Berechnungsgrundlagen für das Anzeigen der Bilder werden laut Google ständig überprüft und ggfs. in einer neuen Browserversion optimiert.

• Der Nachteil dieses Verhalten ist, dass wir als Entwickler diesen Schwellenwert nicht beeinflussen können, wenn wir z.B. für alle Verbindungsgeschwindigkeiten die gleiche Anzahl von Bildern lazyloaden oder grundsätzlich weniger Bilder lazyloaden möchten.

• Firefox und Safari laden grundsätzlich weniger Bilder, eine genau Dokumentation mit der Berechnung dieses Schwellenwertes konnten wir jedoch nicht finden. Er scheint aber bei ca. 600px unter dem sichtbaren Viewport zu liegen.

• Bei Glidern, in denen die Bilder horizontal angeordet sind, kann es passieren, dass alle Bilder des Gliders gleich geladen werden, da der Browser initial eine Größe von 0px x 0px für das Bild annimmt und damit theoretisch unbegrenzt viele Bilder im Viewport Platz fänden (Siehe: https://web.dev/browser-level-image-lazy-loading/#images-should-include-dimension-attributes). Daher ist es notwendig, dass Bilder sowohl ein width- als auch ein height-Attribut besitzen. Dies wurde im fCMS mit der Einführung des nativen Lazyloading implementiert. Anhand der nun vorhandenen Dimensionen des Bildes kann der Browser abschätzen, wie viele Bilder im Viewport sichtbar sein sollen.

 

Was ist beim Einsatz des nativen Lazyloading zu beachten?

• Das LCP-Bild (also das erste Bild der Webseite im sichtbaren Viewport) sollte man niemals lazyloaden. Auch wenn der Browser es sofort darstellen wird, da es sich ja im sichtbaren Bereich befinden, wird dieses Bild durch das "loading="lazy"-Attribut eventuell nicht mit hoher Priorität vom Browser angefordert, was in den Core Web Vitals zu einem schlechteren LCP führen kann. Daher sollte man solche Bilder im Imagetag immer mit "nolazy" zu versehen.

• Zusätzlich empfiehlt Google ebenfalls, das LCP-Bild mit einem fetchpriority="high" zu versehen, um dem Browser zu signalisieren, dieses Bild auf jeden Fall priorisiert zu laden. Im fCMS werden daher alle Bilder, die im Imagetag mit "nolazy" ausgezeichnet sind, automatisch auch mit fetchpriority="high" versehen um es möglichst schnell darstellen zu können und den LCP-Wert nicht zu beeinträchtigen.

• Da Imagetags nun mit width und height ausgegeben werden, ist es notwendig, das CSS des Portals zu erweitern, um zu gewährleisten, dass die im Imagetag mit width und height angegebenen Werte nach Laden des Bildes korrekt überschrieben werden, um verzerrte Bilder und Darstellungsprobleme zu vermeiden.

img {
  max-width: 100%;
  width: 100%;
  height: auto;
}

 

Mit der Umstellung ergeben sich folgende Vorteile:

• Das Verwenden von JavaScript zum Lazyloading erfordert das Laden und Ausführen von zusätzlichem Code, was zu einem gewissen Overhead führt. Dies kann die Gesamtleistung der Website beeinträchtigen und zu längeren Ladezeiten führen. Das native Lazyloading hingegen nutzt die nativen Funktionen des Browsers, was zu einer effizienteren Nutzung der Ressourcen führt.

• Google hebt hervor, dass mit dem nativen Lazyloading im Chrome Bilder ausserhalb des sichtbaren Viewport rechtzeitig genug geladen werden, damit der Ladevorgang bereits beendet ist, wenn der Nutzer zur Stelle des Bildes scrollt, was zu einer guten Nutzererfahrung beiträgt.

• Bei der Performance-Messung in Lighthouse wurden bislang die fehlenden Dimensionen der Bilder bemängelt. Mit der Änderung wird das behoben sein.

• Fehlende width- und height-Attribute bei Bildern führen häufig zu einem höheren CLS (Cumulative Layout Shift), da sich das Layout nach dem Laden der Bilder noch einmal verschiebt. Die width- und height-Attribute geben hier nun einen Platzhalter vor, der frei bleibt bevor die Bildern dann nachgeladen werden. Auch wenn die tatsächlichen Abmessungen des Bildes hinterher vom Platzhalter noch einmal geringfügig abweichen, wird sich der CLS durch eine geringere Layoutverschiebung dennoch verbessern.