Leistungsauswirkungen von zu viel Lazy Loading

Datengestützte Empfehlungen für das Lazy Loading von Bildern unter Berücksichtigung der Core Web Vitals.

Felix Arntz

Rick Viscomi

Lazy Loading ist eine Technik, bei der das Herunterladen einer Ressource verzögert wird, bis sie benötigt wird. Dadurch werden Daten gespart und Netzwerküberlastungen für kritische Assets reduziert. 2019 wurde es zu einem Webstandard und heute wird loading="lazy" für Bilder von den meisten gängigen Browsern unterstützt.

In diesem Leitfaden wird zusammengefasst, wie öffentlich verfügbare Webtransparenzdaten und Ad-hoc-A/B-Tests analysiert wurden, um die Akzeptanz und Leistungsmerkmale des Lazy Loadings von Bildern auf Browserebene zu verstehen. Zu den Ergebnissen gehörte, dass Lazy Loading ein erstaunlich effektives Tool zur Reduzierung unnötiger Bildbytes sein kann, eine übermäßige Nutzung jedoch die Leistung beeinträchtigen kann. Konkret zeigt diese Analyse, dass wir das Beste aus beiden Welten erhalten, wenn wir Bilder im ursprünglichen Darstellungsbereich schneller laden und den Rest großzügig per Lazy Loading laden: weniger geladene Byte und verbesserte Core Web Vitals.

Akzeptanz

Laut den neuesten Daten im HTTP Archive wird das integrierte Lazy Loading von Bildern von 29 % der Websites verwendet und die Akzeptanz nimmt rasant zu.

Eine Abfrage der Rohdaten im HTTP Archive-Projekt gibt uns ein klareres Bild davon, welche Arten von Websites die Akzeptanz vorantreiben: 84 % der Websites, die Lazy Loading für Bilder auf Browserebene verwenden, nutzen WordPress, 2 % ein anderes CMS und die restlichen 14 % kein bekanntes CMS. Diese Ergebnisse zeigen deutlich, dass WordPress bei der Akzeptanz führend ist.

Auch die Akzeptanzrate ist erwähnenswert. Vor einem Jahr, im Juli 2020, machten WordPress-Websites, die Lazy Loading verwenden, Zehntausende Websites im Korpus von etwa 6 Millionen aus (1 % der Gesamtzahl). Allein bei WordPress wird Lazy Loading inzwischen auf über 1 Million Websites (14 % aller Websites) eingesetzt.

Korrelationsleistung

Bei genauerer Betrachtung des HTTP-Archivs lässt sich vergleichen, wie Seiten mit und ohne Lazy Loading von Bildern auf Browserebene beim Messwert „Largest Contentful Paint“ (LCP) abschneiden. Die LCP-Daten stammen aus dem Chrome User Experience Report (CrUX) und basieren auf tatsächlichen Nutzererfahrungen, nicht auf synthetischen Tests im Labor. Im folgenden Diagramm wird ein Box-Whisker-Plot verwendet, um die Verteilungen des 75. Perzentils des LCP der einzelnen Seiten zu visualisieren: Die Linien stellen das 10. und 90. Perzentil dar und die Boxen das 25. und 75. Perzentil.

Die durchschnittliche Seite ohne Lazy Loading hat einen LCP-Wert im 75. Perzentil von 2.922 Millisekunden, verglichen mit 3.546 Millisekunden für die durchschnittliche Seite mit Lazy Loading. Insgesamt weisen Websites, die Lazy Loading verwenden, tendenziell eine schlechtere LCP-Leistung auf.

Es ist wichtig, darauf hinzuweisen, dass es sich hierbei um korrelative Ergebnisse handelt, die nicht unbedingt darauf hindeuten, dass Lazy Loading die Ursache für die langsamere Leistung ist. Wenn WordPress-Websites tendenziell etwas langsamer sind und einen großen Teil der Lazy Loading-Kohorte ausmachen, könnte das den Unterschied erklären. Um diese Variabilität zu eliminieren, kann der Fokus speziell auf WordPress-Websites eingegrenzt werden.

Leider zeigt sich dasselbe Muster, wenn man sich WordPress-Seiten genauer ansieht: Seiten, die Lazy Loading verwenden, haben tendenziell eine langsamere LCP-Leistung. Die durchschnittliche WordPress-Seite ohne Lazy Loading hat einen LCP-Wert im 75. Perzentil von 3.495 Millisekunden, verglichen mit 3.768 Millisekunden für die durchschnittliche Seite mit Lazy Loading.

Das ist zwar kein Beweis dafür, dass Lazy Loading die Seiten tatsächlich langsamer macht, aber die Verwendung von Lazy Loading geht mit einer langsameren Leistung einher. Um die Frage nach der Kausalität zu beantworten, wurde ein laborbasierter A/B-Test eingerichtet.

Kausale Leistung

Ziel des A/B-Tests war es, die Hypothese zu beweisen oder zu widerlegen, dass das integrierte Lazy Loading von Bildern, wie es im WordPress-Core implementiert ist, zu einer langsameren LCP-Leistung und weniger Bildbytes führt. Dazu wurde eine WordPress-Demowebsite mit dem Theme twentytwentyone getestet. Sowohl die Archiv- als auch die Einzelseitentypen wurden getestet. Sie ähneln den Start- und Artikelseiten auf Computern und emulierten Mobilgeräten, die mit WebPageTest getestet wurden. Es wurde jede Kombination von Seiten mit und ohne Lazy Loading getestet. Jeder Test wurde neunmal ausgeführt, um den Medianwert für den LCP und die Anzahl der Bild-Byte zu ermitteln.

In diesen Ergebnissen wird der mittlere LCP-Wert in Millisekunden für Tests auf Archiv- und Einzelseiten für Computer und Mobilgeräte verglichen. Als das Lazy Loading auf Archivseiten deaktiviert wurde, verbesserte sich der LCP-Wert erheblich. Auf einzelnen Seiten war der Unterschied jedoch weniger groß.

Wenn Lazy Loading deaktiviert wird, werden die einzelnen Seiten anscheinend etwas schneller geladen. Der Unterschied beim LCP ist jedoch sowohl bei Desktop- als auch bei Mobiltests geringer als eine Standardabweichung. Dies könnte auf Abweichungen zurückzuführen sein und die Änderung wird insgesamt als neutral angesehen. Im Vergleich dazu liegt der Unterschied bei Archivseiten eher bei zwei bis drei Standardabweichungen.

In diesen Ergebnissen wird die mittlere Anzahl von Bild-Byte (in KB) für jeden Test verglichen. Wie erwartet hat Lazy Loading einen sehr deutlichen positiven Effekt auf die Reduzierung der Anzahl der Bild-Bytes. Wenn ein echter Nutzer durch die gesamte Seite scrollen würde, würden alle Bilder geladen, sobald sie in den Darstellungsbereich gelangen. Diese Ergebnisse zeigen jedoch die verbesserte Leistung beim ersten Seitenaufbau.

Zusammenfassend lässt sich sagen, dass die von WordPress verwendete Lazy-Loading-Technik die Anzahl der Bild-Bytes deutlich reduziert, allerdings auf Kosten eines verzögerten LCP.

Fehlerbehebung testen

Der wichtigste Aspekt der aktuellen Lazy-Loading-Implementierung von WordPress für dieses Experiment ist, dass Bilder im Darstellungsbereich (above the fold) per Lazy Loading geladen werden. Im CMS-Blogpost wird eingeräumt, dass dieses Muster vermieden werden sollte. Die damaligen experimentellen Daten deuteten jedoch darauf hin, dass die Auswirkungen auf den LCP minimal waren und es sich lohnte, die Implementierung im WordPress-Core zu vereinfachen.

Auf Grundlage dieser neuen Daten wurde eine experimentelle Lösung entwickelt, bei der Bilder oberhalb des sichtbaren Bereichs nicht per Lazy Loading geladen werden. Diese Lösung wurde unter denselben Bedingungen wie der erste A/B-Test getestet.

Diese Ergebnisse sind vielversprechender. Wenn nur die Bilder „below the fold“ (mit Scrollen sichtbar) per Lazy Loading geladen werden, wird die LCP-Regression vollständig umgekehrt und es kann sogar zu einer leichten Verbesserung gegenüber der vollständigen Deaktivierung von Lazy Loading kommen. Wie kann das schneller sein, als wenn gar kein Lazy Loading verwendet wird? Eine Erklärung dafür ist, dass durch das Nichtladen von Bildern unterhalb der „Seitenfalte“ weniger Netzwerkkonflikte mit dem LCP-Bild auftreten, sodass es schneller geladen werden kann.

In Bezug auf die Bildbytes gibt es im Vergleich zum Standardverhalten absolut keine Änderung. Das ist großartig, denn das war eine der Stärken des aktuellen Ansatzes.

Diese Lösung hat jedoch einige Einschränkungen. WordPress bestimmt serverseitig, welche Bilder per Lazy Loading geladen werden sollen. Das bedeutet, dass es nichts über die Größe des Darstellungsbereichs des Nutzers weiß und auch nicht, ob Bilder anfänglich darin geladen werden. Die Korrektur verwendet daher Heuristiken zur relativen Position der Bilder im Markup, um zu schätzen, ob sie im Darstellungsbereich geladen werden. Wenn das Bild das erste hervorgehobene Bild auf der Seite oder das erste Bild im Hauptinhalt ist, wird davon ausgegangen, dass es sich „above the fold“ oder in der Nähe befindet. Es wird dann nicht per Lazy Loading geladen.

Bedingungen auf Seitenebene, z. B. die Anzahl der Wörter in der Überschrift oder die Menge des Absatztextes am Anfang des Hauptinhalts, können sich darauf auswirken, ob sich das Bild im Darstellungsbereich befindet. Es gibt auch Bedingungen auf Nutzerebene, die die Genauigkeit der Heuristik beeinträchtigen können, insbesondere die Größe des Darstellungsbereichs und die Verwendung von Ankerlinks, die die Scrollposition der Seite ändern.

Aus diesen Gründen ist es wichtig, zu beachten, dass die Korrektur nur für eine gute Leistung im allgemeinen Fall kalibriert ist und möglicherweise eine Feinabstimmung erforderlich ist, damit diese Ergebnisse auf alle realen Szenarien anwendbar sind.

Implementierung

Nachdem nun eine bessere Methode für das Lazy Loading von Bildern gefunden wurde, die zu Einsparungen bei der Bildgröße und einer schnelleren LCP-Leistung führt, stellt sich die Frage, wie Websites diese Methode nutzen können. Die wichtigste Änderung besteht darin, einen Patch an den WordPress-Core zu senden, um die experimentelle Fehlerbehebung zu implementieren. Die Anleitung im Blogpost Browser-level lazy-loading for CMSs wird ebenfalls aktualisiert, um die negativen Auswirkungen von Lazy Loading im „above the fold“-Bereich zu verdeutlichen und zu zeigen, wie CMS Heuristiken verwenden können, um dies zu vermeiden.

Da diese Best Practices für alle Webentwickler gelten, kann es auch sinnvoll sein, Lazy Loading-Antipatterns in Tools wie Lighthouse zu kennzeichnen. Wenn Sie den Fortschritt dieser Prüfung verfolgen möchten, rufen Sie den Feature Request auf GitHub auf. Bis dahin können Entwickler, die nach Instanzen von LCP-Elementen suchen, die per Lazy Loading geladen werden, ihren Felddaten detailliertere Logging-Informationen hinzufügen.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Das vorherige JavaScript-Snippet wertet das neueste LCP-Element aus und protokolliert eine Warnung, wenn es verzögert geladen wurde.

Dies verdeutlicht auch einen Nachteil der Lazy-Loading-Technik und das Potenzial für API-Verbesserungen auf Plattformebene. In Chromium gibt es beispielsweise ein offenes Problem, bei dem experimentiert wird, die ersten Bilder trotz des Attributs loading nativ sofort zu laden, ähnlich wie bei der Korrektur.

Fazit

Wenn auf Ihrer Website Lazy Loading für Bilder auf Browserebene verwendet wird, sollten Sie prüfen, wie es implementiert ist, und A/B-Tests durchführen, um die Leistungskosten besser zu verstehen. Es könnte von einem schnelleren Laden von Bildern „above the fold“ profitieren. Wenn Sie eine WordPress-Website haben, wird hoffentlich bald ein Patch im WordPress-Core veröffentlicht. Wenn Sie ein anderes CMS verwenden, sollten Sie sich der hier beschriebenen potenziellen Leistungsprobleme bewusst sein.

Das Ausprobieren relativ neuer Webplattform-APIs kann sowohl Risiken als auch Vorteile mit sich bringen. Sie werden nicht ohne Grund als innovative Funktionen bezeichnet. Wir haben jetzt einen Eindruck davon, wie kompliziert das Lazy Loading von Bildern auf Browserebene ist, aber wir sehen auch die Vorteile, die sich daraus für die Leistung ergeben.