Auswirkungen eines zu langen Lazy Loading auf die Leistung

Datengestützte Empfehlungen zum Lazy Loading von Bildern unter Berücksichtigung von Core Web Vitals.

Felix Arntz

Rick Viscomi

Lazy Loading ist eine Technik, mit der das Herunterladen einer Ressource so lange verzögert wird, bis sie benötigt wird. Dadurch werden Daten eingespart und Netzwerkkonflikte für kritische Assets reduziert. Er wurde 2019 zu einem Webstandard und wird heute von den meisten gängigen Browsern loading="lazy"unterstützt. Das klingt toll, aber gibt es auch mehr Lazy Loading?

In diesem Beitrag fassen wir zusammen, wie wir öffentlich verfügbare Webtransparenzdaten und Ad-hoc-A/B-Tests analysiert haben, um die Akzeptanz und Leistungsmerkmale des Lazy Loading von nativen Bildern zu verstehen. Dabei haben wir festgestellt, dass Lazy Loading ein erstaunlich effektives Tool zum Reduzieren nicht benötigter Bildbyte sein kann. Eine übermäßige Verwendung kann sich jedoch negativ auf die Leistung auswirken. Konkret zeigt unsere Analyse, dass ein höheres Laden von Bildern innerhalb des ersten Darstellungsbereichs und ein relativ großzügiges Lazy Loading für den Rest uns das Beste aus beiden Welten bieten kann: weniger Bytes geladen und die Core Web Vitals verbessert.

Adoption

Laut den neuesten Daten im HTTP-Archiv wird das Lazy Loading von nativen Bildern von 17% der Websites verwendet und die Akzeptanz nimmt rasant zu. Diese tiefgreifende Haltung ist für eine relativ neue API erstaunlich.

Durch die Abfrage der Rohdaten im HTTP-Archivprojekt können wir besser nachvollziehen, welche Arten von Websites die Akzeptanz fördern: 84% der Websites, die natives Lazy Loading von Bildern nutzen, nutzen WordPress, 2% ein anderes CMS und die restlichen 14% kein bekanntes CMS. Diese Ergebnisse verdeutlichen, inwiefern WordPress bei der Einführung von führenden Anbietern ist.

Erwähnenswert ist auch die Akzeptanzrate. Vor einem Jahr, im Juli 2020, waren WordPress-Websites, die Lazy Loading verwenden, Zehntausende Websites in einem Korpus von etwa 6 Millionen (1% der Gesamtzahl). Die Einführung von Lazy Loading allein in WordPress ist auf über 1 Million Websites angewachsen (14% der Gesamtmenge).

Korrelationsleistung

Sehen wir uns das HTTP-Archiv genauer an, können wir die Leistung von Seiten mit und ohne natives Lazy Loading von Bildern mit dem Messwert Largest Contentful Paint (LCP) vergleichen. Die LCP-Daten stammen nicht aus synthetischen Tests im Labor, sondern stammen aus dem Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX). Im folgenden Diagramm wird ein Box-and-Whisker-Diagramm verwendet, um die Verteilungen des 75. Perzentils des LCP-Werts jeder Seite zu visualisieren: Die Linien stellen das 10. und 90. Perzentil und die Boxen das 25. und 75. Perzentil dar.

Der Medianwert für die Seite ohne Lazy Loading hat einen LCP-Wert von 2.922 ms im 75. Perzentil. Der Medianwert der Seite mit Lazy Loading liegt bei 3.546 ms. Insgesamt haben Websites mit Lazy Loading in der Regel eine schlechtere LCP-Leistung.

Es ist wichtig anzumerken, dass dies Korrelationsergebnisse sind und nicht unbedingt auf Lazy Loading als Ursache für die geringere Leistung hindeuten. Wenn WordPress-Websites tendenziell etwas langsamer sind und angesichts ihres Anteils der Lazy Loading-Kohorte den Unterschied erklären, könnte das hypothetisch der Fall sein. Versuchen wir also, diese Schwankungen zu vermeiden, indem wir uns nur WordPress-Websites ansehen.

Leider zeigt sich dasselbe Muster, wenn wir die WordPress-Seiten aufschlüsseln. Bei WordPress-Seiten, die Lazy Loading verwenden, ist der LCP in der Regel langsamer. Der Medianwert für die WordPress-Seite ohne Lazy Loading hat einen LCP-Wert im 75. Perzentil von 3.495 ms. Der Medianwert für die Medianseite mit Lazy Loading liegt bei 3.768 ms.

Dies beweist immer noch nicht, dass Lazy Loading verursacht, dass Seiten langsamer werden. Die Verwendung dieses Tools ist jedoch mit einer geringeren Leistung einhergehen. Um die Kausalitätsfrage zu beantworten, richten wir einen Lab-basierten A/B-Test ein.

Kausale Leistung

Ziel des A/B-Tests war es, die Hypothese zu beweisen oder zu widerlegen, dass Lazy Loading von nativen Bildern im WordPress Core zu einer geringeren LCP-Leistung und weniger Bildbyte führt. Wir haben eine WordPress-Demowebsite mit dem Design twentytwentyone getestet. Wir haben mit WebPageTest sowohl Archiv- als auch Einzelseitentypen, wie die Startseite und Artikelseiten, auf Computern und emulierten Mobilgeräten getestet. Wir haben jede Kombination von Seiten mit und ohne aktiviertes Lazy Loading getestet und jeden Test neunmal durchgeführt, um den Medianwert für den LCP-Wert und die Anzahl der Bildbyte zu ermitteln.

In den obigen Ergebnissen wird der Medianwert des LCP in Millisekunden für Tests mit Archivierungs- und Einzelseiten für Computer und Mobilgeräte verglichen. Als wir Lazy Loading auf Archivseiten deaktivieren, konnte der LCP sich deutlich verbessern. Auf einzelnen Seiten war der Unterschied jedoch neutraler.

Beachten Sie, dass die Auswirkungen der Deaktivierung von Lazy Loading die einzelnen Seiten tatsächlich etwas schneller machen. Der LCP-Unterschied ist jedoch sowohl bei Desktop- als auch bei mobilen Tests weniger als eine Standardabweichung. Daher ordnen wir dies der Abweichung zu und betrachten die Änderung insgesamt als neutral. Im Vergleich dazu beträgt der Unterschied bei Archivseiten zwei bis drei Standardabweichungen.

Bei den obigen Ergebnissen wird der Medianwert der Bildbyte (in KB) für jeden Test verglichen. Wie erwartet hat Lazy Loading einen sehr deutlich positiven Effekt auf die Reduzierung der Bildbyte. Wenn ein echter Nutzer die gesamte Seite nach unten scrollt, werden alle Bilder trotzdem geladen, während sie in den Darstellungsbereich gelangen. Diese Ergebnisse zeigen jedoch die verbesserte Leistung beim ersten Seitenaufbau.

Zusammenfassend lässt sich sagen, dass das von WordPress verwendete Lazy-Loading-Verfahren zur Reduzierung der Bildbyte sehr hilfreich ist, allerdings auf Kosten eines verzögerten LCP.

Fehlerbehebung wird getestet

Bevor wir uns damit befassen, wie die Korrektur implementiert wurde, sehen wir uns heute an, wie Lazy Loading in WordPress funktioniert. Das Wichtigste an der aktuellen Implementierung ist, dass Bilder per Lazy Loading „above the fold“ (ohne Scrollen sichtbar) (innerhalb des Darstellungsbereichs) geladen werden. Im CMS-Blogpost wird dies als zu vermeidendes Muster bekannt gegeben. Die damaligen Testdaten zeigten jedoch, dass der Effekt auf den LCP minimal war und sich eine Vereinfachung der Implementierung im WordPress Core lohnen würde.

Basierend auf diesen neuen Daten haben wir eine experimentelle Korrektur erstellt, mit der Lazy Loading von Bildern, die ohne Scrollen sichtbar sind, vermieden wird. Wir haben dies unter denselben Bedingungen wie beim ersten A/B-Test getestet.

Diese Ergebnisse sind viel vielversprechender. Lazy Loading nur der Bilder „below the fold“ (mit Scrollen sichtbar) führt zu einer vollständigen Umkehr der LCP-Regression und möglicherweise sogar zu einer leichten Verbesserung gegenüber der vollständigen Deaktivierung des LCP. Wie könnte das schneller sein als überhaupt kein Lazy Loading? Eine Erklärung ist, dass es weniger Netzwerkkonflikte mit dem LCP-Bild gibt, wenn Bilder „below the fold“ (mit Scrollen sichtbar) nicht geladen werden, wodurch es schneller geladen wird.

Bezüglich der Bildbyte hat sich bei der Korrektur im Vergleich zum Standardverhalten absolut keine Änderung ergeben. Das ist großartig, denn dies war eine der Stärken des aktuellen Ansatzes.

Bei dieser Korrektur gibt es einige Nachteile. WordPress bestimmt serverseitig, für welche Bilder das Lazy Loading verwendet wird. Das bedeutet, dass keine Informationen über die Größe des Darstellungsbereichs des Nutzers oder darüber vorliegen, ob darin Bilder zuerst geladen werden. Bei der Korrektur wird also eine Heuristik zur relativen Position der Bilder im Markup verwendet, um zu erraten, ob sie im Darstellungsbereich zu sehen sind. Genauer gesagt: Wenn das Bild das erste hervorgehobene Bild auf der Seite oder das erste Bild im Hauptinhalt ist, wird davon ausgegangen, dass es „above the fold“ (oder nah daran) ist. Es wird kein Lazy Loading verwendet. Bedingungen auf Seitenebene wie 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 anzuerkennen, dass die Korrektur nur so kalibriert ist, dass im allgemeinen Fall eine gute Leistung erzielt wird. Möglicherweise ist eine Feinabstimmung erforderlich, um diese Ergebnisse auf alle realen Szenarien anzuwenden.

Einführung

Nachdem wir nun eine bessere Methode für das Lazy Loading von Bildern, die Einsparungen bei den Bildern und die schnellere LCP-Leistung kennen, wie können wir nun Websites dazu bringen, diese Funktion zu nutzen? Die höchste Prioritätsänderung besteht darin, einen Patch an WordPress Core zu senden, um die experimentelle Korrektur zu implementieren. Außerdem werden wir die Richtlinien im Blogpost Lazy Loading auf Browserebene für CMSs aktualisieren, um die negativen Auswirkungen von Lazy Loading ohne Scrollen zu verdeutlichen und zu verdeutlichen, wie CMS mithilfe von Heuristiken dies vermeiden können.

Da diese Best Practices für alle Webentwickler gelten, kann es sich lohnen, Lazy Loading-Anti-Patterns in Tools wie Lighthouse zu melden. Über die Funktionsanfrage auf GitHub können Sie den Fortschritt dieser Prüfung verfolgen. Bis dahin konnten Entwickler Instanzen von Lazy-Loading-Instanzen von LCP-Elementen durch ein detaillierteres Logging ihrer Felddaten finden.

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 JavaScript-Snippet oben wertet das neueste LCP-Element aus und gibt eine Warnung aus, wenn es Lazy Loading war.

Dies verdeutlicht auch die Schärfe der Lazy Loading-Technik und die Möglichkeit für API-Verbesserungen auf Plattformebene. Beispielsweise gibt es ein offenes Problem in Chromium, bei dem experimentiert werden kann, bei dem die ersten Bilder nativ geladen werden, ähnlich wie bei der Fehlerbehebung, obwohl das Attribut loading verwendet wurde.

Zusammenfassung

Wenn Sie für Ihre Website natives Lazy Loading von Bildern verwenden, prüfen Sie, wie es implementiert ist, und führen Sie A/B-Tests durch, um die Leistungskosten besser zu verstehen. Es kann von Vorteil sein, wenn Bilder schneller geladen werden, die ohne Scrollen sichtbar sind. Wenn ihr eine WordPress-Website habt, wird es hoffentlich bald ein Patch-Landing in WordPress Core geben. Wenn du ein anderes CMS verwendest, solltest du darauf achten, dass die hier beschriebenen potenziellen Leistungsprobleme bekannt sind.

Das Testen relativ neuer Webplattform-APIs kann sowohl Risiken als auch Vorteile mit sich bringen – aus guten Gründen werden sie als hochmoderne Funktionen bezeichnet. Während wir langsam ein Gefühl für die Schwierigkeit des Lazy Loading von nativen Bildern bekommen, erkennen wir auch die Vorteile, wie man es einsetzen kann, um eine bessere Leistung zu erzielen.

Foto von Frankie Lopez auf Unsplash