fastmon Docs
Web Vitals

Largest Contentful Paint (LCP)

Was LCP ist, was ein guter LCP ist und wie du einen schlechten debuggst, mit fastmon-Daten.

LCP misst, wie lange es dauert, bis das größte sichtbare Element einer Seite da ist. Das ist der Moment, in dem endlich was Sinnvolles auf dem Schirm steht.

LCP gehört zu den Core Web Vitals, Googles Standard-Set für Besuchererlebnis, und zählt fürs Suchranking.

Was ist ein guter LCP?

LCP wird in Millisekunden gemessen. Maßgeblich ist das 75. Perzentil über alle Seitenaufrufe, wie bei Google.

LCP bei p75Rating
≤ 2.500 msGut
≤ 4.000 msVerbesserungswürdig
> 4.000 msSchlecht

Was als „größtes inhaltliches Element" zählt

Der Browser verfolgt das größte Element, das im sichtbaren Viewport fertig gerendert ist. Infrage kommen:

  • <img> und <image> innerhalb von <svg>
  • <video> (der Poster-Frame)
  • Ein Element mit einer per CSS gesetzten background-image
  • Block-Level-Textknoten

Die „Größe" ist die gerenderte Fläche am Schirm, geschnitten mit dem Viewport. Off-Screen-Inhalt zählt nicht, auch wenn er größer wäre.

Das „größte" kann sich beim Laden ändern. Der Browser emittiert LCP-Einträge, bis der Besucher interagiert (Klick, Scroll, Taste). Der letzte Eintrag vor dieser Interaktion ist der LCP-Wert.

Wann LCP reportet wird

LCP wird finalisiert:

  • wenn der Besucher scrollt, klickt oder eine Taste drückt (was zuerst kommt), oder
  • wenn die Seite versteckt wird (visibilitychange).

Der Tracker schickt den finalen LCP mit seinem nächsten Batch.

Beispiele

Marketing-Seite mit Hero-Bild. LCP ist fast immer das Hero-<img>. Liegt das Bild below the fold oder ist lazy-loaded, wird stattdessen ein Textblock zum LCP, meistens schneller.

SaaS-Dashboard mit Skeleton-Loader. LCP ist erst der Skeleton-Container, dann, sobald echter Content rendert, springt's auf das größte Daten-Element. Pass auf falsch-„schnelle" LCPs auf, die nur kommen, weil eine fette Skeleton-Box davor stand.

Artikel mit eingebettetem Video. LCP ist das Video-Poster, nicht der Text. Ein leichteres Poster verbessert den LCP.

LCP in fastmon ansehen

Die LCP-Seite findest du unter Core Web Vitals → LCP. Zwei Kacheln zeigen den LCP mit Bewertung und den Anteil gemessener Seitenaufrufe.

  • Wohin die Zeit geht: Serverantwort, Load Delay, Load Duration und Render Delay als ein Balken, gegen die Zielaufteilung von web.dev.
  • Verlauf: das gewählte Perzentil vor den Bewertungszonen, eine Linie pro Phase oder eine Linie pro Seitentyp, daneben die Verteilung. Das Maximieren-Icon neben dem Teilen-Link zeigt das Diagramm im ganzen Fenster.
  • Wo der LCP schlecht ist: Seitentyp und Gerät oder eine andere Dimension, sortiert nach Seitenaufrufen über 4 s. Eine Zeile öffnet ihr eigenes Diagramm und ihren Breakdown.
  • LCP-Elemente: jedes Element mit Selektor, Art, Discovery-Pfad und Phasen. Das Detail prüft HTML, Preload, fetchpriority, Lazy Loading und Browser-Cache, und AI Prompt gibt es an einen Assistenten weiter.

Per API bekommst du dasselbe über POST /analytics/element-targets, mit fetch_priority_high_rate, lazy_rate und cache_rate pro Element.

Mit einem früheren Zeitraum vergleichen

Vergleichen im Filter-Panel setzt einen zweiten Zeitraum: Zeitraum, Tag, Woche oder Monat davor, einen eigenen Zeitraum oder ein Release gegen das davor. Der Filter-Button zeigt ihn als Chip, das × beendet ihn. Der Vergleich steckt im Link der Seite und geht auf jeder Metrik-Seite.

Mit Vergleich sagt die Zusammenfassung, was sich geändert hat, statt wie der LCP steht. Jedes Diagramm zeigt den zweiten Zeitraum neben dem ersten, und Wo der LCP schlecht ist sortiert nach der größten Verschlechterung. In der API heißt das compare_to, siehe Releases vergleichen.

Schlechten LCP verbessern

LCP zerfällt in vier Phasen, und Wohin die Zeit geht zeigt jede davon. Fang mit der größten an.

  1. TTFB. Wenn dein Time-to-First-Byte schon >1.500 ms ist, rettet keine Frontend-Optimierung deinen LCP. HTML am Edge cachen, oder statisch rendern.
  2. Resource Load Delay. Das LCP-Bild wird zu spät angefordert. Preload (<link rel="preload" as="image">) oder im HTML weiter nach oben.
  3. Resource Load Duration. Das LCP-Bild ist zu groß oder zu langsam ausgeliefert. Moderne Formate (AVIF/WebP), responsive Größen via srcset, CDN nahe deinen Besuchern.
  4. Element Render Delay. Der Browser hat die Bytes, ist aber durch render-blocking CSS oder JavaScript blockiert. Critical CSS inlinen, unkritische Scripts deferren.

Jede Phase im Detail erklärt Optimize LCP auf web.dev.

Häufige Überraschungen

  • LCP ist meistens ein Bild, kein Text. Wenn du nur an Fonts rumschraubst, verschiebst du deinen LCP wahrscheinlich kein Stück.
  • Ein lazy geladener Hero verzögert LCP. Ein lazy_rate über 0 an einem LCP-Element zeigt das.
  • background-image zählt mit. Wenn dein „Hero" ein CSS-Hintergrund ist, misst der Browser den trotzdem als LCP.

Nächste Schritte

Auf dieser Seite