Layoutverschiebung beim Scrollen: ein blinder Fleck.

Die klassische Messung der Layoutverschiebung schaut auf das Ladefenster der Seite; Verschiebungen nach dem Beginn des Scrollens sind in diesem Fenster unsichtbar.

Diese Seite ist keine Theorie, sondern das Protokoll eines auf dieser Website durch Messung gefundenen Fehlers. Und lehrreicher als der Fehler selbst ist, wie er gefunden wurde — denn kein allgemeines Prüfwerkzeug zeigte ihn.

Die Lage: Die beim Laden gemessene Verschiebung lag sehr nahe null, und jedes Werkzeug gab Grün. Aber begann der Nutzer zu scrollen, entstand beim Loslassen eines fixierten Abschnitts eine sichtbare Verschiebung. Zwei Wahrheiten galten zugleich: Die Metrik war gut, und das Erlebnis war schlecht.

Warum es sich nicht zeigt

Prüfwerkzeuge öffnen die Seite, warten aufs Laden und berichten die in diesem Fenster angesammelte Verschiebung. Sie scrollen nicht — denn Scrollen ist ein Nutzerverhalten, und es zu simulieren ist kein Standardschritt. Keine vom Scrollen ausgelöste Verschiebung geht also in diese Messung ein.

In den Felddaten zeigen sich diese Verschiebungen, denn echte Nutzer scrollen. Aber Felddaten sind aggregiert und verzögert; sie sagen nicht, aus welchem Abschnitt eine Verschiebung kam. Das Problem taucht also als Zahl in den Felddaten auf, in der Labormessung nie — und dazwischen bleibt eine Diagnoselücke.

Die Lücke ist kein fehlendes Werkzeug, sondern eine fehlende Frage. Das Werkzeug fragte „verschiebt es sich beim Laden“ und antwortete richtig. „Verschiebt es sich beim Scrollen“ fragte niemand.

Die Metrik war gut und das Erlebnis schlecht; beides stimmte, denn die Metrik stellte diese Frage nicht.

Fixierte Abschnitte

Die Quelle der Verschiebung war ein mit dem Scrollen synchronisiertes Fixierverhalten. Ein Abschnitt wird auf dem Bildschirm festgehalten, der Inhalt ändert sich beim Weiterscrollen, und beim Loslassen kehrt der Abschnitt in den Seitenfluss zurück. In diesem Moment der Rückkehr wird sein Platz neu berechnet, und der Inhalt darunter verschiebt sich.

Das ist ein klassischer Nebeneffekt von Bewegungsbibliotheken und entsteht fast immer aus derselben Ursache: Das Fixieren geschieht, indem das Element aus dem Dokumentfluss genommen und zurückgesetzt wird. Die alternative Methode — das Element im Fluss lassen und nur mit der Transform-Eigenschaft bewegen — berührt das Layout nie und erzeugt keine Verschiebung.

Die Korrektur ging in diese Richtung und wurde mit zwei getrennten Wächtern verriegelt. Der erste misst das Problem direkt: Die Verschiebung in den Momenten des Fixierens und Loslassens muss unter 0,01 bleiben. Der zweite ist allgemeiner: Über das ganze Scrollen muss das mit Googles Sitzungsfenster-Logik berechnete schlechteste Fenster unter 0,08 bleiben — mit bewusstem Abstand unter Googles guter Schwelle von 0,1.

Wie man es misst

Diese Messung einzurichten braucht kein besonderes Werkzeug; der eigene Verschiebungsbeobachter des Browsers genügt. Der Unterschied liegt im Wann: nicht im Ladefenster, sondern während des Scrollens.

1. Die Seite öffnen und das Laden abwarten — die Anfangsverschiebung getrennt messen.
2. Den Beobachter zurücksetzen — ab jetzt zählt die Scrollverschiebung.
3. Programmatisch scrollen — in Schritten nahe der echten Nutzergeschwindigkeit, über die ganze Seite.
4. Die Verschiebungen in Fenster teilen — mit Googles Sitzungsfenster-Logik; das schlechteste Fenster nehmen.
5. An eine Schwelle binden — ein Ziel unter der offiziellen Schwelle setzen, damit die Regression früh sichtbar wird.
6. Bei jedem Deployment laufen lassen — einmal messen und weitergehen bricht bei der nächsten Bewegungsergänzung.

Der vierte Punkt ist kritisch: Dass die Fensterlogik mit Googles eigener identisch ist, garantiert, dass der Test wirklich dasselbe misst. Ein Test, der die Gesamtverschiebung misst, leuchtet auf langen Seiten grundlos rot und wird nach einer Weile ignoriert.

Die allgemeine Lehre

Was dieser Fall wirklich lehrt, ist nicht die Fixiertechnik, sondern die Prüfmethode. Ein grüner Bericht ist die Antwort auf die gestellten Fragen — über die nicht gestellten sagt er nichts. Und zu wissen, welche Frage ein Werkzeug stellt, ist die Verantwortung des Prüfenden.

Dasselbe Muster spielte sich auf dieser Website auch auf der Barrierefreiheitsseite ab: Ein Kontrastkriterium wurde von keinem Werkzeug getestet, und in dieser Lücke lebte ein echter Fehler. Zwei Fälle in verschiedenen Feldern, eine Lehre.

Die praktische Folge: Lesen Sie den Umfang jedes Messwerkzeugs einmal, listen Sie die nicht abgedeckten Kriterien und verwandeln Sie diese Liste in eigene Tests. Die Lücke der allgemeinen Werkzeuge schließt sich mit projektspezifischen Wächtern — anders schließt sie sich nicht.

Ähnliche blinde Flecken

Das Muster dieses Falls ist nicht auf eine Metrik begrenzt, und mit derselben Logik lassen sich weitere blinde Flecken jagen. Die gemeinsame Frage: In welchem FENSTER wird diese Metrik gemessen, und was geschieht außerhalb?

1. Interaktionsreaktivität — die Messung verlangt echte Interaktion; in einem Test ohne jede Interaktion zeigt sie sich nie.
2. Lange Aufgaben — periodische Arbeit nach dem Seitenladen fehlt im Ladefenster.
3. Speicherlecks — sie sammeln sich in langen Sitzungen; ein einzelnes Seitenöffnen zeigt nichts.
4. Scroll-Performance — Frame-Einbrüche entstehen nur beim Scrollen.
5. Eingebettete Inhalte — bei Nutzerinteraktion ladende Ressourcen fehlen in der ersten Messung.

Die Gemeinsamkeit der fünf Punkte: Alle entstehen in echter Nutzung und zeigen sich in einem Standard-Öffnungstest nie. Das zeigt die Grenze der automatischen Prüfung erneut: Das Werkzeug misst ein Szenario und schweigt über alles außerhalb.

Auf dieser Website werden die Verschiebung beim Scrollen und das Frame-Budget mit eigenen Tests gemessen; beides sind Fragen, die Standardwerkzeuge nicht abdecken. Die Frame-Budget-Schwellen leiten sich vom Ziel von sechzig Bildern pro Sekunde ab: Median unter 12 Millisekunden, 95. Perzentil unter 24.

Zum Abschluss ein Methodenvorschlag: Der produktivste Weg, auf der eigenen Website blinde Flecken zu jagen, ist die echten Nutzungsszenarien zu schreiben und bei jedem Schritt zu fragen, welche Metrik gemessen wird. Der Nutzer öffnet die Seite, scrollt, drückt einen Button, öffnet eine Ebene, geht zurück — welches Werkzeug misst was bei jedem Schritt? Die ungemessenen Schritte sind die Liste der blinden Flecken, und diese Liste wird direkt zu neuen Tests.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist für die Mess-Blindflecken Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. In welchem Fenster wird diese Metrik gemessen?
2. Was geschieht außerhalb dieses Fensters — Scrollen, Interaktion, lange Sitzung?
3. Interagiert das Werkzeug mit der Seite — wenn nicht, fehlen die Interaktionsmetriken.
4. Wurde ein echtes Nutzungsszenario geschrieben — welches Werkzeug misst was bei jedem Schritt?
5. Wurden die ungemessenen Schritte gelistet — diese Liste ist der Plan der neuen Tests.
6. Wurde jeder gefundene Fehler an einen Test gebunden?

Der sechste Punkt ist die Zusammenfassung der Arbeitsweise dieser Website: Einen Fehler zu beheben beseitigt ihn einmal; einen Wächter zu ergänzen verhindert seine Rückkehr.