Lazy Loading richtig verwenden.
Lazy Loading heißt, dass eine Ressource erst geladen wird, wenn der Nutzer sich ihr nähert — und am falschen Ort angewandt verschlechtert es die Performance, statt sie zu verbessern.
Die Idee ist einfach und richtig: Ein Bild zu laden, das der Nutzer nie sehen wird, hat keinen Sinn. Trägt eine lange Seite zwanzig Bilder und sieht der Nutzer nur die ersten drei, waren siebzehn Downloads vergebens — an Bandbreite wie an Hauptthread-Zeit.
Moderne Browser bieten das mit einem einzigen Attribut; keine Zusatzbibliothek nötig. Aber genau diese Leichtigkeit erzeugt den häufigsten Fehler: das Attribut pauschal auf alle Bilder anzuwenden.
Nie auf eine Ressource im sichtbaren Bereich
Die Regel ist ein Satz: Keine Ressource im sichtbaren Bereich wird lazy geladen. Der Grund hängt direkt an LCP — Lazy Loading verzögert die Entdeckung der Ressource und den Beginn ihrer Anforderung. Wird ein Bild im sichtbaren Bereich ohnehin sofort gebraucht, ist die Verzögerung ein Nettoverlust.
Das Hero-Bild ist fast immer das LCP-Element, und lazy geladen verlängert es LCP direkt. Das ist eine messbare, wiederholbare Regression — und das klarste Beispiel dafür, wie eine gut gemeinte Optimierung eine Website verlangsamt.
- Das Bild im sichtbaren Bereich — KEIN Lazy Loading. Bei Bedarf die Priorität anheben.
- Direkt unter dem sichtbaren Bereich — Grenzfall; der Browser beginnt ohnehin eine gewisse Distanz im Voraus zu laden.
- Bilder tief in der Seite — Lazy Loading JA; hier liegt der größte Gewinn.
- Eingebettete Rahmen — Videoplayer, Karten, Social-Boxen. Unbedingt ja; das sind die schwersten Ressourcen.
- Hintergrundbilder — das Attribut wirkt nicht; es braucht eine eigene Technik.
Der vierte Punkt ist auf den meisten Websites der größte Einzelgewinn. Ein eingebetteter Videoplayer bringt Hunderte Kilobyte Skript mit, und diese Kosten werden bezahlt, auch wenn der Nutzer das Video nie abspielt. Den Player erst beim Klick zu laden kann das Seitengewicht halbieren.
Die Platzreservierung ist Pflicht
Jede lazy geladene Ressource ist ein Kandidat für Layoutverschiebung: Kommt sie an, beginnt sie Platz einzunehmen und schiebt alles darunter. Lazy Loading und Größenangabe sind deshalb ein untrennbares Paar — eines darf nicht ohne das andere angewandt werden.
Bei Bildern ist die Lösung, die Attribute für Breite und Höhe zu schreiben; der Browser berechnet daraus das Seitenverhältnis und reserviert auch im responsiven Layout den richtigen Platz. Bei eingebetteten Rahmen muss ein Container ein Verhältnis bekommen.
Auf dieser Website sind die Live-Vorschauvideos genau so gebaut: Die Videos werden nicht vorgeladen, ihr Platz wird mit einem Posterbild reserviert, und bei aktiver Präferenz für reduzierte Bewegung lädt das Video gar nicht. Alle drei Verhalten misst die Prüfsuite einzeln.
Lazy Loading und Größenangabe sind ein untrennbares Paar; eines wird nicht ohne das andere angewandt.
Content-Visibility
Jenseits der Bilder gibt es einen Gewinn für die völlig außerhalb des Bildschirms liegenden Abschnitte der Seite: Dem Browser lässt sich auftragen, deren Layout und Malen aufzuschieben. Auf langen Seiten verkürzt das das erste Malen deutlich.
Dieselbe Falle gilt auch hier: Wird der Platz des aufgeschobenen Abschnitts nicht angegeben, ändert sich das Layout, wenn der Nutzer dorthin scrollt. Eine geschätzte Größe schließt dieses Risiko.
Dazu kommt eine übersehene Barrierefreiheitsdimension: Aufgeschobener Inhalt wird von der Seitensuche womöglich nicht gefunden. Sucht der Nutzer mit der Suchfunktion des Browsers ein Wort, wird Text in einem noch nicht gerenderten Abschnitt nicht gefunden. Bei langen Dokumenten ist das ein echter Verlust an Gebrauchstauglichkeit und begrenzt, wo die Technik angewandt werden sollte.
Wie früh geladen werden soll
Lazy Loading heißt nicht „warte bis sichtbar“; Browser beginnen eine gewisse Distanz im Voraus zu laden. Sonst sieht der Nutzer beim Scrollen eine leere Fläche, und das Bild kommt verspätet — der am häufigsten beklagte Nebeneffekt des Lazy Loading.
Die Standard-Vorausschau des Browsers variiert mit der Verbindungsgeschwindigkeit und ist meist vernünftig. Braucht es Handsteuerung, lässt sich mit einem Beobachter eine eigene Distanz definieren — aber vor dem Ändern des Standards sollte gemessen werden, ob wirklich ein Problem vorliegt.
Der praktische Test: Scrollen Sie die Seite in normalem Tempo und prüfen Sie, ob die Bilder an ihrem Platz bereitstehen. Sehen Sie leere Flächen, muss die Distanz wachsen; sehen Sie nie eine, wird vermutlich zu früh geladen und die Ersparnis verpufft.
Eine Messnotiz: Der Gewinn des Lazy Loading ist in Gesamtbytes zu messen, nicht am Erstladewert der Gewichtsberichte. Das Erstladen sieht immer gut aus — die eigentliche Frage ist, was die Summe ist, wenn der Nutzer die Seite bis zum Ende scrollt.
Prüfen: sehen, was lazy ist
Zu sehen, ob Lazy Loading auf einer Website richtig angewandt ist, dauert wenige Minuten. Im Netzwerkpanel des Browsers wird geprüft, welche Bilder beim Öffnen der Seite laden; stehen Bilder außerhalb des sichtbaren Bereichs auf der Liste, funktioniert das Lazy Loading nicht.
Die Gegenprobe zählt mehr: Stehen die Bilder im sichtbaren Bereich NICHT auf der Liste, wurde ihnen versehentlich Lazy Loading zugewiesen, und LCP leidet. Das ist das typische Ergebnis der Pauschalanwendung — und in Berichten erscheint es nie.
Die dritte Kontrolle sind die eingebetteten Rahmen: Lädt beim Seitenstart ein Videoplayer- oder Kartenskript, wurde diese Ressource nicht lazy gemacht. Das sind meist die schwersten Posten, und dort liegt der größte Gewinn.
Diese drei Kontrollen lassen sich in eine Prüfliste verwandeln und automatisieren: Die Liste der beim Seitenstart ladenden Ressourcen wird extrahiert und mit der erwarteten verglichen. Lädt eine unerwartete Ressource, leuchtet der Test rot.
Ein Schlussprinzip: Lazy Loading ist eine Entscheidung, kein Standard. Der richtige Ort zwischen „alles lazy“ und „nichts lazy“ hängt davon ab, welche Ressourcen der Seite im sichtbaren Bereich liegen, und das wird je Seitentemplate bestimmt. Keine pauschal angewandte Performance-Einstellung schlägt eine durch Messung getroffene Entscheidung.
Eine praktische Checkliste
Übersetzt man diese Seite in einen Prüfschritt, ist am Lazy-Loading-Aufbau Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.
- Ist es auf Bilder im sichtbaren Bereich angewandt — wenn ja, muss es ENTFERNT werden.
- Hat das Hero-Bild hohe Priorität?
- Sind die tiefen Bilder lazy — wenn nicht, liegt dort der größte Gewinn.
- Sind die eingebetteten Rahmen lazy — Video, Karte, Social-Box.
- Ist der Platz jeder lazy Ressource reserviert?
- Erscheinen beim Scrollen leere Flächen — wenn ja, muss die Vorausschau wachsen.
Der erste und der dritte Punkt sind einander entgegengesetzt, und beide müssen geprüft werden: Am falschen Ort angewandtes Lazy Loading bricht LCP; nicht angewandtes verbrennt Bandbreite.