Ein A/B-Test soll herausfinden, welche Variante besser wirkt. Damit der Besucher nicht erst die alte und dann die neue Fassung sieht, verstecken viele Aufbauten die ganze Seite, bis das Testwerkzeug entschieden hat. Genau dieser Griff kostet die Kennzahl, an der derselbe Test hinterher gemessen wird. Der klassische Ausblendschnipsel nimmt sich dafür bis zu 3.000 Millisekunden (Herstellerdokumentation) Zeit, bevor er die Seite von selbst wieder freigibt – und bis dahin gibt es nichts zu sehen. Auf dem Handy erreichen ohnehin nur 62 Prozent (Web Almanac 2025) der Seiten einen guten Largest Contentful Paint. Eine Ausblendschicht schiebt genau diesen Messpunkt weiter nach hinten, weil ein unsichtbares Element für den Browser gar kein Kandidat ist. Dieser Beitrag zeigt, wie der Zusammenhang technisch entsteht, welche Zahlen dahinterstehen und wie sich ein Test ausliefern lässt, ohne den ersten Anstrich zu opfern. In unserer Frontend-Optimierung ist die Testschicht einer der Posten, die wir als Erstes aufnehmen.
Das Wichtigste in Kürze
- Flimmern entsteht, weil die Grundfassung schon steht, wenn das Testskript antwortet. Der übliche Gegengriff versteckt die Seite auf Verdacht – der Ausblendschnipsel eines Herstellers gibt sie nach 3.000 Millisekunden (Herstellerdokumentation) von selbst wieder frei.
- Die Ausblendung verschiebt nicht nur den Eindruck, sondern die Messung: Chromium schließt Elemente mit einer Deckkraft 0 (web.dev) als LCP-Kandidaten aus. Der Messpunkt wandert damit an das Ende der Ausblendung.
- Das trifft die Kennzahl an der empfindlichsten Stelle, denn auf 76 Prozent (Web Almanac 2025) der mobilen Seiten ist das LCP-Element ein Bild – also genau das Element, das die Schicht verdeckt.
- Gezieltes Blockieren ist die sauberere Alternative:
blocking="render"steht seit Chrome 105 (MDN) und Safari 18.2 (MDN) bereit, in Firefox ist es nicht umgesetzt. Der Standard kennt dafür genau ein Schlüsselwort (WHATWG). - Ohne Messung bleibt jede Entscheidung Geschmackssache. Nur 15 Prozent (Web Almanac 2025) der mobilen Seiten bestehen die Prüfung auf renderblockierende Ressourcen – ein Testskript kommt also selten in eine aufgeräumte Lage.
Warum ein Test die Seite unsichtbar macht
Der Ablauf ist in fast jedem Aufbau derselbe. Das Dokument kommt vom Server, der Browser beginnt zu zeichnen, und erst danach meldet sich das Testwerkzeug mit der Entscheidung, welche Variante dieser Besucher sehen soll. Zwischen dem ersten Anstrich und dem Umbau liegt ein sichtbarer Sprung: Die Überschrift wechselt, der Knopf ändert die Farbe, ein Bereich verschwindet. Fachlich heißt das Aufblitzen der Grundfassung, im Alltag heißt es Flimmern. Es ist kein Fehler des Werkzeugs, sondern die Folge einer Reihenfolge – der Browser ist schneller fertig als die Entscheidung. Weil dieser Sprung im Nutzertest sofort auffällt, greifen viele Aufbauten zum einfachsten Gegenmittel: Sie machen die Seite unsichtbar, bis die Entscheidung da ist. Wie stark solche vorgeschalteten Schichten den ersten Eindruck verschieben, zeigt in ähnlicher Form der Beitrag zu Einwilligungsbannern und den Core Web Vitals.
Technisch ist der Griff denkbar schlicht. Ein kleiner Schnipsel im Dokumentkopf setzt eine Klasse auf das Wurzelelement, eine Regel setzt daraufhin die Deckkraft des Rumpfes auf null, und das Testskript entfernt die Klasse wieder, sobald es fertig ist. Damit die Seite bei einem Ausfall nicht dauerhaft leer bleibt, hängt an dem Schnipsel ein Zeitüberlauf. Genau dieser Wert ist der Kern des Problems: Die Herstellerdokumentation zum Vorab-Ausblenden nennt 3.000 Millisekunden (Herstellerdokumentation) als Standardfrist, nach der sich die Schicht selbst entfernt. Das ist die obere Wartezeit, nicht die übliche – aber sie ist die Zusage, die der Aufbau dem Besucher macht. Bleibt die Antwort des Werkzeugs aus, weil das Netz schlecht ist oder eine Sperrliste die Adresse blockt, sieht der Besucher bis zu drei Sekunden lang eine weiße Fläche.
Flimmern ist ein Symptom, keine Ursache
Was die Ausblendschicht mit dem LCP macht
Der Zusammenhang ist nicht bloß gefühlt, er steht in der Auswahlregel des Browsers. Für den Largest Contentful Paint sucht Chromium das größte Element im sichtbaren Bereich – und schließt dabei ausdrücklich Elemente mit einer Deckkraft 0 (web.dev) aus, weil sie für den Nutzer unsichtbar sind. Solange die Ausblendschicht liegt, gibt es also keinen gültigen Kandidaten. Der Zähler läuft trotzdem, denn gemessen wird ab dem Beginn der Navigation. Sobald die Schicht fällt, wird das größte sichtbare Element registriert – mit der bis dahin verstrichenen Zeit. Aus einem LCP von einer Sekunde wird so ohne jede Änderung am Inhalt einer von zwei oder drei Sekunden. Als guter Wert gelten 2,5 Sekunden (web.dev), und zwar nicht im Mittel, sondern für 75 Prozent (web.dev) der Seitenaufrufe. Wie sich die vier Teilzeiten dahinter einzeln aufschlüsseln lassen, beschreibt der Beitrag zu den vier Phasen des LCP.
Besonders unangenehm wird das, weil die Schicht meist genau das Element trifft, auf das es ankommt. Auf 76 Prozent (Web Almanac 2025) der mobilen Seiten ist das LCP-Element ein Bild, also das Kopfbild, das Produktfoto oder die Bühne. Kommen zwei selbstgemachte Bremsen zusammen, addiert sich der Schaden: 16 bis 17 Prozent (Web Almanac 2025) der Seiten laden ihr LCP-Bild verzögert, und nur 17,3 Prozent (Web Almanac 2025) der mobilen Seiten mit LCP-Bild setzen die hohe Abrufpriorität. Wer zusätzlich eine Ausblendschicht darüberlegt, verschiebt ein Element, das ohnehin zu spät kommt. Welche Stellschrauben hier greifen, ordnet der Beitrag zu Priority Hints und fetchpriority ein. Der erste Anstrich leidet übrigens genauso: Als guter First Contentful Paint gelten 1,8 Sekunden (web.dev) – eine Seite, die drei Sekunden unsichtbar bleibt, reißt diese Marke, bevor irgendein Inhalt geladen ist.
// Misst, wie lange die Ausblendschicht den Bildaufbau zurückhält -- und welchen
// Kandidaten der Browser danach als Largest Contentful Paint einträgt.
const marken = [];
new PerformanceObserver((liste) => {
for (const eintrag of liste.getEntries()) {
marken.push({
kennzahl: 'LCP',
zeit: Math.round(eintrag.startTime),
element: eintrag.element ? eintrag.element.tagName : '(kein Element)'
});
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
new PerformanceObserver((liste) => {
for (const eintrag of liste.getEntries()) {
if (eintrag.name === 'first-contentful-paint') {
marken.push({ kennzahl: 'FCP', zeit: Math.round(eintrag.startTime) });
}
}
}).observe({ type: 'paint', buffered: true });
// Der Moment, in dem die Testschicht die Seite wieder freigibt. Der Klassenname
// stammt aus dem eigenen Ausblendschnipsel und ist je Aufbau anzupassen.
const wurzel = document.documentElement;
const waechter = new MutationObserver(() => {
if (!wurzel.classList.contains('test-ausblenden')) {
marken.push({ kennzahl: 'Seite freigegeben', zeit: Math.round(performance.now()) });
waechter.disconnect();
}
});
waechter.observe(wurzel, { attributes: true, attributeFilter: ['class'] });
// Erst beim Verlassen ausgeben: vorher ist der LCP-Eintrag nicht endgültig.
addEventListener('pagehide', () => console.table(marken));Der Ausschnitt beantwortet die einzige Frage, die vor jeder Entscheidung steht: Wie viel Zeit liegt zwischen dem Laden des Dokuments und dem Moment, in dem die Testschicht die Seite wieder freigibt – und welches Element trägt danach den LCP? Interessant ist dabei weniger der Einzelwert als die Verteilung. Ein Labordurchlauf auf einer schnellen Leitung zeigt die Schicht selten von ihrer schlechten Seite; erst die Werte aus dem Feld machen den Zeitüberlauf sichtbar, weil dort auch die Aufrufe landen, bei denen die Antwort des Werkzeugs ausgeblieben ist. Warum sich Feld- und Labordaten nicht ersetzen, sondern ergänzen, beschreibt der Beitrag zu Felddaten und Labormessung nebeneinander. Und weil der Zeitüberlauf im Feld selten, aber teuer eintritt, gehört er als eigene Verteilung ausgewertet, nicht als Mittelwert.
Die Lage, in die ein Testskript hineinkommt
Ein Testwerkzeug landet selten auf einer aufgeräumten Seite. 90 bis 92 Prozent (Web Almanac 2025) aller Seiten binden mindestens einen Drittanbieter ein, und die mittlere mobile Seite fordert bereits 79 Anfragen (Web Almanac 2025) an fremde Ursprünge an. Skripte stellen dabei den größten Block: 24,8 Prozent (Web Almanac 2025) aller Drittanbieter-Anfragen. Dazu kommt die Verschachtelung – die mittlere Tiefe der Einbindungskette liegt bei 3 (Web Almanac 2025), ein eingebundenes Werkzeug lädt also in der Regel weitere Werkzeuge nach. Wie sich dieser Bestand systematisch ausdünnen lässt, beschreibt der Beitrag zum Entschlacken von Drittanbieterskripten. Für den Testaufbau heißt das: Das Testskript ist nicht der einzige Gast, aber häufig der einzige, der die Anzeige der Seite an sich bindet.
Die Wartezeit ist die Zusage
Ein Zeitüberlauf ist kein Sicherheitsnetz, sondern eine Obergrenze für Blindzeit. Was als Ausnahme gedacht ist, wird für einen Teil der Aufrufe zum Regelfall – und zwar für die auf langsamen Netzen, deren Werte in der Auswertung ohnehin am schlechtesten sind.
Der Hauptthread ist schon belegt
Der mittlere Blockierzeitwert liegt mobil bei 1.916 Millisekunden (Web Almanac 2025). Ein synchron geladenes Testskript legt sich obenauf – jede Aufgabe über 50 Millisekunden (Chrome for Developers) gilt als lange Aufgabe und verschiebt die Reaktion auf Eingaben.
Der Test misst sich selbst mit
Verschiebt die Ausblendung den Anstrich in beiden Varianten gleich, bleibt der Vergleich zwar sauber. Die absolute Wirkung auf Umsatz und Abbruchquote misst der Test aber gegen eine Seite, die er selbst verlangsamt hat – der Gewinn der besseren Variante wird damit unterschätzt.
| Aufbau | Was der Besucher bis dahin sieht | Wirkung auf den LCP | Verhalten bei Ausfall |
|---|---|---|---|
| Ganze Seite verstecken, Skript asynchron | nichts | Messpunkt wandert an das Ende der Ausblendung | leere Seite bis zum Zeitüberlauf |
| Testskript gezielt renderblockierend | nichts, aber deutlich kürzer | Messpunkt hängt an der Dauer des Skripts | Browser zeichnet nach eigenem Zeitlimit |
| Variante vor der Auslieferung entschieden | die fertige Variante | unverändert | Grundfassung wird ausgeliefert |
| Test auf Bereiche unterhalb des Fensters begrenzt | den echten Kopfbereich | unverändert | Bereich bleibt in der Grundfassung |
| LCP-Element aus dem Test herausgehalten | den echten Kopfbereich | unverändert | kein Einfluss auf die Anzeige |
Gezielt blockieren statt alles verstecken
Die Plattform bietet für genau diesen Fall ein eigenes Mittel an. Mit dem Attribut blocking="render" lässt sich ein Skript so einbinden, dass der Browser den Bildaufbau erst nach dessen Ausführung beginnt – ohne dass die Seite dafür versteckt werden muss. Der Unterschied ist keine Kosmetik: Statt einer festen Frist von drei Sekunden hängt die Verzögerung an der tatsächlichen Dauer des Skripts, und der Browser behält die Kontrolle über den Zeitpunkt des ersten Anstrichs. Der Standard hält dazu fest, dass ein blockierendes Attribut ausdrücklich anzeigt, welche Vorgänge am Abruf einer externen Ressource hängen; die Liste der möglichen Werte enthält genau ein Schlüsselwort (WHATWG). Mehr Steuerung gibt die Plattform nicht her – was die Sache übersichtlich hält, aber auch bedeutet, dass es keine Feinabstufung nach Bereichen gibt.
Die Verfügbarkeit ist der Haken. Die Kompatibilitätsdaten weisen das Attribut am Skriptelement ab Chrome 105 (MDN) und ab Safari 18.2 (MDN) aus; für Firefox steht dort version_added: false (MDN), auch am Link-Element für Stylesheets und Vorlade-Verweise. Wer sich allein darauf verlässt, hat für einen Teil der Besucher wieder genau die Ausgangslage: Skript kommt später, Seite ist schon gezeichnet, Sprung sichtbar. Praktikabel ist deshalb ein zweistufiger Aufbau – gezieltes Blockieren, wo es unterstützt wird, und ein enger gefasster Rückfallweg dort, wo es fehlt. Historisch ist das nicht neu: Parserblockierende Fremdskripte über document.write waren so schädlich, dass der Browserhersteller eingegriffen hat; betroffen waren nach dessen Messung 7,6 Prozent (Chrome for Developers) aller Seitenaufrufe im 2G-Netz.
Der Kern in einem Satz
Wo das Schlüsselwort fehlt: der zweite Weg
Der belastbarste Ausweg verlegt die Entscheidung vor die Auslieferung. Wird die Variante bereits beim Zusammenbauen der Antwort gewählt – am Server oder an der Auslieferungsschicht davor --, kommt beim Browser nur eine Fassung an. Es gibt kein Flimmern, weil es nichts zu ersetzen gibt, und keine Ausblendschicht, weil nichts nachträglich umgebaut wird. Der Preis dafür ist Zeit an einer anderen Stelle: Die Variantenauswahl liegt dann im kritischen Pfad der Serverantwort, und dort ist wenig Luft. Nur 44 Prozent (Web Almanac 2025) der mobilen Seiten haben einen guten Wert für die Zeit bis zum ersten Byte. Wo diese Zeit im Backend tatsächlich hingeht, lässt sich mit den Mitteln aus dem Beitrag zur Server-Antwortzeit aufschlüsseln. Zweiter Preis: Die Antwort wird für jede Variante eigen, und die Zwischenspeicherung muss das abbilden, statt sie unbrauchbar zu machen.
Drei Muster, die einen Test teuer machen
Ein Vorgehen, das im Bestand funktioniert
Im laufenden Betrieb ist der große Umbau selten die richtige Wahl, denn die Testschicht hängt an Prozessen, die nicht in der Entwicklung liegen. Sinnvoller ist eine Reihenfolge, die mit dem größten Hebel beginnt und jeden Schritt einzeln belegt. Als Bezugsgröße lohnt der Blick auf das Gesamtbild: Nur 48 Prozent (Web Almanac 2025) der mobilen Seiten bestehen alle Core Web Vitals, und die mittlere mobile Startseite wiegt 2,56 MB (Web Almanac 2025) bei 646 KB (Web Almanac 2025) JavaScript und 22 Anfragen (Web Almanac 2025) für Skripte. Ein Testwerkzeug kommt also zu einem gut gefüllten Wagen hinzu. Wie sich eine Obergrenze dafür festschreiben lässt, beschreibt der Beitrag zu Performance-Budgets für JavaScript.
- Bestand aufnehmen: Welche Tests laufen, auf welchen Vorlagen, mit welchem Ausblendmechanismus und mit welchem Zeitüberlauf? Häufig laufen Tests weiter, deren Auswertung längst abgeschlossen ist.
- Den Ausblendbereich verkleinern: Statt des gesamten Rumpfes nur den Ausschnitt verdecken, den der Test wirklich verändert – damit bleibt der LCP-Kandidat sichtbar und die Messung ungestört.
- Das LCP-Element aus dem Test herausnehmen. Wo die Kopfbühne selbst getestet werden soll, gehört die Entscheidung vor die Auslieferung und nicht in ein nachgeladenes Skript.
- Wo unterstützt, das Testskript gezielt renderblockierend einbinden und den Zeitüberlauf der Ausblendung deutlich unter die Herstellervorgabe setzen – der Rückfallweg ist die Grundfassung, nicht die leere Seite.
- Vorher und nachher im Feld messen, getrennt nach Variante und Gerät, und die Testschicht als eigene Position in das Budget aufnehmen, wie es der Beitrag zu Budgets im Bauprozess beschreibt.
Bei der Bewertung hilft ein nüchterner Blick auf die Kennzahlen, die ein Test tatsächlich berührt. Der Layoutsprung ist selten das Problem: 81 Prozent (Web Almanac 2025) der mobilen Seiten haben einen guten CLS-Wert. Die Reaktionszeit hingegen leidet mit, wenn das Testskript den Hauptthread belegt – mobil erreichen 77 Prozent (Web Almanac 2025) einen guten INP-Wert, am Schreibtisch sind es 97 Prozent (Web Almanac 2025). Wie sich lange Aufgaben aufteilen lassen, damit der Browser dazwischen zeichnen kann, zeigt der Beitrag zum Aufteilen langer Aufgaben. Auch im Laborwert schlägt sich das nieder: Der grüne Bereich beginnt erst bei 90 bis 100 (Chrome for Developers) Punkten, und wie ein solcher Bericht zu lesen ist, ohne ihn von oben nach unten abzuarbeiten, beschreibt der Beitrag zum Lesen eines Lighthouse-Berichts.
Ein Test, der die Seite drei Sekunden lang unsichtbar macht, misst nicht mehr die Wirkung der Variante. Er misst, wie viele Besucher bereit sind, auf sie zu warten.
Wirtschaftlich lässt sich der Zielkonflikt beziffern. Eine Auswertung mobiler Seitendaten aus Handel, Reise und Leadgenerierung fand, dass 0,1 Sekunden kürzere Ladezeit die Abschlussquote im Handel um 8,4 Prozent (Deloitte, im Auftrag von Google) gehoben haben. Ein Test, der eine halbe Sekunde kostet, muss diesen Effekt erst wieder einspielen, bevor er überhaupt einen Gewinn zeigt. Besonders spürbar ist das dort, wo Tests am häufigsten laufen: 19,2 Prozent (Web Almanac 2025) der untersuchten mobilen Seiten sind Läden. Wie sich Anforderungen an das Tempo verbindlich festhalten lassen, statt sie im Nachhinein zu verhandeln, beschreibt der Beitrag zu Performance in der Ausschreibung; und dass die Wirkung auf schwacher Hardware anders ausfällt als auf dem Entwicklungsrechner, zeigt der Beitrag zum Zielgerät statt Testgerät.
Damit ist der Umgang mit Tests weniger eine Werkzeugfrage als eine Frage der Reihenfolge. Wer die Variantenauswahl so früh wie möglich trifft, den verdeckten Bereich so klein wie möglich hält und das LCP-Element aus dem Zugriff des Skripts nimmt, kann testen, ohne die Ladezeit als Pfand zu hinterlegen. Wo genau die Zeit bleibt und welche Vorlage die schlechtesten Werte liefert, klärt eine technische Performance-Analyse mit Feld- und Labordaten nebeneinander – und wie sich die Ergebnisse in den Kennzahlen niederschlagen, die Suchmaschinen und Besucher gleichermaßen bewerten, ordnet unsere Seite zu den Core Web Vitals ein.
Quellen und Studien
Verwandte Artikel
fetchpriority: LCP mit Priority Hints beschleunigen
Wie fetchpriority='high' das LCP-Bild früher lädt: korrekte Anwendung, Zusammenspiel mit preload und srcset, die häufigsten Fehler und der LCP-Quick-Win.
Critical CSS: Sichtbarer Bereich in Millisekunden
Critical CSS extrahieren, inline einbinden und automatisieren. So laden Sie den sichtbaren Bereich in Millisekunden und verbessern LCP nachhaltig.
Style-Recalculation: wenn CSS erst im Browser bremst
Warum Stilberechnung zur Laufzeit Zeit kostet, wie Selector Stats und Long Animation Frames den Anteil sichtbar machen und welche Eingriffe den Umfang senken.