Datengestützte Empfehlungen für das Lazy Loading von Bildern unter Berücksichtigung der Core Web Vitals.
Beim Lazy Loading wird das Herunterladen einer Ressource verzögert, bis sie benötigt wird. So werden Daten gespart und Netzwerkkonflikte für wichtige Assets reduziert. loading="lazy" wurde 2019 zum Webstandard und wird heute von den meisten gängigen Browsern für Bilder 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 ermitteln. Die Ergebnisse zeigten, dass Lazy Loading ein erstaunlich effektives Tool zur Reduzierung nicht benötigter Bildbytes ist, aber eine übermäßige Verwendung sich negativ auf die Leistung auswirken kann. Konkret zeigt diese Analyse, dass das schnellere Laden von Bildern im ursprünglichen Viewport und das großzügige Lazy-Laden des Rests das Beste aus beiden Welten bieten kann: weniger geladene Bytes 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. Die Akzeptanz steigt rapide.
Durch die Abfrage der Rohdaten im HTTP Archive-Projekt erhalten wir ein besseres Verständnis dafür, welche Arten von Websites die Akzeptanz vorantreiben: 84 % der Websites, die Lazy Loading von Bildern auf Browserebene verwenden, nutzen WordPress, 2 % ein anderes CMS und die verbleibenden 14 % kein bekanntes CMS. Diese Ergebnisse zeigen, dass WordPress die Nase vorn hat.
Auch die Akzeptanzrate ist erwähnenswert. Vor einem Jahr, im Juli 2020, machten WordPress-Websites mit Lazy Loading Zehntausende Websites im Korpus von etwa 6 Millionen aus (1 % der Gesamtzahl). Allein in WordPress wird Lazy Loading inzwischen auf über einer Million Websites (14 % der Gesamtzahl) eingesetzt.
Korrelationsleistung
Wenn Sie das HTTP-Archiv genauer untersuchen, können Sie mit dem Messwert Largest Contentful Paint (LCP) die Leistung von Seiten mit und ohne Lazy Loading von Bildern auf Browserebene vergleichen. Die LCP-Daten stammen nicht aus synthetischen Tests im Labor, sondern aus realen Nutzererfahrungen aus dem Chrome User Experience Report (CrUX). Im folgenden Diagramm wird mithilfe eines Box-and-Whisker-Diagramms die Verteilung des LCP der einzelnen Seiten im 75. Perzentil dargestellt: Die Linien stehen für die 10. und 90. Perzentile und die Boxen für die 25. und 75. Perzentile.
Die Medianseite ohne Lazy Loading hat einen LCP von 2.922 Millisekunden (75. Perzentil), verglichen mit 3.546 Millisekunden für die Medianseite mit Lazy Loading. Insgesamt haben Websites mit Lazy Loading in der Regel eine schlechtere LCP-Leistung.
Es ist wichtig zu beachten, dass dies Korrelationsergebnisse sind und nicht unbedingt darauf hinweisen, dass Lazy Loading die Ursache für die geringere Leistung ist. Hypothetisch: Wenn WordPress-Websites in der Regel etwas langsamer laufen, und angesichts ihres Anteils an der Lazy-Loading-Kohorte, könnte das den Unterschied erklären. Um diese Variabilität zu beseitigen, kann der Fokus speziell auf WordPress-Websites gelegt werden.
Leider zeigt sich bei der Aufschlüsselung von WordPress-Seiten das gleiche Muster. Anbieter, die Lazy Loading verwenden, weisen in der Regel eine geringere LCP-Leistung auf. Die durchschnittliche WordPress-Seite ohne Lazy Loading hat einen LCP-Wert für das 75. Perzentil von 3.495 Millisekunden. Der Medianwert für die Seite mit Lazy Loading liegt bei 3.768 Millisekunden.
Das beweist zwar nicht, dass Lazy Loading zu langsameren Seiten führt, aber die Verwendung von Lazy Loading geht mit einer geringeren Leistung einher. Um die Kausalitätsfrage zu beantworten, wurde ein gerätespezifischer 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 für Bilder, wie es in WordPress Core implementiert ist, zu einer langsameren LCP-Leistung und weniger Bildbyte führte. Es wurde eine WordPress-Demowebsite mit dem twentytwentyone-Design getestet. Sowohl die Archiv- als auch die Einzelseitentypen, die den Start- und Artikelseiten ähneln, wurden mit WebPageTest auf Computern und emulierten Mobilgeräten getestet. Jede Kombination von Seiten mit und ohne aktiviertem Lazy Loading wurde getestet. Jeder Test wurde neunmal ausgeführt, um den Medianwert für den LCP-Wert und die Anzahl der Bildbytes zu ermitteln.
| Reihe | Standard | deaktiviert | Abweichung vom Standard |
|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029 | 1.759 | -13 % |
| twentytwentyone-archive-mobile | 1.657 | 1.403 | -15 % |
| twentytwentyone-single-desktop | 1.655 | 1.726 | 4 % |
| twentytwentyone-single-mobile | 1.352 | 1.384 | 2 % |
In diesen Ergebnissen wird der Medianwert für den LCP in Millisekunden für Tests auf Archiv- und Einzelseiten für Computer und Mobilgeräte verglichen. Als Lazy Loading auf Archivseiten deaktiviert wurde, konnte der LCP deutlich verbessert werden. Auf einzelnen Seiten machte es jedoch weniger Unterschied.
Wenn Sie das Lazy Loading deaktivieren, werden die einzelnen Seiten anscheinend etwas schneller geladen. Der LCP-Unterschied beträgt jedoch bei Tests für Computer und Mobilgeräte weniger als eine Standardabweichung. Dies könnte auf die Varianz zurückzuführen sein und die Änderung insgesamt als neutral erachtet. Im Vergleich dazu liegt die Differenz bei Archivseiten bei etwa zwei bis drei Standardabweichungen.
| Reihe | Standard | deaktiviert | Abweichung von Standardeinstellung |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 103 % |
| twentytwentyone-archive-mobile | 172 | 378 | 120 % |
| twentytwentyone-single-desktop | 301 | 850 | 183 % |
| twentytwentyone-single-mobile | 114 | 378 | 233 % |
In diesen Ergebnissen wird die Medianzahl der Bildbytes (in KB) für jeden Test verglichen. Wie erwartet, hat das Lazy-Loading einen sehr deutlichen positiven Effekt auf die Reduzierung der Anzahl der Bildbytes. Wenn ein echter Nutzer durch die gesamte Seite scrollt, werden alle Bilder ohnehin geladen, sobald sie in den Darstellungsbereich gelangen. Diese Ergebnisse zeigen jedoch die verbesserte Leistung beim ersten Laden der Seite.
Zusammenfassend lässt sich sagen, dass die Ergebnisse des A/B-Tests mit dem Lazy Loading-Verfahren von WordPress sehr deutlich dazu beitragen, die Bildbyte auf Kosten eines verzögerten LCP zu reduzieren.
Fehlerbehebung testen
Der wichtigste Aspekt der aktuellen Lazy-Loading-Implementierung von WordPress für diesen Test ist, dass Bilder im Darstellungsbereich (above the fold) per Lazy Loading geladen werden. Im CMS-Blogpost wird dies als Muster beschrieben, das vermieden werden sollte. Die Testdaten zu dieser Zeit zeigten jedoch, dass die Auswirkungen auf die LCP minimal waren und es sich lohnte, die Implementierung im WordPress-Kern zu vereinfachen.
Auf Grundlage dieser neuen Daten wurde eine experimentelle Lösung entwickelt, mit der das Lazy-Loading von Bildern verhindert wird, die sich im sichtbaren Bereich befinden. Diese Lösung wurde unter denselben Bedingungen wie der erste A/B-Test getestet.
| Reihe | Standard | deaktiviert | korrigieren | Abweichung vom Standard | Unterschied zu „Deaktiviert“ |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029 | 1.759 | 1.749 | –14 % | -1% |
| twentytwentyone-archive-mobile | 1.657 | 1.403 | 1.352 | -18 % | -4 % |
| twentytwentyone-single-desktop | 1.655 | 1.726 | 1.676 | 1 % | -3% |
| twentytwentyone-single-mobile | 1.352 | 1.384 | 1.342 | -1% | -3 % |
Diese Ergebnisse sind viel vielversprechender. Das Lazy Loading nur für die Bilder „below the fold“ führt zu einer vollständigen Umkehrung der LCP-Regression und unter Umständen sogar zu einer leichten Verbesserung im Vergleich zum kompletten Deaktivieren von Lazy Loading. Wie könnte es schneller sein als gar kein Lazy Loading? Eine Erklärung ist, dass es zu weniger Netzwerkkonflikten mit dem LCP-Bild kommt, wenn die „below the fold“-Bilder nicht geladen werden, sodass es schneller geladen wird.
| Reihe | Standard | deaktiviert | korrigieren | Abweichung vom Standard | Unterschied zu „Deaktiviert“ |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0 % | -51 % |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0 % | -54 % |
| twentytwentyone-single-desktop | 301 | 850 | 301 | 0 % | -65 % |
| twentytwentyone-single-mobile | 114 | 378 | 114 | 0 % | -70% |
Die Anzahl der Bildbytes ändert sich durch die Korrektur nicht im Vergleich zum Standardverhalten. Das ist großartig, da dies eine der Stärken des aktuellen Ansatzes ist.
Diese Lösung hat jedoch einige Einschränkungen. WordPress bestimmt auf der Serverseite, für welche Bilder Lazy Loading verwendet wird. Das bedeutet, dass es keine Informationen zur Größe des Darstellungsbereichs des Nutzers oder dazu hat, ob Bilder zuerst darin geladen werden. Bei der Korrektur wird daher eine Heuristik zur relativen Position der Bilder im Markup verwendet, um abzuschätzen, ob die Bilder im Darstellungsbereich geladen werden. Wenn das Bild das erste vorgestellte Bild auf der Seite oder das erste Bild im Hauptinhalt ist, wird davon ausgegangen, dass es sich „above the fold“ (ohne Scrollen sichtbar) oder in der Nähe davon befindet. Es wird also nicht per Lazy Loading geladen.
Bedingungen auf Seitenebene wie die Anzahl der Wörter in der Überschrift oder die Menge an Text im ersten Absatz des Hauptinhalts können sich darauf auswirken, ob sich das Bild im Darstellungsbereich befindet. Es gibt auch Bedingungen auf Nutzerebene, die sich auf die Genauigkeit der Heuristik auswirken 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 kalibriert ist. Es kann sein, dass eine Feinabstimmung erforderlich ist, damit diese Ergebnisse auf alle realen Szenarien anwendbar sind.
Implementierung
Jetzt, da eine bessere Möglichkeit zum Lazy-Load von Bildern gefunden wurde, mit allen Bildeinsparungen und einer schnelleren LCP-Leistung, wie können Websites diese Funktion nutzen? Die Änderung mit der höchsten Priorität besteht darin, einen Patch für den WordPress-Kern einzureichen, um die experimentelle Fehlerbehebung zu implementieren. Die Anleitung im Blogpost Lazy Loading auf Browserebene für CMS wird ebenfalls aktualisiert, um die negativen Auswirkungen des Lazy Loadings „above the fold“ zu verdeutlichen und zu erläutern, wie CMS Heuristiken einsetzen können, um dies zu vermeiden.
Da diese Best Practices für alle Webentwickler gelten, kann es auch sinnvoll sein, Lazy-Loading-Antimuster in Tools wie Lighthouse zu melden. Wenn Sie den Fortschritt dieser Prüfung verfolgen möchten, sehen Sie sich den Feature-Request auf GitHub an. Bis dahin konnten Entwickler, um LCP-Elemente mit Lazy-Loading zu finden, eine detailliertere Protokollierung ihrer Felddaten 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 obige JavaScript-Snippet wertet das letzte LCP-Element aus und protokolliert eine Warnung, wenn es mit Lazy Loading geladen wurde.
Dies zeigt auch eine scharfe Kante der Lazy-Loading-Technik und das Potenzial für API-Verbesserungen auf Plattformebene. In Chromium gibt es beispielsweise ein offenes Problem, bei dem getestet wird, ob die ersten Bilder trotz des loading-Attributs nativ geladen werden können, ähnlich wie bei der Fehlerbehebung.
Fazit
Wenn auf Ihrer Website Lazy Loading von Bildern auf Browserebene verwendet wird, prüfen Sie, wie es implementiert ist, und führen Sie A/B-Tests durch, um die Leistungskosten besser zu verstehen. Es kann von einem schnelleren Laden von Bildern „above the fold“ profitieren. Wenn Sie eine WordPress-Website haben, wird es hoffentlich bald einen Patch für den WordPress-Kern geben. Wenn Sie ein anderes CMS verwenden, informieren Sie den Anbieter über die hier beschriebenen potenziellen Leistungsprobleme.
Das Testen relativ neuer Webplattform-APIs kann sowohl Risiken als auch Vorteile mit sich bringen – sie werden nicht umsonst als innovative Funktionen bezeichnet. Wir beginnen zwar, die Tücken des Lazy-Loadings von Bildern auf Browserebene zu erkennen, sehen aber auch die Vorteile, die sich damit erzielen lassen, um die Leistung zu verbessern.
Foto von Frankie Lopez auf Unsplash