Datengestützte Tipps zum Lazy Loading von Bildern mit 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 wir durch ein schnelleres Laden von Bildern innerhalb des ersten Darstellungsbereichs – und den Rest mit großzügigem Lazy Loading – das Beste aus beiden Bereichen erhalten: weniger Byte geladen und die Core Web Vitals verbessert werden.
Akzeptanz
Aktuellen Daten im HTTP-Archiv zufolge wird von 29% der Websites integriertes Lazy Loading für Bilder verwendet und die Akzeptanz steigt rasant.
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 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). 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 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 Variabilität zu beseitigen, kann der Fokus speziell auf WordPress-Websites gelegt werden.
Leider zeigt sich dasselbe Muster, wenn Sie WordPress-Seiten aufschlüsseln. Seiten mit Lazy Loading haben in der Regel eine langsamere LCP-Leistung. Die mediane WordPress-Seite ohne Lazy Loading hat eine LCP von 3.495 Millisekunden (75. Perzentil), verglichen mit 3.768 Millisekunden für die mediane Seite mit Lazy Loading.
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 der Typ "Archiv" als auch der Typ "Einzelseite", also die Startseiten- und Artikelseiten, wurden mit WebPageTest auf Desktop- und emulierten Mobilgeräten getestet. Es wurden alle Kombinationen von Seiten mit und ohne aktiviertem Lazy Loading getestet. Jeder Test wurde neunmal ausgeführt, um den Medianwert für die LCP und die Anzahl der Bild-Byte 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 Median der LCP in Millisekunden für Tests auf Archiv- und einzelnen Seiten für Computer und Mobilgeräte verglichen. Durch das Deaktivieren des Lazy-Loadings auf Archivseiten konnte der LCP-Wert 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 Unterschied beim LCP liegt jedoch sowohl bei den Desktop- als auch bei den mobilen Tests unter einer Standardabweichung. Daher kann er auf eine Varianz zurückgeführt werden und die Änderung insgesamt als neutral betrachtet werden. 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 von WordPress verwendete Lazy-Loading-Technologie die Anzahl der Bild-Byte deutlich reduziert, was jedoch zu einer verzögerten LCP führt.
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 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.
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 von Standardeinstellung | 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 vielversprechender. Wenn Sie nur die Bilder unterhalb des Folds per Lazy Loading laden, wird die LCP-Rückschritt vollständig rückgängig gemacht und es kann sogar zu einer leichten Verbesserung im Vergleich zum vollständigen Deaktivieren des Lazy Loadings kommen. 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 von Standardeinstellung | 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% |
In Bezug auf die Bildbyte hat die Korrektur im Vergleich zum Standardverhalten keinerlei Änderungen. Das ist großartig, denn das war eine der Stärken des aktuellen Ansatzes.
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. Daher wird bei der Fehlerbehebung anhand von Heuristiken über die relative Position der Bilder im Markup geschätzt, ob sie 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 Heuristiken 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
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 Informationen im Blogpost Lazy Loading auf Browserebene für CMS werden ebenfalls aktualisiert, um die negativen Auswirkungen des Lazy Loadings im Above-the-Fold-Bereich zu verdeutlichen und zu erläutern, wie CMS-Hersteller Heuristiken verwenden 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 können Entwickler beispielsweise detailliertere Protokolle zu ihren Felddaten hinzufügen, um LCP-Elemente zu finden, die mit Lazy Loading geladen werden.
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 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 einem schnelleren Laden von Bildern „above the fold“ profitieren. Wenn Sie eine WordPress-Website haben, wird es hoffentlich bald ein Patch in WordPress Core geben. Wenn Sie ein anderes CMS verwenden, informieren Sie den Anbieter über die hier beschriebenen potenziellen Leistungsprobleme.
Das Ausprobieren relativ neuer Webplattform-APIs kann sowohl Risiken als auch Vorteile bergen, da sie aus gutem Grund als hochmoderne Funktionen bezeichnet werden. 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 bei Unsplash