Datengestützte Tipps zum Lazy Loading von Bildern mit Core Web Vitals
Lazy Loading ist eine Technik, bei der das Herunterladen einer Ressource so lange zurückgestellt wird, bis sie benötigt wird, um Daten zu sparen und Netzwerkkonflikte bei wichtigen Assets zu reduzieren. Sie wurde 2019 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 Transparenzdaten und Ad-hoc-A/B-Tests analysiert wurden, um die Akzeptanz und die Leistungsmerkmale des Lazy Loadings von Bildern auf Browserebene zu verstehen. 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 wir durch ein schnelleres Laden von Bildern innerhalb des ersten Darstellungsbereichs – und den Rest mit großzügigem Lazy Loading – das Beste aus beiden Welten erhalten: weniger Byte geladen und die Core Web Vitals verbessert werden.
Adoption
Aktuellen Daten im HTTP-Archiv zufolge wird von 29% der Websites integriertes Lazy Loading für Bilder verwendet und die Akzeptanz steigt rasant.
![Kreisdiagramm, das zeigt, wie WordPress 84,1% der Lazy-Loading-Einführung, 2,3 % andere CMS und 13,5 % Nicht-CMS-Lösungen ausmacht.](https://web.dev/static/articles/lcp-lazy-loading/image/pie-chart-showing-wordpre-4b9f571267fae.png?authuser=6&hl=de)
Die Abfrage der Rohdaten im HTTP-Archiv-Projekt gibt uns Aufschluss darüber, welche Arten von Websites die Akzeptanz steigern: 84% der Websites, die Lazy Loading für Bilder auf Browserebene verwenden, verwenden WordPress, 2% nutzen ein anderes CMS und die restlichen 14% nutzen kein bekanntes CMS. Diese Ergebnisse verdeutlichen, auf welche Weise WordPress bei der Einführung des Tools eine entscheidende Rolle spielt.
![Zeitreihendiagramm für die Einführung von Lazy Loading, wobei WordPress im Vergleich zu anderen CMS und Nicht-CMS die vorherrschende Rolle spielt. Der Anteil ist ähnlich wie im vorherigen Diagramm. Zwischen Juli 2020 und Juni 2021 ist die Akzeptanzrate von 1% auf 17% gestiegen.](https://web.dev/static/articles/lcp-lazy-loading/image/timeseries-chart-lazy-lo-bb9c26a3fb041.png?authuser=6&hl=de)
Erwähnenswert ist auch die Akzeptanzrate. Vor einem Jahr, im Juli 2020, umfassten WordPress-Websites mit Lazy Loading Zehntausende Websites in einem Korpus von etwa 6 Millionen (1% der Gesamtzahl). Allein bei WordPress ist Lazy Loading bereits auf über 1 Million Websites (14% aller Websites) angestiegen.
Korrelationsleistung
Wenn Sie sich näher mit dem HTTP-Archiv befassen, können Sie mit dem Messwert LCP (Largest Contentful Paint) vergleichen, wie Seiten mit und ohne Lazy Loading für Bilder auf Browserebene abschneiden. Die LCP-Daten stammen nicht aus synthetischen Tests im Labor, sondern aus realen Nutzererfahrungen aus dem Chrome User Experience Report (CrUX). Das folgende Diagramm verwendet ein Box-and-Whisker-Diagramm, um die Verteilungen des 75. Perzentils für LCP für jede Seite zu visualisieren: Die Linien stellen das 10. und 90. Perzentil und die Boxen das 25. und 75. Perzentil dar.
![Box- und Whisker-Diagramm mit den 10., 25., 75. und 90. Perzentilen für Seiten, die Lazy Loading für Bilder auf Browserebene verwenden oder nicht. Im Vergleich dazu ist die LCP-Verteilung bei Seiten, auf denen diese Funktion nicht verwendet wird, schneller als bei Seiten, auf denen dies der Fall ist.](https://web.dev/static/articles/lcp-lazy-loading/image/box-whisker-chart-showin-fab6befef771c.png?authuser=6&hl=de)
Der Medianwert für die Seite ohne Lazy Loading hat einen LCP-Wert für das 75. Perzentil von 2.922 Millisekunden. Bei Seiten mit Lazy Loading liegt der Medianwert bei 3.546 Millisekunden. Insgesamt weisen Websites, die Lazy Loading verwenden, in der Regel eine schlechtere LCP-Leistung auf.
Es ist wichtig anzumerken, dass es sich hierbei um Korrelationsergebnisse handelt, die nicht unbedingt auf Lazy Loading als Ursache für die geringere Leistung hindeuten. 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 Schwankungen zu vermeiden, kann der Fokus auf WordPress-Websites eingegrenzt werden.
![Box- und Whisker-Diagramm mit den 10., 25., 75. und 90. Perzentilen für WordPress-Seiten, die Lazy Loading für Bilder auf Browserebene verwenden oder nicht. Im Vergleich dazu ist die LCP-Verteilung bei Seiten, auf denen sie nicht verwendet wird, schneller als bei Seiten, die dies tun, ähnlich wie im vorherigen Diagramm.](https://web.dev/static/articles/lcp-lazy-loading/image/box-whisker-chart-showin-c37339441feb8.png?authuser=6&hl=de)
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.
Dies ist zwar immer noch nicht bewiesen, dass Lazy Loading verursacht, dass Seiten langsamer werden. Wenn Sie Lazy Loading verwenden, wirkt sich dies jedoch auf eine geringere Leistung aus. Um die Kausalitätsfrage 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 für Bilder, wie es in WordPress Core implementiert ist, zu einer langsameren LCP-Leistung und weniger Bildbyte führte. Die verwendete Methode bestand darin, eine WordPress-Demowebsite mit dem Thema twentytwentyone zu testen. Sowohl der Archiv- als auch der Einzelseitentyp, also die Startseiten- und Artikelseiten, wurden mit WebPageTest auf Desktop-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 Bildbyte zu ermitteln.
Reihe | default | deaktiviert | Unterschied von Standardeinstellung |
---|---|---|---|
twentytwentyone-archive-desktop | 2.029 | 1.759 | -13% |
zwanzig-ytwentyone-archiv-mobil | 1.657 | 1.403 | -15 % |
twentytwentyone-single-desktop | 1.655 | 1.726 | 4 % |
zwanzig-ytwentyone-ein-mobil | 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 er jedoch keinen großen Unterschied.
Durch das Deaktivieren des Lazy Loadings werden die einzelnen Seiten etwas schneller geladen. Der LCP-Unterschied beträgt jedoch bei Tests für Desktop-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 der Unterschied für Archivseiten näher bei zwei bis drei Standardabweichungen.
Reihe | default | deaktiviert | Unterschied von Standardeinstellung |
---|---|---|---|
twentytwentyone-archive-desktop | 577 | 1173 | 103 % |
zwanzig-ytwentyone-archiv-mobil | 172 | 378 | 120 % |
twentytwentyone-single-desktop | 301 | 850 | 183% |
zwanzig-ytwentyone-ein-mobil | 114 | 378 | 233% |
In diesen Ergebnissen wird der Medianwert der Bildbyte (in KB) für jeden Test verglichen. Wie erwartet hat Lazy Loading einen sehr deutlichen positiven Effekt auf die Reduzierung der Bildbyte. Wenn ein echter Nutzer durch die gesamte Seite scrollt, würden alle Bilder trotzdem geladen, wenn sie den Darstellungsbereich erreichen. Diese Ergebnisse zeigen jedoch die verbesserte Leistung beim anfänglichen Seitenaufbau.
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 innerhalb des Darstellungsbereichs above the fold (ohne Scrollen sichtbar) geladen werden. Im CMS-Blogpost wird dies als Muster bestätigt, aber experimentelle Daten zu diesem Zeitpunkt deuteten darauf hin, dass die Auswirkungen auf den LCP minimal waren und es sich lohnt, die Implementierung in WordPress Core zu vereinfachen.
Aufgrund dieser neuen Daten wurde eine experimentelle Korrektur entwickelt, um Lazy Loading für Bilder zu vermeiden, die ohne Scrollen sichtbar sind. Die Korrektur wurde unter denselben Bedingungen wie der erste A/B-Test getestet.
Reihe | default | deaktiviert | fix | Unterschied von Standardeinstellung | Unterschied zu „Deaktiviert“ |
---|---|---|---|---|---|
twentytwentyone-archive-desktop | 2.029 | 1.759 | 1.749 | -14% | -1% |
zwanzig-ytwentyone-archiv-mobil | 1.657 | 1.403 | 1.352 | -18 % | -4 % |
twentytwentyone-single-desktop | 1.655 | 1.726 | 1.676 | 1 % | -3% |
zwanzig-ytwentyone-ein-mobil | 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 gegenüber dem kompletten Deaktivieren von Lazy Loading. Wie könnte es schneller sein als gar kein Lazy Loading? Eine Erklärung besteht darin, dass es zu weniger Netzwerkkonflikten mit dem LCP-Bild kommt, wenn keine „below the fold“-Bilder geladen werden. Das führt dazu, dass das Bild schneller geladen wird.
Reihe | default | deaktiviert | fix | Unterschied von Standardeinstellung | Unterschied zu „Deaktiviert“ |
---|---|---|---|---|---|
twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0 % | -51% |
zwanzig-ytwentyone-archiv-mobil | 172 | 378 | 172 | 0 % | -54% |
twentytwentyone-single-desktop | 301 | 850 | 301 | 0 % | -65% |
zwanzig-ytwentyone-ein-mobil | 114 | 378 | 114 | 0 % | -70% |
In Bezug auf die Bildbyte hat die Korrektur im Vergleich zum Standardverhalten keinerlei Änderungen. Das ist großartig, da dies eine der Stärken des aktuellen Ansatzes ist.
Diese Lösung bringt einige Nachteile mit sich. 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 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“ (ohne Scrollen sichtbar) oder in der Nähe des Bildes befindet und kein Lazy Loading erforderlich ist.
Bedingungen auf Seitenebene, wie die Anzahl der Wörter in der Überschrift oder die Menge des Absatztexts am Anfang des Hauptinhalts, können beeinflussen, 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 wissen, dass die Korrektur nur so kalibriert ist, dass im Allgemeinen eine gute Leistung erzielt wird, und dass eventuell Feinabstimmungen erforderlich sind, damit diese Ergebnisse auf alle realen Szenarien anwendbar sind.
Implementierung (:#Implementierung)
Nachdem wir nun einen besseren Weg für das Lazy Loading von Bildern, alle Bildeinsparungen und eine höhere LCP-Leistung gefunden haben, wie können Websites dieses Tool einsetzen? Die höchste Priorität besteht darin, einen Patch an WordPress Core zu senden, um die experimentelle Fehlerkorrektur 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, lohnt es sich möglicherweise, auch Lazy Loading-Anti-Patterns in Tools wie Lighthouse zu melden. Wenn Sie den Fortschritt dieser Prüfung verfolgen möchten, lesen Sie die Funktionsanfrage auf GitHub. 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 vorherige JavaScript-Snippet wertet das letzte LCP-Element aus und protokolliert eine Warnung, wenn es Lazy-Loading-Technologie vorsieht.
Dies unterstreicht auch die Grenzen des Lazy-Loading-Verfahrens und das Potenzial für API-Verbesserungen auf Plattformebene. Es gibt beispielsweise ein offenes Problem in Chromium, mit dem das native Laden der ersten Bilder getestet wird, ähnlich wie bei der Fehlerbehebung, obwohl das Attribut loading
verwendet wird.
Fazit
Wenn Sie für Ihre Website Lazy Loading auf Browserebene verwenden, prüfen Sie die Implementierung und führen Sie A/B-Tests durch, um die Leistungskosten besser zu verstehen. Es kann von Vorteil sein, wenn Bilder „above the fold“ (ohne Scrollen sichtbar) geladen werden. Wenn Sie eine WordPress-Website haben, wird es hoffentlich bald ein Patch in WordPress Core geben. Falls Sie ein anderes CMS verwenden, achten Sie darauf, dass es sich der hier beschriebenen potenziellen Leistungsprobleme bewusst ist.
Das Ausprobieren relativ neuer Webplattform-APIs kann sowohl Risiken als auch Vorteile bergen, da sie aus gutem Grund als hochmoderne Funktionen bezeichnet werden. Das Lazy Loading von Bildern auf Browserebene ist zunächst unübersichtlich. Wir sehen aber auch, wie man damit eine bessere Leistung erzielen kann.
Foto von Frankie Lopez bei Unsplash