Warum sagt Lighthouse 87 und echtes Chrome 98?.

Die zehn Punkte Unterschied zwischen Laborwert und echtem Browser lagen nicht an der Website, sondern an einem einzigen Flag des Chrome, den das Messwerkzeug startet — und unsere erste Diagnose war falsch.

Eines Morgens blieb unser Laborwert bei 87 stehen, und unsere eigene Schwelle lag bei 88. Die Suche nach diesem einen Punkt führte uns aus dem Code der Website heraus und in den Browser hinein, den das Messwerkzeug startet. Das Ergebnis hat zwei Hälften: ein einziges Flag der Messumgebung hält das erste Bild sekundenlang zurück — und die Ursache, die wir zuerst dafür benannt haben, war falsch.

Hypothese

Der Bericht zeigte ein Labor-LCP von 3,27 Sekunden. Nach den eigenen Zeilen desselben Berichts war die Seite nach 685 ms geladen, die blockierenden Ressourcen waren nach 545 ms fertig, und der Haupt-Thread war in den ersten 2,4 Sekunden nur 202 ms beschäftigt. Die Seite war bereit; die Verzögerung lag nicht in der Bereitschaft. Genau das war die Hypothese: verspätet ist nicht die Bereitschaft, sondern die Darstellung des ersten Bildes.

Methode

Wir haben ein A/B mit einer einzigen Variablen gebaut. Lighthouse öffnet Chrome über seinen eigenen Starter, und dessen Standardliste enthält eine Zeile: ein Feature namens RenderDocument wird abgeschaltet. Wir haben die Liste nicht von Hand kopiert — wir haben sie aus dem installierten Paket gelesen, nur diesen einen Eintrag entfernt und kein weiteres Flag angefasst. Im zweiten Schritt haben wir eine minimale Seite mit demselben Symptom gebaut: ein Dokument, das nach 250 ms antwortet, eine einzige Stildatei nach 150 ms, im Körper eine Überschrift und ein Absatz.

Datum und Umgebung

1. Datum → 2026-09-21 Messung · 2026-09-22 Reproduktion
2. Werkzeug → Lighthouse 13.4.1 · Mobilprofil · Lantern
3. Browser → Chrome 153 · --headless=new · macOS
4. Objekt → Startseite dieser Website + minimale Seite

Ergebnis

Auf der Live-Startseite blieb die beobachtete erste Darstellung mit den Standard-Flags des Starters in vier Läufen bei 2.326–2.550 ms; wurde nur dieses eine Feature wiederhergestellt, sank sie auf 384–425 ms. Der Leistungswert pendelte zwischen 78–87 und 97–98, ohne dass sich auf der Website ein einziges Byte geändert hätte. Die minimale Seite zeigte dieselbe Zweiteilung. In der auslösenden Konfiguration hielten 18 von 18 Läufen an; mit eingeschaltetem Feature keiner von 12.

1. live · Standard → erste Darstellung 2.326–2.550 ms
2. live · Feature an → erste Darstellung 384–425 ms
3. minimal · Standard → 1.331–1.355 ms (bereit: 410 ms)
4. minimal · Feature an → 423–463 ms (bereit: 417 ms)

Unsere erste Diagnose war falsch

Am 21. September hielten wir den dokumentübergreifenden Seitenübergang für den Schuldigen: schaltete man den Übergang ab, verschwand das Anhalten, schaltete man ihn ein, kam es zurück. Die minimale Seite widerlegte diese Lesart — auch eine Seite ganz ohne Übergang wurde genauso angehalten. Der richtige Satz lautet: angehalten wird durch das Flag des Starters; der Seitenübergang ist nur einer der Gründe, die das erste Bild in ein zurückgehaltenes Fenster schieben. Die eigene Diagnose zu widerlegen ist ebenfalls ein Messergebnis, und es steht hier.

Die Browser-Spur schreibt die Entscheidung ausdrücklich hin. Die Bildquelle des Kompositors lehnt die Bildanforderung der Seite ab, weil sich ungezeichnete Bilder angesammelt haben; die Seite ist nach 413 ms vollständig bereit, das nächste erlaubte Bild kommt nach 1.327 ms, und die erste Darstellung fällt 17 ms dahinter. Mit eingeschaltetem Feature gibt es dieselben Ablehnungen — aber die zurückgehaltenen Fenster liegen hinter dem ersten Bild statt um es herum.

Was wir getan haben

Wir haben die Seite nicht geändert, denn es gab nichts zu ändern. Wir haben die Messung geändert: der verbindliche Laborlauf nutzt jetzt die eigenen Flags des Werkzeugs, nur dieses eine Feature wieder eingeschaltet. Die Standardzahl des Werkzeugs bleibt im Bericht und trägt dort einen offenen Namen — Juryansicht. Eine Award-Jury oder ein Kunde wird höchstwahrscheinlich diese Zahl sehen; beide Zahlen werden berichtet, keine ersetzt die andere.

Wiederholen

1. Server → Dokument 250 ms · Stildatei 150 ms verzögert
2. Lauf → lighthouse <url> --form-factor=mobile
3. --screenEmulation.mobile --throttling-method=simulate
4. Arm A → Standard-Flags des Starters
5. Arm B → dieselbe Liste, ohne RenderDocument
6. lesen → audits.metrics … observedFirstContentfulPaint

Grenzen

Warum dieses Feature die Bildbuchhaltung verändert, wissen wir nicht; wir haben nur gemessen, dass es das deterministisch tut. PageSpeed Insights selbst konnten wir nicht laufen lassen, das API-Kontingent war erschöpft; auch die Zeile der Juryansicht stammt also aus dem lokalen Werkzeug. Das Bereitschaftsband, in dem das Anhalten auftritt, haben wir abgetastet, nicht kartiert — auf einer anderen Maschine liegen seine Ränder woanders. Die Messung wurde als Beitrag zu einem offenen Bericht im Tracker von Lighthouse geschrieben; dort steht heute die Notiz: keine minimale synthetische Reproduktion gefunden.

Der Chrome des Messwerkzeugs ist nicht der Chrome der Besucherin.