Lazy Loading (verzoegertes Laden) ist eine Technik zur Web-Optimierung, die das Laden von nicht sichtbaren Ressourcen -- Bilder, Videos, Komponenten, Daten -- verzoegert, 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 hoeren wollen: Lazy Loading ist hervorragend fuer Ihre Nutzer und katastrophal fuer 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 grundsaetzlich in Spannung zueinander.
Diese Spannung ist kein Grund, sich fuer eines auf Kosten des anderen zu entscheiden. Ihre Website braucht Lazy Loading fuer die Performance -- die Daten von Google sind eindeutig: Die Ladezeit ist ein SEO-Rankingfaktor und ein entscheidender Faktor fuer die Absprungrate. Und Ihre Website braucht visuelle Tests, um sicherzustellen, dass Lazy Loading keine Regressionen einfuehrt -- ein Placeholder, der nie verschwindet, ein Bild, das mit falschen Abmessungen geladen wird, ein Layout, das springt, wenn der Inhalt erscheint.
Dieser Artikel erklaert, wie Sie beides vereinbaren koennen.
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 ueberprueft werden.
Manche Teams denken, sie koennten das Problem mit einem Full-Page-Screenshot loesen. Aber ein Full-Page-Screenshot loest 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 vollstaendiges Bild einer unvollstaendigen 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 unvollstaendig. Wenn Sie vor der Aufnahme bis zum Ende der Seite scrollen, loesen Sie das Laden aller verzoegerten Inhalte aus -- aber waehrend jede Ressource laedt, kann sich der Inhalt oben auf der Seite veraendert haben (Animationen, Echtzeit-Updates, erneutes Rendern des Headers).
Und das Scrollen selbst veraendert das Erscheinungsbild der Seite. Ein Sticky Header, der beim Scrollen erscheint, ein "Zurueck nach oben"-Button, der sich materialisiert, ein Lesefortschrittsindikator, der sich fuellt -- all diese Elemente aendern 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 aufgeloeste Vorschaubilder (LQIP -- Low Quality Image Placeholder), farbige SVGs oder einfach nichts. Wenn das eigentliche Bild laedt, ersetzt es den Platzhalter.
Das Problem tritt auf, wenn der Austausch des Platzhalters durch das Bild die Abmessungen des Elements veraendert. Das ist der beruechtigte Cumulative Layout Shift (CLS) -- eine sichtbare Verschiebung, die umliegende Elemente verschiebt und negative SEO-Auswirkungen haben kann. Wenn Ihr Screenshot waehrend dieser Verschiebung aufgenommen wird, erfassen Sie einen Uebergangszustand, der weder der Platzhalter noch der Endzustand ist.
Best Practices empfehlen, explizite Abmessungen fuer 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 Groesse und verzoegertem Inhalt haben Sie eine Seite, deren Laenge potenziell unendlich ist. Jedes Scrollen nach unten laedt neue Elemente und verlaengert die Seite.
Wie testen Sie eine endlose Seite visuell? Sie koennen keinen Full-Page-Screenshot aufnehmen -- die Seite hat kein "Full". Sie muessen willkuerlich entscheiden, wann Sie aufhoeren zu scrollen, wie viele Elemente eine ausreichende Stichprobe darstellen und wie Sie damit umgehen, dass die per Infinite Scroll geladenen Inhalte oft aus sich aendernden Daten gespeist werden (neue Artikel, neue Veroeffentlichungen, neue Produkte).
Infinite Scroll erzeugt auch ein Speicherproblem. Jeder geladene Inhaltsblock fuegt Elemente zum DOM hinzu. Nach genuegend Scrollvorgaengen kann der Browser langsamer werden, das Rendering weniger fluessig sein, und das Timing der Operationen kann variieren -- was Nichtdeterminismus in Ihre Tests einfuehrt.
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 Hoehe eines Viewports, warten Sie, bis der verzoegerte 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 vollstaendig geladenem Inhalt ab.
Der Vorteil ist, dass Sie eine vollstaendige Abdeckung mit vollstaendig 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, Uebergangsanimationen abgeschlossen und das Layout stabilisiert sind -- muss ausreichend, aber nicht uebertrieben sein.
Fuer Infinite Scroll definieren Sie eine feste Anzahl von Scrollvorgaengen (zum Beispiel 5 oder 10) und testen die entsprechenden Segmente. Sie koennen nicht das Unendliche testen, aber Sie koennen eine repraesentative Stichprobe testen.
Strategie 2: Vollstaendiges Laden vor der Aufnahme erzwingen
Einige Tools ermoeglichen es, Lazy Loading in der Testumgebung zu deaktivieren. Das HTML-Attribut loading="eager" erzwingt das sofortige Laden aller Bilder. Intersection Observer-Skripte koennen gepatcht werden, damit alle Elemente sofort als sichtbar betrachtet werden. Frameworks wie React und Vue, die Lazy Loading auf Komponentenebene implementieren, koennen so konfiguriert werden, dass alle Komponenten im Testmodus geladen werden.
Dieser Ansatz verwandelt Ihre Lazy-Loading-Seite in eine vollstaendig geladene Seite, und Sie koennen einen klassischen Full-Page-Screenshot aufnehmen. Das ist einfach, direkt und loest das Abdeckungsproblem.
Aber Sie testen nicht mehr das Lazy Loading selbst. Wenn Ihre Lazy-Loading-Implementierung einen Bug hat -- eine Komponente, die nie laedt, ein Platzhalter, der angezeigt bleibt, eine Uebergangsanimation, die das Layout beschaedigt -- werden Sie das im "eager"-Modus nicht sehen. Sie testen den Inhalt, nicht den Lademechanismus.
Das ist ein akzeptabler Kompromiss, wenn Ihr Ziel ausschliesslich die Erkennung visueller Regressionen im Inhalt ist. Wenn Sie auch ueberpruefen moechten, ob das Lazy Loading korrekt funktioniert, benoetigen Sie die folgende Strategie.
Strategie 3: Uebergangszustaende 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 waehrend des Ladens (Uebergang) und den Endzustand mit dem vollstaendigen Inhalt.
Jeder Zustand hat seine eigene Baseline. Der Test des Anfangszustands ueberprueft, ob die Platzhalter korrekt dimensioniert und positioniert sind. Der Test des Endzustands ueberprueft, ob der geladene Inhalt die Platzhalter korrekt ersetzt, ohne das Layout zu beschaedigen. Der Uebergangstest ueberprueft, ob kein uebertriebener Layout Shift auftritt.
Dieser Ansatz ist der umfassendste, aber auch der aufwaendigste in der Pflege. Drei Baselines pro Lazy-Loading-Komponente bedeuten dreifachen Wartungsaufwand, wenn sich das Design weiterentwickelt. Reservieren Sie diesen Ansatz fuer kritische Komponenten, bei denen das Lazy-Loading-Verhalten wesentlich fuer die Benutzererfahrung ist.
Strategie 4: Struktureller Vergleich, unabhaengig von Pixelinhalten
Der strukturuelle Ansatz loest 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 voellig unterschiedlich sind. Eine Lazy-Loading-Komponente, die korrekt laedt, behaelt dieselbe Position und dieselben Abmessungen wie ihr Platzhalter. Der strukturelle Ansatz validiert diese Aequivalenz, ohne sich um den Pixelinhalt der Bilder zu kuemmern.
Das ist der Ansatz, den Delta-QA nativ verwendet. Wenn ein 400x300-Pixel-Platzhalter durch ein 400x300-Pixel-Bild ersetzt wird, aendert sich die Struktur nicht -- kein Alarm. Wenn ein 400x300-Platzhalter durch ein 400x200-Bild ersetzt wird (ein Bug im Seitenverhaeltnis), aendert 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 laedt in der Regel paginierten Inhalt von einer API. Der Inhalt von Seite 2 haengt davon ab, was auf Seite 1 ist. Wenn sich der Datensatz zwischen zwei Testlaeufen aendert (ein neuer Artikel veroeffentlicht, ein Produkt entfernt), haben die Seiten nicht denselben Inhalt, und der Vergleich schlaegt fehl.
Um wiederholbare Ergebnisse zu erzielen, muessen 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 Raendern und Gruppierungen
Infinite-Scroll-Listen zeigen oft Inhalte mit Gruppierungs-Headern an -- "Heute", "Gestern", "Letzte Woche". Diese Header haengen vom aktuellen Datum ab und aendern sich von Tag zu Tag. Ein heute veroeffentlichter Artikel steht unter dem Header "Gestern" am naechsten Tag.
Die Loesung ist dieselbe wie fuer jeden zeitabhaengigen Inhalt: Frieren Sie das Systemdatum in der Testumgebung ein.
Das Problem der verschlechterten Performance
Nach 20 oder 30 aufeinanderfolgenden Scrollvorgaengen kann die Browser-Performance aufgrund der Anzahl der Elemente im DOM nachlassen. Diese Verschlechterung beeinflusst das Rendering-Timing und kann Nichtdeterminismus in Ihre Screenshots einfuehren.
Gut konzipierte Anwendungen implementieren Virtualisierung -- sie halten nur die aktuell sichtbaren Elemente im DOM und recyceln DOM-Knoten waehrend des Scrollens. Wenn Ihre Anwendung das DOM virtualisiert, bleibt die Anzahl der Elemente konstant, unabhaengig von der Anzahl der Scrollvorgaenge, und die Performance bleibt stabil.
Wenn Ihre Anwendung keine Virtualisierung verwendet, begrenzen Sie die Anzahl der Scrollvorgaenge in Ihren Tests, um im akzeptablen Performance-Bereich zu bleiben.
Praktische Empfehlungen zur Integration von Lazy Loading in Ihre visuelle Teststrategie
Fuer 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 auszuloesen, warten Sie auf die Stabilisierung und nehmen Sie auf. Definieren Sie klare Erwartungen: Alle Bilder im Viewport muessen geladen sein (keine sichtbaren Platzhalter), und nach dem Laden darf kein Layout Shift auftreten.
Fuer Komponenten mit Lazy Loading (Code Splitting, Dynamic Imports) testen Sie in zwei Modi: den Modus "alles geladen", um das Rendering der Komponenten selbst zu ueberpruefen, und den Modus "natuerliches Laden", um Uebergangszustaende und Fallbacks zu ueberpruefen.
Fuer Infinite Scroll definieren Sie einen realistischen Testumfang. Testen Sie die ersten 3 bis 5 Ladevorgaenge (Scrolls), die das Anfangsverhalten, die Paginierungslogik und den Uebergang zwischen den Chargen abdecken. Versuchen Sie nicht, den gesamten Fluss zu testen -- das ist weder praktisch noch notwendig.
Fuer Platzhalter testen Sie diese explizit. Platzhalter sind Teil der Benutzererfahrung -- ein falsch dimensionierter Platzhalter verursacht Layout Shift, ein fehlender Platzhalter hinterlaesst eine weisse Luecke auf der Seite. Nehmen Sie einen Screenshot des Anfangszustands (vor dem Scrollen) auf und ueberpruefen Sie, ob die Platzhalter korrekt dimensioniert und positioniert sind.
Fuer das Timing bevorzugen Sie bedingte Wartezeiten gegenueber festen Verzoegerungen. Warten Sie, bis die Bilder geladen sind (ueber das load-Event der img-Elemente), anstatt eine willkuerliche Anzahl von Sekunden zu warten. Feste Verzoegerungen sind fragil -- 2 Sekunden koennen lokal ausreichen und in der CI unter Last unzureichend sein.
Lazy Loading ist ein Verbuendeter, 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 fuer 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 dafuer konzipiert, diese Komplexitaet zu bewaeltigen, ohne dass Sie zwischen Performance und Testbarkeit waehlen muessen.
Lazy Loading ist kein Hindernis fuer den visuellen Test. Es ist eine technische Einschraenkung mit technischen Loesungen. Setzen Sie sie um, und Sie haben das Beste aus beiden Welten: schnelle Seiten und zuverlaessige Tests.
FAQ
Macht Lazy Loading den visuellen Full-Page-Test unmoeglich?
Nein, aber es erfordert einen anderen Ansatz als den klassischen Full-Page-Screenshot. Entweder erzwingen Sie das vollstaendige Laden (loading="eager") vor der Aufnahme, oder Sie scrollen schrittweise und erfassen jedes Segment einzeln. Beide Ansaetze bieten eine vollstaendige Abdeckung -- der erste ist einfacher, der zweite ist naeher am realen Verhalten der Seite.
Wie teste ich visuell eine Seite mit Infinite Scroll?
Definieren Sie einen realistischen Testumfang: 3 bis 5 Scrollvorgaenge decken das Anfangsverhalten, die Paginierungslogik und die Uebergaenge zwischen Chargen ab. Verwenden Sie gemockte Daten, um die Wiederholbarkeit zu gewaehrleisten. Erfassen Sie jedes Segment als unabhaengigen Screenshot mit eigener Baseline. Versuchen Sie nicht, das Unendliche zu testen -- testen Sie eine repraesentative und zuverlaessige Stichprobe.
Sollte man Lazy Loading in der Testumgebung deaktivieren?
Das haengt 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 (ueberpruefen, ob Platzhalter, Uebergaenge und verzoegertes Laden funktionieren), behalten Sie Lazy Loading aktiviert und testen Sie die verschiedenen Zustaende explizit.
Wie geht man mit dem Layout Shift um, der durch verzoegertes Laden von Bildern verursacht wird?
Definieren Sie immer explizite Abmessungen (width und height) fuer 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 aendern und keine Verschiebung auftritt.
Sind visuelle Tests mit Lazy Loading langsamer als klassische Tests?
Ja, zwangslaeufig. Das inkrementelle Scrollen mit Wartezeiten fuer das Laden bei jedem Schritt dauert laenger als eine sofortige Aufnahme einer vollstaendig geladenen Seite. Das ist der Preis fuer vollstaendige Abdeckung. Optimieren Sie durch Parallelisierung Ihrer Tests, Begrenzung der Scrollvorgaenge auf das strikt Noetige und Verwendung bedingter Wartezeiten anstelle fester Verzoegerungen, um die Wartezeit zu minimieren.
Unterstuetzt Delta-QA Lazy Loading und Infinite Scroll?
Ja. Der strukturelle Ansatz von Delta-QA ist besonders gut fuer 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 unterstuetzt inkrementelles Scrollen, Ladewartezeiten und Vergleich nach Segmenten, alles ohne eine Zeile Code.
Weiterführende Lektüre
- Visueller Test mit React, Vue und Angular: Framework-unabhaengig 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 einfuehrt. Die beiden sind nicht inkompatibel -- sie sind komplementaer. Testen Sie Ihre dynamischen Seiten mit derselben Sorgfalt wie Ihre statischen Seiten.