Der vollständige Leitfaden zum Lazy Loading von Bildern

Bilder sind entscheidend. Ob Marketingbanner, Produktbilder oder Logos – eine Website ohne Bilder ist unvorstellbar. Leider sind Bilder oft schwere Dateien, die sie zum größten Einzelposten für überladene Seiten machen. Laut dem State of Images Report von HTTP Archive beträgt die durchschnittliche Seitengröße auf Desktops 1511 KB, und Bilder machen fast 45 % (650 KB) dieser Gesamtsumme aus.

Das bedeutet jedoch nicht, dass wir auf Bilder verzichten können. Sie sind zu wichtig für das allgemeine Benutzererlebnis. Stattdessen müssen wir dafür sorgen, dass unsere Webseiten mit ihnen wirklich schnell laden. In diesem Leitfaden behandeln wir alle Aspekte des Lazy Loadings von Bildern, eine Technik, die hilft, die Ladezeit einer Webseite zu verbessern, indem das Laden von Bildern verzögert wird, bis sie benötigt werden.

Bevor wir richtig einsteigen, hier ein Beispielvideo, das das Konzept demonstriert. Kurz gesagt: Eine graue Platzhalterbox wird auf der Seite gerendert, bis sie in den Ansichtsbereich scrollt – an diesem Punkt wird das eigentliche Bild anstelle der Box geladen.

Kapitel 1: Was ist Lazy Loading?

Wir assoziieren das Wort „faul“ oft damit, Arbeit so lange wie möglich zu vermeiden, oder mit dem reinen Wunsch, gar nichts zu tun.

Ähnlich verzögert Lazy Loading das Laden von Ressourcen auf der Seite, solange sie nicht benötigt werden. Anstatt sie sofort zu laden, was normalerweise geschieht, erlauben wir ihnen, später zu laden.

Lazy Loading ist eine Reihe von Techniken in der Web- und Anwendungsentwicklung, die das Laden von Ressourcen auf einer Seite auf einen späteren Zeitpunkt verschieben – wenn diese Ressourcen tatsächlich benötigt werden, anstatt sie im Voraus zu laden. Diese Techniken helfen, die Leistung zu verbessern, die Ressourcen des Geräts besser zu nutzen und damit verbundene Kosten zu senken.

Die Technik des Lazy Loadings kann auf nahezu jede Ressource einer Seite angewendet werden. Zum Beispiel kann sogar eine JavaScript-Datei zurückgehalten werden, wenn es nicht ratsam ist, sie sofort zu laden. Das Gleiche gilt für ein Bild – laden Sie es, wenn wir es brauchen.

In diesem Leitfaden konzentrieren wir uns auf das Lazy Loading von Bildern, aber es ist gut zu wissen, dass es auch auf andere Assets angewendet werden kann.

Kapitel 2: Warum überhaupt Lazy Load?

Wenn der Benutzer niemals zu dem Punkt der Seite scrollt, der das Bild enthält, dann wird der Benutzer dieses Bild niemals sehen. Es wird auch nie geladen, weil es, siehe da, nie benötigt wurde.

Sie sehen vielleicht schon, wie dies sowohl Ihnen als auch dem Benutzer zugute kommt. Hier sind zwei der Vorteile, die wir mit Lazy Loading erzielen.

Leistungssteigerung

Der offensichtliche Vorteil ist, dass wir kleinere Webseiten erhalten, die schneller laden. Lazy Loading reduziert die Anzahl der Bilder, die im Voraus auf einer Seite geladen werden müssen. Weniger Bildanfragen bedeuten weniger herunterzuladende Bytes. Und weniger herunterzuladende Bytes bedeuten, dass die Seite schneller gerendert wird, als wenn diese Bytes und Anfragen gestellt würden.

Dies stellt sicher, dass jedes Gerät in jedem Netzwerk die verbleibenden Ressourcen viel schneller herunterladen und verarbeiten kann. Daher wird die Zeit von der Anfrage bis zum Rendern kürzer und die Seite wird viel früher nutzbar. Ein Win-Win!

Kostensenkung

Der zweite Vorteil ist für Sie als Webseitenadministrator. Cloud-Hosting-Dienste wie Content Delivery Networks (CDNs) oder Webserver oder Speicher liefern Bilder (oder beliebige Assets) zu Kosten, die auf der Anzahl der übertragenen Bytes basieren. Ein Lazy-Loaded-Bild wird möglicherweise nie geladen, wenn der Benutzer es nie erreicht. Somit können Sie die auf der Seite ausgelieferten Gesamtbytes reduzieren und letztendlich ein paar Cent sparen. Dies gilt insbesondere für Benutzer, die eine Seite sofort verlassen oder nur mit dem oberen Teil des Inhalts interagieren.

Die Reduzierung der von Ihrem Liefernetzwerk oder Server übertragenen Bytes reduziert die Lieferkosten. Dies wird deutlicher, wenn wir Lazy Loading in den folgenden Abschnitten untersuchen.

Wie viel werden Sie sparen? Sie können herausfinden, welche Bilder für Lazy Loading in Frage kommen und wie viele Bytes Sie beim anfänglichen Seitenaufruf sparen können, indem Sie das Google Lighthouse Audit Tool verwenden. Dieses hat einen Abschnitt für Offscreen Images. Sie können auch den Website-Analyzer von ImageKit verwenden, um zu identifizieren, ob Ihre Website Lazy Loading verwendet oder nicht, abgesehen von anderen wichtigen bildbezogenen Optimierungen auf Ihrer Seite.

Lazy Loading ist nicht nur für eine gute Leistung entscheidend, sondern auch für die Bereitstellung einer guten Benutzererfahrung. Da die Kombination von Leistung und Benutzererfahrung mit Lazy Loading wichtig und herausfordernd ist, werden wir dieses Thema in diesem Leitfaden weiterhin im Detail behandeln, nachdem wir verschiedene Möglichkeiten des Lazy Loadings von Bildern betrachtet haben.

Kapitel 3: Lazy Loading Techniken für Bilder

Es gibt zwei gängige Methoden, mit denen wir Bilder auf eine Seite laden: das <img>-Tag und die CSS-Eigenschaft background-image. Wir betrachten zuerst die gebräuchlichere der beiden, das <img>-Tag, und gehen dann zu CSS-Hintergrundbildern über.

Lazy Loading von Bildern in einem Image-Tag

Beginnen wir mit der typischen HTML-Auszeichnung für ein Bild.

<img src="/path/to/some/image.jpg">

Die Auszeichnung für Lazy Loading von Bildern ist ziemlich ähnlich.

Schritt eins ist die Verhinderung des sofortigen Ladens des Bildes. Der Browser verwendet das src-Attribut des Tags, um das Laden des Bildes auszulösen. Es spielt keine Rolle, ob es das erste oder das tausendste Bild in Ihrem HTML ist. Wenn der Browser das src-Attribut erhält, löst er den Download des Bildes aus, unabhängig davon, ob es sich im aktuellen Ansichtsbereich befindet oder nicht.

Um das Laden zu verzögern, legen Sie die Bild-URL in ein anderes Attribut als src. Nehmen wir an, wir geben die Bild-URL im data-src-Attribut des Bild-Tags an. Nun ist src leer und der Browser löst das Laden des Bildes nicht aus.

<img data-src="https://ik.imagekit.io/demo/default-image.jpg">

Nachdem wir nun verhindern, dass das Bild geladen wird, müssen wir dem Browser mitteilen, wann er es laden soll. Sonst passiert es nie. Dazu prüfen wir, sobald das Bild (d. h. sein Platzhalter) in den Viewport scrollt, und lösen das Laden aus.

Es gibt zwei Möglichkeiten, zu prüfen, wann ein Bild in den Viewport gelangt. Betrachten wir beide mit funktionierenden Codebeispielen.

Methode 1: Auslösen des Bildladens mit JavaScript-Events

Diese Technik verwendet Event Listener für die Events scroll, resize und orientationChange im Browser. Das Scroll-Event ist ziemlich eindeutig, da es beobachtet, wo sich der Benutzer beim Scrollen auf einer Seite befindet. Die Events resize und orientationChange sind ebenso wichtig. Das resize-Event tritt auf, wenn sich die Größe des Browserfensters ändert, während orientationChange ausgelöst wird, wenn das Gerät von Querformat zu Hochformat oder umgekehrt gedreht wird.

Wir können diese drei Events verwenden, um eine Änderung des Bildschirms zu erkennen, die Anzahl der auf dem Bildschirm sichtbaren Bilder zu bestimmen und sie entsprechend zu laden.

Wenn eines dieser Events auftritt, finden wir alle auf der Seite verzögerten Bilder und prüfen, welche davon sich gerade im Viewport befinden. Dies geschieht anhand des oberen Offsets des Bildes, der aktuellen Position des Dokuments von oben und der Fensterhöhe. Wenn ein Bild in den Viewport gelangt ist, nehmen wir die URL aus dem data-src-Attribut und verschieben sie in das src-Attribut, woraufhin das Bild geladen wird.

Beachten Sie, dass wir JavaScript bitten, Bilder auszuwählen, die eine lazy-Klasse enthalten. Sobald das Bild geladen ist, entfernen wir die Klasse, da sie kein weiteres Event auslösen muss. Und wenn alle Bilder geladen sind, entfernen wir auch die Event Listener.

Wenn wir scrollen, wird das Scroll-Event mehrmals schnell ausgelöst. Daher fügen wir aus Leistungsgründen einen kleinen Timeout zu unserem Skript hinzu, der die Ausführung der Lazy-Loading-Funktion drosselt, damit diese nicht andere Aufgaben blockiert, die im selben Thread im Browser laufen.

Hier ist ein funktionierendes Beispiel für diesen Ansatz.

Beachten Sie, dass die ersten drei Bilder in diesem Beispiel sofort geladen werden. Die URL ist direkt im src-Attribut anstelle des data-src-Attributs vorhanden. Dies ist für eine gute Benutzererfahrung unerlässlich. Da sich diese Bilder am oberen Rand der Seite befinden, sollten sie so schnell wie möglich sichtbar gemacht werden. Es ist nicht nötig, auf JavaScript zu warten, um sie zu laden.

Methode 2: Auslösen des Bildladens mit der Intersection Observer API

Die Intersection Observer API ist relativ neu. Sie vereinfacht die Erkennung, wenn ein Element in den Viewport gelangt, und das Ausführen einer Aktion, wenn dies geschieht. In der vorherigen Methode mussten wir Events binden, Leistung berücksichtigen und eine Methode implementieren, um zu berechnen, ob das Element im Viewport war oder nicht. Die Intersection Observer API beseitigt diesen gesamten Overhead, indem sie die Mathematik vermeidet und sofort eine großartige Leistung liefert.

Unten ist ein Beispiel für die Verwendung der API zum Lazy Loading von Bildern. Wir fügen den Observer für alle zu lazy loadenden Bilder hinzu. Sobald die API erkennt, dass das Element mit der Eigenschaft isIntersecting in den Viewport gelangt ist, nehmen wir die URL aus dem data-src-Attribut und verschieben sie in das src-Attribut, damit der Browser das Bild lädt. Sobald dies geschehen ist, entfernen wir die lazy-Klasse vom Bild und auch den Observer von diesem Bild.

Wenn Sie die Ladezeiten der Bilder für die beiden Methoden (Event Listener vs. Intersection Observer) vergleichen, werden Sie feststellen, dass Bilder mit der Intersection Observer API viel schneller geladen werden und die Aktion auch schneller ausgelöst wird – und dennoch erscheint die Seite überhaupt nicht träge, selbst während des Scrollens. Bei der Methode mit Event Listenern mussten wir einen Timeout hinzufügen, um sie performant zu machen, was sich geringfügig negativ auf die Benutzererfahrung auswirkt, da der Bildaufruf mit einer leichten Verzögerung ausgelöst wird.

Allerdings ist, wie bei jeder neuen Funktion, die Unterstützung für die Intersection Observer API nicht in allen Browsern verfügbar.

Daher müssen wir in Browsern, in denen die Intersection Observer API nicht unterstützt wird, auf die Event-Listener-Methode zurückgreifen. Dies haben wir im obigen Beispiel berücksichtigt.

Kapitel 4: Lazy Loading von CSS-Hintergrundbildern

Ein gängiges Hintergrundbild in CSS

.my-class {
  background-image: url('/path/to/some/image.jpg');
  /* more styles */
}

CSS-Hintergrundbilder sind nicht so einfach wie das Bild-Tag. Um sie zu laden, muss der Browser den DOM-Tree sowie den CSSOM-Tree aufbauen, um zu entscheiden, ob die CSS-Regel auf einen DOM-Knoten im aktuellen Dokument angewendet wird. Wenn die CSS-Regel, die das Hintergrundbild spezifiziert, nicht auf ein Element im Dokument angewendet wird, lädt der Browser das Hintergrundbild nicht. Wenn die CSS-Regel auf ein Element im aktuellen Dokument anwendbar ist, lädt der Browser das Bild.

Huh? Das mag zuerst komplex erscheinen, aber dieses Verhalten bildet die Grundlage für die Technik des Lazy Loadings von Hintergrundbildern. Einfach ausgedrückt: Wir täuschen den Browser an, die CSS-Eigenschaft background-image erst dann auf ein Element anzuwenden, wenn dieses Element in den Viewport gelangt.

Hier ist ein funktionierendes Beispiel, das ein CSS-Hintergrundbild lazy lädt.

Eine Sache, die hier zu beachten ist, ist, dass der JavaScript-Code für Lazy Loading immer noch derselbe ist. Wir verwenden immer noch die Intersection Observer API-Methode mit einem Fallback auf Event Listener. Der „Trick“ liegt im CSS.

Wir haben ein Element mit der ID bg-image, das ein background-image hat. Wenn wir dem Element jedoch die Klasse lazy hinzufügen, können wir die background-image-Eigenschaft überschreiben, indem wir ihren Wert in CSS auf none setzen.

Da ein Element mit einer ID und einer Klasse in CSS eine höhere Spezifität als eine ID allein hat, wendet der Browser zunächst die Eigenschaft background-image: none auf das Element an. Wenn wir nach unten scrollen, erkennt die Intersection Observer API (oder Event Listener, je nachdem, welche Methode Sie wählen), dass das Bild im Viewport ist, und entfernt die Klasse lazy vom Element. Dies ändert das anwendbare CSS und wendet die tatsächliche background-image-Eigenschaft auf das Element an, was das Laden des Hintergrundbilds auslöst.

Kapitel 5: Schaffung einer besseren Benutzererfahrung mit Lazy Loading

Lazy Loading bietet einen großen Leistungsvorteil. Für ein E-Commerce-Unternehmen, das Hunderte von Produktbildern auf einer Seite lädt, kann Lazy Loading eine deutliche Verbesserung der anfänglichen Seitenladezeiten bei gleichzeitiger Reduzierung des Bandverbrauch bringen.

Viele Unternehmen entscheiden sich jedoch nicht für Lazy Loading, da sie glauben, dass es gegen die Bereitstellung einer großartigen Benutzererfahrung verstößt (d. h. der anfängliche Platzhalter ist hässlich, die Ladezeiten sind langsam usw.).

In diesem Abschnitt versuchen wir, einige Bedenken hinsichtlich der Benutzererfahrung mit Lazy Loading von Bildern zu lösen.

Tipp 1. Den richtigen Platzhalter verwenden

Ein Platzhalter ist das, was im Container erscheint, bis das tatsächliche Bild geladen ist. Normalerweise sehen wir Entwickler, die einen einfarbigen Platzhalter für Bilder oder ein einzelnes Bild als Platzhalter für alle Bilder verwenden.

Die bisher betrachteten Beispiele haben einen ähnlichen Ansatz verfolgt: eine Box mit einem einfarbigen hellgrauen Hintergrund. Wir können es jedoch besser machen, um eine angenehmere Benutzererfahrung zu bieten. Unten sind zwei Beispiele für die Verwendung besserer Platzhalter für unsere Bilder.

Platzhalter mit dominierender Farbe

Anstatt eine feste Farbe für den Bildplatzhalter zu verwenden, finden wir die dominante Farbe des Originalbildes und verwenden diese als Platzhalter. Diese Technik wird seit einiger Zeit von Google in seinen Bildergebnissen sowie von Pinterest in seinem Rasterdesign verwendet.

Das mag kompliziert erscheinen, aber Manuel Wieser hat eine elegante Lösung, um dies zu erreichen, indem das Bild auf ein 1×1-Pixel verkleinert und dann auf die Größe des Platzhalters skaliert wird – eine sehr grobe Annäherung, aber eine einfache, unkomplizierte Möglichkeit, eine einzelne dominante Farbe zu erhalten. Mit ImageKit kann der Platzhalter mit dominanter Farbe mit einer verketteten Transformation in ImageKit wie unten gezeigt erhalten werden.

<!-- Original image at 400x300 -->
<img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300" alt="original image"> 

<!-- Dominant color image with same dimensions -->
<img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-1,h-1:w-400,h-300" alt="dominant color placeholder">

Das Platzhalterbild ist nur 661 Bytes groß, verglichen mit dem Originalbild, das 12700 Bytes wiegt – **19x kleiner**. Und es bietet ein schöneres Übergangserlebnis vom Platzhalter zum tatsächlichen Bild.

Hier ist ein Video, das demonstriert, wie dieser Effekt für den Benutzer funktioniert.

Low Quality Image Placeholder (LQIP)

Wir können die obige Idee, einen Platzhalter mit dominierender Farbe zu verwenden, weiter ausbauen. Anstatt eine einzelne Farbe zu verwenden, verwenden wir eine sehr niedrig aufgelöste, verschwommene Version des Originalbildes als Platzhalter. Das sieht nicht nur gut aus, sondern gibt dem Benutzer auch eine Vorstellung davon, wie das tatsächliche Bild aussieht, und die Wahrnehmung, dass das Bild geladen wird, ist im Gange. Dies ist großartig, um die wahrgenommene Ladeerfahrung zu verbessern. Diese Technik wurde von Unternehmen wie Facebook und Medium genutzt.

LQIP-Bild-URL-Beispiel mit ImageKit

<!-- Original image at 400x300 --> 
<img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300" alt="original image">

<!-- Low quality image placeholder with same dimensions --> 
<img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300,bl-30,q-50" alt="dominant color placeholder">

Das LQIP ist 1300 Bytes groß, immer noch fast **10x kleiner** als das Originalbild und eine signifikante Verbesserung in Bezug auf das visuelle Erlebnis gegenüber jeder anderen Platzhaltertechnik.

Hier ist ein Video, das demonstriert, wie dieser Effekt für den Benutzer funktioniert.

---

Es ist klar, dass die Verwendung von Platzhaltern mit dominierender Farbe oder LQIP-Platzhaltern einen reibungsloseren Übergang vom Platzhalter zum tatsächlichen Bild bietet, dem Benutzer eine Vorstellung davon gibt, was ihn anstelle dieses Platzhalters erwartet, und die Ladebildwahrnehmung verbessert.

Tipp 2: Pufferzeit zum Laden von Bildern hinzufügen

Als wir verschiedene Methoden zum Auslösen von Bildladungen diskutierten, prüften wir den Zeitpunkt, zu dem das Bild in den Viewport gelangt, d. h. das Bild wird geladen, wenn der obere Rand des Bildplatzhalters mit dem unteren Rand des Viewports zusammenfällt.

Das Problem dabei ist, dass Benutzer möglicherweise sehr schnell durch die Seite scrollen und das Bild einige Millisekunden zum Laden und Erscheinen auf dem Bildschirm benötigt. In Kombination mit der Drosselung, die den Ladevorgang möglicherweise weiter verzögert, wartet der Benutzer möglicherweise ein paar zusätzliche Millisekunden, bis das Bild angezeigt wird. Nicht ideal für die Benutzererfahrung!

Obwohl wir mit der Intersection Observer API für die Leistung und LQIP für reibungslosere Übergänge eine ziemlich gute Benutzererfahrung erzielen können, gibt es einen weiteren einfachen Trick, mit dem Sie sicherstellen können, dass die Bilder immer vollständig geladen sind, wenn sie in den Viewport gelangen: Führen Sie einen Rand am Auslösepunkt für Bilder ein.

Anstatt das Bild genau dann zu laden, wenn es in den Viewport gelangt, laden Sie es, wenn es, sagen wir, 500 Pixel, *bevor* es in den Viewport gelangt. Dies bietet zusätzliche Zeit zwischen dem Lösungsaufruf und dem tatsächlichen Eintritt in den Viewport, damit die Bilder geladen werden können.

Mit der Intersection Observer API können Sie den Parameter root zusammen mit dem Parameter rootMargin (funktioniert wie eine Standard-CSS-Margin-Regel), um die effektive Begrenzungsbox zu vergrößern, die zur Ermittlung der Schnittmenge berücksichtigt wird. Bei der Event-Listener-Methode können wir anstelle der Überprüfung, ob die Differenz zwischen dem Bildrand und dem Viewport-Rand 0 ist, eine positive Zahl verwenden, um einen Schwellenwert hinzuzufügen.

Wenn Sie sich die folgende Bildschirmaufnahme genau ansehen, werden Sie feststellen, dass das fünfte Bild in der Sequenz geladen wird, wenn das dritte Bild sichtbar ist. Ebenso wird das sechste Bild geladen, wenn das vierte sichtbar ist, und so weiter. Auf diese Weise geben wir den Bildern ausreichend Zeit, um vollständig geladen zu werden, und in den meisten Fällen wird der Benutzer den Platzhalter überhaupt nicht sehen.

Wenn Sie es noch nicht bemerkt haben, wird in all unseren Beispielen das dritte Bild (image3.jpg) immer sofort geladen, auch wenn es außerhalb des Viewports liegt. Dies geschah auch nach dem gleichen Prinzip: Etwas im Voraus laden, anstatt genau am Schwellenwert zu laden, für eine bessere Benutzererfahrung.

Tipp 3: Content Reflow vermeiden

Dies ist ein weiterer trivialer Punkt, der, wenn er gelöst wird, dazu beitragen kann, eine gute Benutzererfahrung aufrechtzuerhalten.

Wenn kein Bild vorhanden ist, weiß der Browser nicht, wie viel Platz es einnehmen wird. Und wenn wir es nicht mit CSS angeben, hat der umschließende Container keine Dimensionen, d. h. er wird als 0x0 Pixel gelesen.

Wenn das Bild geladen wird, fügt der Browser es in den Bildschirm ein und ordnet den Inhalt neu an, um es anzupassen. Diese plötzliche Änderung des Layouts bewirkt, dass sich andere Elemente verschieben, und dies wird als Content Reflow oder Shifting bezeichnet. Michael Scharnagl erklärt ausführlich, wie dies zu einer unangenehmen Benutzererfahrung führt.

Dies kann vermieden werden, indem für den umschließenden Container eine Höhe und/oder Breite angegeben wird, damit der Browser den Bildcontainer mit einer bekannten Höhe und Breite zeichnen kann. Wenn das Bild später geladen wird, da die Containergröße bereits angegeben ist und das Bild perfekt hineinpasst, bewegt sich der restliche Inhalt um diesen Container nicht.

Tipp 4: Vermeiden Sie Lazy Loading für jedes Bild

Dies ist ein Fehler, den Entwickler oft machen, da es sehr verlockend ist zu denken, dass das Verzögern von Bildladungen immer gut ist. Aber wie im Leben selbst kann man von einer guten Sache zu viel haben. Lazy Loading kann zwar die anfängliche Seitenladezeit verkürzen, aber auch zu einer schlechten Benutzererfahrung führen, wenn einige Bilder verzögert geladen werden, obwohl sie es nicht sollten.

Wir können einigen allgemeinen Prinzipien folgen, um zu identifizieren, welche Bilder per Lazy Loading geladen werden sollten. Zum Beispiel sollten Bilder, die im Viewport oder am Anfang einer Webseite sichtbar sind, wahrscheinlich nicht per Lazy Loading geladen werden. Dies gilt für jedes Header-Bild, jedes Marketing-Banner, Logos oder wirklich alles, was der Benutzer beim ersten Aufrufen einer Seite sehen würde. Denken Sie auch daran, dass mobile und Desktop-Geräte unterschiedliche Bildschirmgrößen haben und somit eine unterschiedliche Anzahl von Bildern, die anfangs auf dem Bildschirm sichtbar sind. Sie sollten das verwendete Gerät berücksichtigen und entscheiden, welche Ressourcen im Voraus geladen und welche per Lazy Loading geladen werden sollen.

Ein weiteres Beispiel sind Bilder, die sich beim initialen Laden auch nur geringfügig außerhalb des Viewports befinden und wahrscheinlich nicht per Lazy Loading geladen werden sollten. Dies folgt dem oben genannten Prinzip – geringfügig im Voraus laden. Sagen wir also, jedes Bild, das 500 Pixel oder eine einzige Scrollbewegung vom unteren Rand des Viewports entfernt ist, kann ebenfalls im Voraus geladen werden.

Ein weiteres Beispiel ist, wenn die Seite kurz ist. Es kann nur eine oder zwei Scrollbewegungen dauern, oder es gibt vielleicht weniger als fünf Bilder außerhalb des Viewports. In diesen Fällen können Sie Lazy Loading wahrscheinlich ganz weglassen. Es würde dem Endbenutzer keine signifikanten Leistungsvorteile bringen und das zusätzliche JavaScript, das Sie zum Aktivieren von Lazy Loading auf der Seite laden, würde jeden potenziellen Gewinn zunichte machen.

Kapitel 5: Abhängigkeit von Lazy Loading von JavaScript

Die gesamte Idee des Lazy Loadings hängt davon ab, ob JavaScript im Browser des Benutzers aktiviert und verfügbar ist. Während die meisten Ihrer Benutzer wahrscheinlich JavaScript aktiviert haben, ist es wichtig, Fälle zu berücksichtigen, in denen dies nicht der Fall ist.

Sie könnten entweder eine Nachricht anzeigen, die den Benutzern erklärt, warum die Bilder nicht geladen werden, und sie ermutigt, einen modernen Browser zu verwenden oder JavaScript zu aktivieren.

Eine andere Möglichkeit ist die Verwendung des noscript-Tags. Dieser Ansatz hat jedoch einige Tücken. Dieser Diskussionsfaden auf Stack Overflow geht sehr gut auf diese Bedenken ein und wird für jeden empfohlen, der diese Gruppe von Benutzern berücksichtigen möchte.

Kapitel 6: Beliebte JavaScript-Bibliotheken für Lazy Loading

Da Umgebungen und Implementierungsdetails je nach Browser und Gerät variieren können, sollten Sie vielleicht eine bewährte Bibliothek für Lazy Loading in Betracht ziehen, anstatt etwas von Grund auf neu zu entwickeln.

Hier ist eine Liste beliebter Bibliotheken und plattformspezifischer Plugins, mit denen Sie Lazy Loading mit minimalem Aufwand implementieren können

• Yet Another Lazy Loader: Diese Bibliothek verwendet die Intersection Observer API und greift auf ereignisbasiertes Lazy Loading für Browser zurück, die sie noch nicht unterstützen. Dies ist großartig für fast jedes HTML-Element, funktioniert aber leider nicht für Hintergrundbilder in CSS. Die gute Nachricht ist, dass sie IE bis Version 11 unterstützt.
• lazysizes: Dies ist eine sehr beliebte Bibliothek mit umfangreicher Funktionalität. Sie unterstützt responsive Bild-srcset- und sizes-Attribute und bietet eine hervorragende Leistung, obwohl sie die Intersection Observer API nicht nutzt.
• WordPress A3 Lazy Load: Es gibt viele Lazy Loading WordPress-Plugins, aber dieses hier verfügt über eine robuste Funktionsausstattung, einschließlich eines Fallbacks, wenn JavaScript nicht verfügbar ist.
• jQuery Lazy: Eine einfache Bibliothek, die eine jQuery-Implementierung verwendet.
• WeltPixel Lazy Loading Enhanced: Eine Magento 2-Erweiterung.
• Magento Lazy Image Loader: Eine weitere Magento-Erweiterung, für 1.x.
• Shopify Lazy Image Plugin (kostenpflichtig): Ermöglicht Lazy Loading auf einer Shopify-Website.

Kapitel 7: Testen von Lazy Load

Nachdem Sie Lazy Loading implementiert haben, möchten Sie wahrscheinlich überprüfen, ob es wie beabsichtigt funktioniert. Der einfachste Weg wäre, die Entwicklertools in Ihrem Browser zu öffnen.

Gehen Sie von dort zu Netzwerk > Bilder. Wenn Sie die Seite zum ersten Mal aktualisieren, sollten Sie nur die geladenen Bilder in der Liste sehen.

Wenn Sie dann nach unten scrollen, werden andere Bildanforderungen ausgelöst und geladen. Sie können auch die Ladezeiten für Bilder in der Wasserfallspalte in dieser Ansicht sehen. Dies hilft Ihnen, Bildladefehler oder Probleme beim Auslösen des Bildladens zu identifizieren.

Eine andere Möglichkeit ist, den Google Chrome Lighthouse Audit Report für Ihre Seite auszuführen, nachdem Sie die Änderungen implementiert haben, und nach Vorschlägen im Abschnitt „Offscreen images“ zu suchen.

Fazit

Wir haben viel über Lazy Loading von Bildern gelernt! Lazy Loading – wenn es gut implementiert ist – kann erhebliche Vorteile für die Leistung Ihrer Website bringen und gleichzeitig die Gesamtgröße der Seite und die Lieferkosten reduzieren, da unnötige Ressourcen im Voraus verzögert geladen werden.

Worauf warten Sie also noch? Beginnen Sie jetzt mit dem Lazy Loading von Bildern! Und wenn Sie eine kleine Erinnerung brauchen, wie das funktioniert, speichern Sie eine Kopie der folgenden Infografik.