Neu im Report: LCP-Teilzeiten und bfcache-Quote aus echten Besucherdaten

Ein Labortest lädt eine Seite einmal, von einem Standort aus, auf einem simulierten Smartphone. Er zeigt, was schiefgehen kann, aber nicht, was echte Besucher erleben. Der Report von PerfDelta enthält deshalb jetzt zwei Ansichten aus echten Smartphone-Besuchen: die vier LCP-Teilzeiten, die zeigen, wo die Zeit bis zum größten Bild verloren geht, und die bfcache-Quote, die zeigt, wie oft der Zurück-Button eine Seite sofort wiederherstellt. Beide stammen aus dem Chrome UX Report und stehen neben den Werten Ihrer Wettbewerber. So führen sie direkt zur wichtigsten Korrektur.

LCP-Teilzeiten zeigen, welche Phase echte Besucher ausbremst

Der Largest Contentful Paint misst, wann das größte Element im sichtbaren Bereich erscheint. Ist dieses Element ein Bild, zerlegt Chrome die Zeit in vier aufeinanderfolgende Teilzeiten und misst jede davon bei echten Besuchern:

1. Serverantwort: die Zeit, bis das erste Byte des HTML ankommt.
2. Ladeverzögerung: die Zeit zwischen dem HTML und dem Start der Bildanfrage.
3. Ladedauer: der Download des Bildes selbst.
4. Renderverzögerung: die Zeit zwischen dem fertigen Download und dem Moment, in dem das Bild gezeichnet wird.

Der Report zeigt diese vier Werte für Ihre Domain und Ihre Wettbewerber am 75. Perzentil, also an dem Wert, den Google für die Core Web Vitals heranzieht. Die längste Teilzeit jeder Domain ist hervorgehoben, ein gestapelter Balken macht die Anteile auf einen Blick sichtbar. Eine zusätzliche Spalte zeigt, wie oft das LCP-Element überhaupt ein Bild ist, denn nur für diese Seitenaufrufe gelten die Teilzeiten.

Die längste LCP-Teilzeit bestimmt die erste Korrektur

Mit den Teilzeiten wird aus einem vagen „der LCP ist zu langsam“ eine konkrete Aufgabe. Unsere Auswertung von 893 Websites mit langsamem LCP und Teilzeitdaten zeigt, wie unterschiedlich die Ursachen verteilt sind: Die Serverantwort war bei 45,4 Prozent die längste Teilzeit, die Ladeverzögerung bei 43,4 Prozent, die Renderverzögerung bei 8,8 Prozent und der Bild-Download nur bei 2,4 Prozent (Chrome UX Report, Smartphones, Datenzeitraum bis 26. Oktober 2026). Die Hintergründe stehen ausführlich im Artikel Langsamer LCP: Ladeverzögerung und Serverantwort sind in neun von zehn Fällen die Ursache.

Je nach längster Teilzeit ist ein anderer Ratgeber der richtige Einstieg:

• Serverantwort: Seiten-Cache, Content Delivery Network und weniger Weiterleitungen. Details im Ratgeber zur Time to First Byte.
• Ladeverzögerung: Das Bild gehört ins HTML, ohne loading="lazy" und mit fetchpriority="high". Wann ein Preload-Hinweis nötig ist, zeigt der Ratgeber zu Preconnect und Preload.
• Ladedauer: kleinere Dateien und moderne Formate, erklärt im Ratgeber zur Bildübermittlung.
• Renderverzögerung: weniger Stylesheets und Skripte, die das Zeichnen blockieren, siehe renderblockierende Ressourcen.

Der Laborteil des Reports zeigt weiterhin für jede getestete Seite das LCP-Element mit eigener Aufschlüsselung. Zusammen zeigen beide Ansichten, ob ein im Labor gefundenes Problem auch echte Besucher trifft.

Die bfcache-Quote zeigt, wie schnell der Zurück-Button wirkt

Eine zweite Karte im Report heißt Navigation und Netz. Sie zeigt, wie echte Smartphone-Besucher auf Ihre Seiten kommen: den Anteil der Zurück- und Vor-Navigationen, den Anteil neu geladener Seiten, den Anteil vorab gerenderter Seitenaufrufe und die Netzlaufzeit Ihres Publikums. Der wichtigste Wert darin ist die bfcache-Quote.

Der Back/Forward-Cache bewahrt eine vollständige Momentaufnahme einer Seite im Arbeitsspeicher auf. Geht ein Besucher zurück, stellt der Browser die Momentaufnahme sofort wieder her, statt die Seite neu zu laden. Die Quote zeigt, welcher Anteil der Zurück- und Vor-Navigationen tatsächlich so bedient wurde. Bei der mittleren Website unserer Stichprobe waren es 59 Prozent, jede vierte Website blieb unter 25 Prozent. Ein niedriger Wert hat fast immer eine konkrete Ursache, meist einen Header Cache-Control: no-store im HTML oder eine Verbindung, die beim Verlassen der Seite noch offen ist. Den genauen Grund je Seite nennen die Chrome DevTools.

Der Wochenverlauf zeigt, ob eine bfcache-Korrektur wirkt

Laborwerkzeuge prüfen, ob eine einzelne Seite für den bfcache geeignet ist. Ob Besucher davon profitieren, zeigen erst die Felddaten. Der Report zeigt deshalb bfcache-Quote und Anteil der Zurück- und Vor-Navigationen Ihrer Domain Woche für Woche. Jeder Punkt fasst die 28 Tage bis zur jeweiligen Woche zusammen. Nach einer Korrektur steigt die Quote über etwa vier Wochen schrittweise an, weil neue Besuche die älteren im Zeitraum ablösen.

Für die LCP-Teilzeiten gilt dasselbe: Der allgemeine Verlauf der Felddaten im Report zeigt, wie sich der LCP Ihrer Domain nach einer Änderung entwickelt.

Werte der Wettbewerber ordnen LCP-Teilzeiten und bfcache-Quote ein

Ein absoluter Wert allein ist schwer zu bewerten. Ist eine Serverantwort von 900 Millisekunden ein Problem? Ist eine bfcache-Quote von 40 Prozent normal? Der Report stellt Ihre Domain deshalb neben ihre Wettbewerber. Erreicht ein Wettbewerber im selben Markt eine deutlich höhere bfcache-Quote, liegt die Ursache selten am Publikum und meist an der Website. Bei der Netzlaufzeit gilt das Gegenteil: Ein höherer Wert als beim Wettbewerber spricht für ein langsameres Publikum, nicht zwingend für eine langsamere Website.

LCP-Teilzeiten und bfcache-Daten im Report finden

Beide Karten stehen im Kapitel zu echten Nutzern, in jedem Report, für dessen Domain der Chrome UX Report Daten hat. Starten Sie mit einem kostenlosen Website Speed Test. Ohne Test vergleicht der Core Web Vitals Benchmark dieselben Feldwerte für bis zu fünf Websites nebeneinander.

Grenzen der Felddaten

• Genug Besucher: Der Chrome UX Report enthält nur Domains mit ausreichend vielen Chrome-Besuchen. Kleinere Websites haben unter Umständen gar keine Felddaten.
• Nur Bild-LCP: Die Teilzeiten gibt es nur für Seitenaufrufe, bei denen das LCP-Element ein Bild ist.
• 75. Perzentil je Teilzeit: Jede Teilzeit ist an ihrem eigenen 75. Perzentil gemessen. Die vier Werte ergeben in der Summe nicht genau den LCP.
• Ganze Domain, 28 Tage: Die Werte beschreiben alle Seiten der Domain über die letzten 28 Tage, nicht eine einzelne URL an einem einzelnen Tag.
• Nur Chrome: Besuche aus Safari und Firefox sind nicht enthalten.