Lazy Loading (verzögertes Laden) ist eine Technik zur Web-Optimierung, die das Laden von nicht sichtbaren Ressourcen -- Bilder, Videos, Komponenten, Daten -- verzögert, bis der Nutzer zu dem Bereich der Seite scrollt, in dem sie erscheinen. So werden die initiale Ladezeit und der Bandbreitenverbrauch reduziert.
Hier ist das Paradox, das nur wenige Teams hören wollen: Lazy Loading ist hervorragend für Ihre Nutzer und katastrophal für Ihre visuellen Tests. Es ist eine Technologie, die darauf ausgelegt ist, Inhalte nicht zu laden, solange sie nicht sichtbar sind. Ein visuelles Testwerkzeug muss jedoch den Inhalt sehen, um ihn zu testen. Diese beiden Ziele stehen grundsätzlich in Spannung zueinander.
Diese Spannung ist kein Grund, sich für eines auf Kosten des anderen zu entscheiden. Ihre Website braucht Lazy Loading für die Performance -- die Daten von Google sind eindeutig: Die Ladezeit ist ein SEO-Rankingfaktor und ein entscheidender Faktor für die Absprungrate. Und Ihre Website braucht visuelle Tests, um sicherzustellen, dass Lazy Loading keine Regressionen einführt -- ein Placeholder, der nie verschwindet, ein Bild, das mit falschen Abmessungen geladen wird, ein Layout, das springt, wenn der Inhalt erscheint.
Dieser Artikel erklärt, wie Sie beides vereinbaren können.
Warum Lazy Loading den visuellen Test erschwert
Unsichtbarer Inhalt ist nicht testbar
Das Grundprinzip von Lazy Loading ist, dass Inhalte unterhalb der Faltlinie (below the fold) beim initialen Seitenladen nicht geladen werden. Ein Screenshot, der unmittelbar nach dem Laden aufgenommen wird, zeigt nur den Inhalt oberhalb der Faltlinie -- alles andere fehlt oder wird durch Platzhalter ersetzt.
Das ist ein Abdeckungsproblem. Wenn Ihre Seite 5000 Pixel hoch ist und Ihr Viewport 900 Pixel misst, deckt ein initialer Screenshot nur 18 % Ihrer Seite ab. Die restlichen 82 % werden nicht getestet. Bei einer E-Commerce-Produktseite bedeutet das, dass die Beschreibung, Kundenbewertungen, empfohlene Produkte und der Footer niemals visuell überprüft werden.
Manche Teams denken, sie könnten das Problem mit einem Full-Page-Screenshot lösen. Aber ein Full-Page-Screenshot löst kein Lazy Loading aus -- er erfasst die Seite so, wie sie zum Zeitpunkt der Aufnahme gerendert wird, mit Platzhaltern und nicht geladenen Elementen. Sie erhalten ein vollständiges Bild einer unvollständigen Seite.
Der Zeitpunkt der Aufnahme: ein permanentes Dilemma
Wann genau sollten Sie Ihren Screenshot aufnehmen? Die Frage klingt einfach. Ist sie aber nicht.
Wenn Sie den Screenshot unmittelbar nach dem Laden der Seite aufnehmen, erfassen Sie den Anfangszustand mit den Platzhaltern. Das ist schnell, aber unvollständig. Wenn Sie vor der Aufnahme bis zum Ende der Seite scrollen, lösen Sie das Laden aller verzögerten Inhalte aus -- aber während jede Ressource lädt, kann sich der Inhalt oben auf der Seite verändert haben (Animationen, Echtzeit-Updates, erneutes Rendern des Headers).
Und das Scrollen selbst verändert das Erscheinungsbild der Seite. Ein Sticky Header, der beim Scrollen erscheint, ein "Zurück nach oben"-Button, der sich materialisiert, ein Lesefortschrittsindikator, der sich füllt -- all diese Elemente ändern sich je nach Scrollposition, und ihr Zustand zum Zeitpunkt der Aufnahme variiert von Durchlauf zu Durchlauf.
Bild-Platzhalter und Layout Shift
Lazy Loading von Bildern verwendet Platzhalter, um Platz im Layout zu reservieren: graue Rechtecke, niedrig aufgelöste Vorschaubilder (LQIP -- Low Quality Image Placeholder), farbige SVGs oder einfach nichts. Wenn das eigentliche Bild lädt, ersetzt es den Platzhalter.
Das Problem tritt auf, wenn der Austausch des Platzhalters durch das Bild die Abmessungen des Elements verändert. Das ist der berüchtigte Cumulative Layout Shift (CLS) -- eine sichtbare Verschiebung, die umliegende Elemente verschiebt und negative SEO-Auswirkungen haben kann. Wenn Ihr Screenshot während dieser Verschiebung aufgenommen wird, erfassen Sie einen Übergangszustand, der weder der Platzhalter noch der Endzustand ist.
Best Practices empfehlen, explizite Abmessungen für Bilder festzulegen (width und height in HTML), um Layout Shift zu vermeiden. Aber nicht alle Teams befolgen diese Best Practices, und responsive Bilder mit variablen Abmessungen machen die Sache komplexer.
Infinite Scroll: eine endlose Seite
Infinite Scroll treibt das Lazy-Loading-Problem auf die Spitze. Anstelle einer Seite mit fester Größe und verzögertem Inhalt haben Sie eine Seite, deren Länge potenziell unendlich ist. Jedes Scrollen nach unten lädt neue Elemente und verlängert die Seite.
Wie testen Sie eine endlose Seite visuell? Sie können keinen Full-Page-Screenshot aufnehmen -- die Seite hat kein "Full". Sie müssen willkürlich entscheiden, wann Sie aufhören zu scrollen, wie viele Elemente eine ausreichende Stichprobe darstellen und wie Sie damit umgehen, dass die per Infinite Scroll geladenen Inhalte oft aus sich ändernden Daten gespeist werden (neue Artikel, neue Veröffentlichungen, neue Produkte).
Infinite Scroll erzeugt auch ein Speicherproblem. Jeder geladene Inhaltsblock fügt Elemente zum DOM hinzu. Nach genügend Scrollvorgängen kann der Browser langsamer werden, das Rendering weniger flüssig sein, und das Timing der Operationen kann variieren -- was Nichtdeterminismus in Ihre Tests einführt.
Strategien zum visuellen Testen von Lazy-Loading-Inhalten
Strategie 1: Inkrementelles Scrollen mit mehreren Aufnahmen
Anstatt einen einzigen Screenshot der gesamten Seite zu suchen, teilen Sie die Seite in Segmente auf und erfassen jedes Segment einzeln. Scrollen Sie um die Höhe eines Viewports, warten Sie, bis der verzögerte Inhalt geladen ist, nehmen Sie einen Screenshot auf und fahren Sie fort.
Dieser Ansatz erzeugt eine Reihe von Screenshots -- Viewport 1, Viewport 2, Viewport 3 usw. -- die Sie einzeln mit ihren jeweiligen Baselines vergleichen. Jeder Screenshot deckt ein bestimmtes Segment der Seite mit vollständig geladenem Inhalt ab.
Der Vorteil ist, dass Sie eine vollständige Abdeckung mit vollständig geladenen Inhalten erhalten. Der Nachteil ist die Vielzahl der zu pflegenden Baselines und das Timing-Management zwischen jedem Scroll und jeder Aufnahme. Die Stabilisierungszeit nach dem Scrollen -- die Zeit, bis Bilder geladen, Übergangsanimationen abgeschlossen und das Layout stabilisiert sind -- muss ausreichend, aber nicht übertrieben sein.
Für Infinite Scroll definieren Sie eine feste Anzahl von Scrollvorgängen (zum Beispiel 5 oder 10) und testen die entsprechenden Segmente. Sie können nicht das Unendliche testen, aber Sie können eine repräsentative Stichprobe testen.
Strategie 2: Vollständiges Laden vor der Aufnahme erzwingen
Einige Tools ermöglichen es, Lazy Loading in der Testumgebung zu deaktivieren. Das HTML-Attribut loading="eager" erzwingt das sofortige Laden aller Bilder. Intersection Observer-Skripte können gepatcht werden, damit alle Elemente sofort als sichtbar betrachtet werden. Frameworks wie React und Vue, die Lazy Loading auf Komponentenebene implementieren, können so konfiguriert werden, dass alle Komponenten im Testmodus geladen werden.
Dieser Ansatz verwandelt Ihre Lazy-Loading-Seite in eine vollständig geladene Seite, und Sie können einen klassischen Full-Page-Screenshot aufnehmen. Das ist einfach, direkt und löst das Abdeckungsproblem.
Aber Sie testen nicht mehr das Lazy Loading selbst. Wenn Ihre Lazy-Loading-Implementierung einen Bug hat -- eine Komponente, die nie lädt, ein Platzhalter, der angezeigt bleibt, eine Übergangsanimation, die das Layout beschädigt -- werden Sie das im "eager"-Modus nicht sehen. Sie testen den Inhalt, nicht den Lademechanismus.
Das ist ein akzeptabler Kompromiss, wenn Ihr Ziel ausschließlich die Erkennung visueller Regressionen im Inhalt ist. Wenn Sie auch überprüfen möchten, ob das Lazy Loading korrekt funktioniert, benötigen Sie die folgende Strategie.
Strategie 3: Übergangszustände testen
Anstatt Lazy Loading zu umgehen, testen Sie es explizit. Nehmen Sie Screenshots in jeder Phase des Ladezyklus auf: den Anfangszustand mit den Platzhaltern, den Zustand während des Ladens (Übergang) und den Endzustand mit dem vollständigen Inhalt.
Jeder Zustand hat seine eigene Baseline. Der Test des Anfangszustands überprüft, ob die Platzhalter korrekt dimensioniert und positioniert sind. Der Test des Endzustands überprüft, ob der geladene Inhalt die Platzhalter korrekt ersetzt, ohne das Layout zu beschädigen. Der Übergangstest überprüft, ob kein übertriebener Layout Shift auftritt.
Dieser Ansatz ist der umfassendste, aber auch der aufwändigste in der Pflege. Drei Baselines pro Lazy-Loading-Komponente bedeuten dreifachen Wartungsaufwand, wenn sich das Design weiterentwickelt. Reservieren Sie diesen Ansatz für kritische Komponenten, bei denen das Lazy-Loading-Verhalten wesentlich für die Benutzererfahrung ist.
Strategie 4: Struktureller Vergleich, unabhängig von Pixelinhalten
Der strukturelle Ansatz löst elegant mehrere Lazy-Loading-Probleme gleichzeitig. Anstatt die Pixel eines Platzhalters und die Pixel des finalen Bildes zu vergleichen, vergleicht er die Struktur des Elements: seine Position im DOM, seine berechneten Abmessungen, seine CSS-Eigenschaften, seine Sichtbarkeit.
Ein korrekt dimensionierter Platzhalter nimmt denselben Raum ein wie das finale Bild -- die Struktur ist identisch, auch wenn die Pixel völlig unterschiedlich sind. Eine Lazy-Loading-Komponente, die korrekt lädt, behält dieselbe Position und dieselben Abmessungen wie ihr Platzhalter. Der strukturelle Ansatz validiert diese Äquivalenz, ohne sich um den Pixelinhalt der Bilder zu kümmern.
Das ist der Ansatz, den Delta-QA nativ verwendet. Wenn ein 400x300-Pixel-Platzhalter durch ein 400x300-Pixel-Bild ersetzt wird, ändert sich die Struktur nicht -- kein Alarm. Wenn ein 400x300-Platzhalter durch ein 400x200-Bild ersetzt wird (ein Bug im Seitenverhältnis), ändert sich die Struktur -- berechtigter Alarm.
Die spezifischen Herausforderungen von Infinite Scroll
Infinite Scroll verdient besondere Aufmerksamkeit, weil es die Lazy-Loading-Probleme mit eigenen Herausforderungen kombiniert.
Das Problem der Wiederholbarkeit
Infinite Scroll lädt in der Regel paginierten Inhalt von einer API. Der Inhalt von Seite 2 hängt davon ab, was auf Seite 1 ist. Wenn sich der Datensatz zwischen zwei Testläufen ändert (ein neuer Artikel veröffentlicht, ein Produkt entfernt), haben die Seiten nicht denselben Inhalt, und der Vergleich schlägt fehl.
Um wiederholbare Ergebnisse zu erzielen, müssen Sie die zugrunde liegenden Daten einfrieren. Verwenden Sie eine gemockte API, die immer dieselben Daten in derselben Reihenfolge liefert, oder testen Sie gegen eine Staging-Umgebung mit einem festen Datensatz.
Das Problem des Renderings von Rändern und Gruppierungen
Infinite-Scroll-Listen zeigen oft Inhalte mit Gruppierungs-Headern an -- "Heute", "Gestern", "Letzte Woche". Diese Header hängen vom aktuellen Datum ab und ändern sich von Tag zu Tag. Ein heute veröffentlichter Artikel steht unter dem Header "Gestern" am nächsten Tag.
Die Lösung ist dieselbe wie für jeden zeitabhängigen Inhalt: Frieren Sie das Systemdatum in der Testumgebung ein.
Das Problem der verschlechterten Performance
Nach 20 oder 30 aufeinanderfolgenden Scrollvorgängen kann die Browser-Performance aufgrund der Anzahl der Elemente im DOM nachlassen. Diese Verschlechterung beeinflusst das Rendering-Timing und kann Nichtdeterminismus in Ihre Screenshots einführen.
Gut konzipierte Anwendungen implementieren Virtualisierung -- sie halten nur die aktuell sichtbaren Elemente im DOM und recyceln DOM-Knoten während des Scrollens. Wenn Ihre Anwendung das DOM virtualisiert, bleibt die Anzahl der Elemente konstant, unabhängig von der Anzahl der Scrollvorgänge, und die Performance bleibt stabil.
Wenn Ihre Anwendung keine Virtualisierung verwendet, begrenzen Sie die Anzahl der Scrollvorgänge in Ihren Tests, um im akzeptablen Performance-Bereich zu bleiben.
Praktische Empfehlungen zur Integration von Lazy Loading in Ihre visuelle Teststrategie
Für Bilder mit Lazy Loading ist das Minimum, den Endzustand zu testen -- den Zustand, in dem alle sichtbaren Bilder im Viewport geladen sind. Verwenden Sie inkrementelles Scrollen, um das Laden auszulösen, warten Sie auf die Stabilisierung und nehmen Sie auf. Definieren Sie klare Erwartungen: Alle Bilder im Viewport müssen geladen sein (keine sichtbaren Platzhalter), und nach dem Laden darf kein Layout Shift auftreten.
Für Komponenten mit Lazy Loading (Code Splitting, Dynamic Imports) testen Sie in zwei Modi: den Modus "alles geladen", um das Rendering der Komponenten selbst zu überprüfen, und den Modus "natürliches Laden", um Übergangszustände und Fallbacks zu überprüfen.
Für Infinite Scroll definieren Sie einen realistischen Testumfang. Testen Sie die ersten 3 bis 5 Ladevorgänge (Scrolls), die das Anfangsverhalten, die Paginierungslogik und den Übergang zwischen den Chargen abdecken. Versuchen Sie nicht, den gesamten Fluss zu testen -- das ist weder praktisch noch notwendig.
Für Platzhalter testen Sie diese explizit. Platzhalter sind Teil der Benutzererfahrung -- ein falsch dimensionierter Platzhalter verursacht Layout Shift, ein fehlender Platzhalter hinterlässt eine weiße Lücke auf der Seite. Nehmen Sie einen Screenshot des Anfangszustands (vor dem Scrollen) auf und überprüfen Sie, ob die Platzhalter korrekt dimensioniert und positioniert sind.
Für das Timing bevorzugen Sie bedingte Wartezeiten gegenüber festen Verzögerungen. Warten Sie, bis die Bilder geladen sind (über das load-Event der img-Elemente), anstatt eine willkürliche Anzahl von Sekunden zu warten. Feste Verzögerungen sind fragil -- 2 Sekunden können lokal ausreichen und in der CI unter Last unzureichend sein.
Lazy Loading ist ein Verbündeter, kein Feind
Lazy Loading optimiert die Performance Ihrer Website. Es reduziert die initiale Ladezeit, den Bandbreitenverbrauch und die Ressourcennutzung auf der Client-Seite. Das sind reale und messbare Vorteile für Ihre Nutzer.
Die Tatsache, dass es den visuellen Test erschwert, ist kein Grund, es aufzugeben -- es ist ein Grund, Ihre Teststrategie anzupassen. Und moderne visuelle Testtools, allen voran Delta-QA, sind dafür konzipiert, diese Komplexität zu bewältigen, ohne dass Sie zwischen Performance und Testbarkeit wählen müssen.
Lazy Loading ist kein Hindernis für den visuellen Test. Es ist eine technische Einschränkung mit technischen Lösungen. Setzen Sie sie um, und Sie haben das Beste aus beiden Welten: schnelle Seiten und zuverlässige Tests.
FAQ
Macht Lazy Loading den visuellen Full-Page-Test unmöglich?
Nein, aber es erfordert einen anderen Ansatz als den klassischen Full-Page-Screenshot. Entweder erzwingen Sie das vollständige Laden (loading="eager") vor der Aufnahme, oder Sie scrollen schrittweise und erfassen jedes Segment einzeln. Beide Ansätze bieten eine vollständige Abdeckung -- der erste ist einfacher, der zweite ist näher am realen Verhalten der Seite.
Wie teste ich visuell eine Seite mit Infinite Scroll?
Definieren Sie einen realistischen Testumfang: 3 bis 5 Scrollvorgänge decken das Anfangsverhalten, die Paginierungslogik und die Übergänge zwischen Chargen ab. Verwenden Sie gemockte Daten, um die Wiederholbarkeit zu gewährleisten. Erfassen Sie jedes Segment als unabhängigen Screenshot mit eigener Baseline. Versuchen Sie nicht, das Unendliche zu testen -- testen Sie eine repräsentative und zuverlässige Stichprobe.
Sollte man Lazy Loading in der Testumgebung deaktivieren?
Das hängt von Ihrem Ziel ab. Wenn Sie den Inhalt testen (visuelle Regressionen im Design erkennen), deaktivieren Sie Lazy Loading, um die Aufnahmen zu vereinfachen. Wenn Sie den Lademechanismus testen (überprüfen, ob Platzhalter, Übergänge und verzögertes Laden funktionieren), behalten Sie Lazy Loading aktiviert und testen Sie die verschiedenen Zustände explizit.
Wie geht man mit dem Layout Shift um, der durch verzögertes Laden von Bildern verursacht wird?
Definieren Sie immer explizite Abmessungen (width und height) für Ihre Bilder, um den Platz im Layout zu reservieren. Verwenden Sie Platzhalter mit denselben Abmessungen wie das finale Bild (LQIP oder farbige Rechtecke). Testen Sie visuell den Anfangszustand (mit Platzhaltern) und den Endzustand (mit Bildern), um sicherzustellen, dass sich die Abmessungen nicht ändern und keine Verschiebung auftritt.
Sind visuelle Tests mit Lazy Loading langsamer als klassische Tests?
Ja, zwangsläufig. Das inkrementelle Scrollen mit Wartezeiten für das Laden bei jedem Schritt dauert länger als eine sofortige Aufnahme einer vollständig geladenen Seite. Das ist der Preis für vollständige Abdeckung. Optimieren Sie durch Parallelisierung Ihrer Tests, Begrenzung der Scrollvorgänge auf das strikt Nötige und Verwendung bedingter Wartezeiten anstelle fester Verzögerungen, um die Wartezeit zu minimieren.
Unterstützt Delta-QA Lazy Loading und Infinite Scroll?
Ja. Der strukturelle Ansatz von Delta-QA ist besonders gut für Lazy Loading geeignet, weil er die Struktur statt der Pixel vergleicht. Ein korrekt dimensionierter Platzhalter und das finale Bild haben dieselbe Struktur -- kein Fehlalarm. Das Tool unterstützt inkrementelles Scrollen, Ladewartezeiten und Vergleich nach Segmenten, alles ohne eine Zeile Code.
Weiterführende Lektüre
- Visueller Test mit React, Vue und Angular: Framework-unabhängig testen
- Visueller Test vs. Funktionaler Test: Der grundlegende Unterschied, den die meisten Teams ignorieren
Lazy Loading optimiert die Performance Ihrer Website. Delta-QA stellt sicher, dass es keine visuellen Regressionen einführt. Die beiden sind nicht inkompatibel -- sie sind komplementär. Testen Sie Ihre dynamischen Seiten mit derselben Sorgfalt wie Ihre statischen Seiten.