LCP (Largest Contentful Paint)

LCP (Largest Contentful Paint) ist eine [Core Web Vitals](/glossary/core-web-vitals)-Metrik, die die Zeit vom Beginn des Seitenladens bis zum vollständigen Rendering des größten sichtbaren Inhaltselements im [Viewport](/glossary/viewport) misst. Dieses Element ist typischerweise ein Hero-Bild, ein großer Textblock, ein Video-Poster oder ein Hintergrundbild. Google definiert drei Leistungsbänder: **gut** (2,5 Sekunden oder weniger), **verbesserungsbedürftig** (2,5 bis 4,0 Sekunden) und **schlecht** (über 4,0 Sekunden). Der LCP wird am 75. Perzentil der Seitenladungen gemessen, was bedeutet, dass der Wert die Erfahrung der meisten realen Nutzer widerspiegelt, nicht nur der schnellsten Verbindungen.

LCP ist der wichtigste Indikator für die wahrgenommene Ladegeschwindigkeit. Während andere Metriken die technische Bereitschaft oder visuelle Stabilität messen, erfasst LCP den Moment, in dem ein Besucher den Hauptinhalt sieht — den Moment, in dem er entscheidet, dass die Seite „geladen" hat. Ein langsamer LCP lässt Besucher auf eine unvollständige Seite starren, was die Absprungrate erhöht und das Engagement verringert. Google verwendet LCP als Ranking-Signal in seinem Suchalgorithmus, was bedeutet, dass ein schlechter Wert nicht nur die Nutzererfahrung beeinträchtigt — er reduziert direkt die organische Sichtbarkeit. Für Publisher, die auf Suchverkehr angewiesen sind, kann die LCP-Optimierung den Unterschied zwischen Seite eins und dem Verschwinden in den Suchergebnissen ausmachen.

FlipLink optimiert den LCP sowohl für die Marketing-Website als auch für veröffentlichte Flipbooks. Der [Flipbook](/glossary/flipbook)-Viewer priorisiert das Rendering der Titelseite und der ersten Doppelseite, sodass das größte sichtbare Inhaltselement vor dem Laden schwerer Assets erscheint. Der [benutzerdefinierte Ladebildschirm](/features/custom-loading-screen) bietet sofortiges visuelles Feedback — ein gebrandeter Platzhalter, der in unter einer Sekunde erscheint — während [Three.js](/glossary/three-js)-Rendering-Ressourcen im Hintergrund initialisiert werden. FlipLinks [Seitenerlebnis und Layout](/features/page-experience-and-layout)-Engine wendet optimierte Bildkompression, responsive Bildgrößen und progressives Rendering an, um den LCP auf Desktop und Mobil innerhalb der von Google empfohlenen 2,5-Sekunden-Schwelle zu halten. Wenn Flipbooks auf externen Seiten [eingebettet](/glossary/embed) werden, stellt [Lazy Loading](/glossary/lazy-loading) sicher, dass das Einbettungselement nicht mit dem LCP-Element der Host-Seite konkurriert.

Das Verständnis von LCP erfordert Kontext neben verwandten Leistungsmetriken: - **Guter LCP**: 2,5 Sekunden oder weniger. Die Seite fühlt sich sofort an. Die meisten Nutzer sehen den Inhalt, bevor sie ans Verlassen denken. - **Verbesserungsbedürftig**: 2,5 bis 4,0 Sekunden. Nutzer bemerken eine Verzögerung. Absprungraten beginnen zu steigen. - **Schlechter LCP**: Über 4,0 Sekunden. Besucher verlassen wahrscheinlich die Seite, bevor der Hauptinhalt erscheint. Das LCP-Element ändert sich je nach Seite. Auf einer Produktseite ist es üblicherweise das Produktbild. Bei einem Blog-Beitrag könnte es das Hero-Banner oder der erste Textabsatz sein. Auf einer Flipbook-Seite ist es das Coverbild. Die Identifizierung des LCP-Elements auf jeder Seite ist der erste Schritt zur Optimierung.

Die LCP-Messung folgt spezifischen Regeln, die von der Web Performance Working Group definiert wurden. Das größte Element wird anhand seiner sichtbaren Größe im Viewport bestimmt, nicht anhand der Dateigröße. Für LCP berücksichtigte Elemente umfassen `<img>`-Elemente, `<image>` innerhalb von SVG, Video-Poster-Bilder, Elemente mit per CSS geladenem `background-image` und Block-Level-Elemente mit Textinhalt. Elemente, die über den Viewport hinausragen, werden nur für ihren sichtbaren Anteil gemessen. Häufige Ursachen für langsamen LCP sind nicht optimierte Bilder (ein 4-MB-Foto ausliefern, wenn ein 200-KB-WebP genügen würde), render-blockierendes CSS und JavaScript, langsame Server-Antwortzeiten ([TTFB](/glossary/core-web-vitals) über 800ms) und Client-seitiges Rendering, das JavaScript-Ausführung erfordert, bevor Inhalte erscheinen. Praktische Optimierungen umfassen: Vorabladen des LCP-Bildes mit `<link rel="preload">`, Bilder in modernen Formaten (WebP, AVIF) ausliefern, CDN für statische Assets nutzen, kritisches CSS inline einbinden, nicht-essentielles JavaScript zurückstellen und explizite `width`- und `height`-Angaben bei Bildern setzen, um Layoutverschiebungen zu vermeiden, die den LCP verzögern können.

LCP und [FCP](/glossary/core-web-vitals) (First Contentful Paint) sind beides Zeitmetriken, messen aber unterschiedliche Momente. FCP wird ausgelöst, wenn der Browser das erste Stück DOM-Inhalt rendert — selbst wenn es nur eine Navigationsleiste, ein Lade-Spinner oder eine einzelne Textzeile ist. LCP wird ausgelöst, wenn das größte Inhaltselement gerendert wird. In der Praxis wird FCP oft ein bis zwei Sekunden vor LCP ausgelöst. Eine Seite kann einen schnellen FCP, aber einen langsamen LCP haben, wenn Header und Navigation schnell laden, während das Hero-Bild mehrere Sekunden zum Erscheinen braucht. Für die Nutzererfahrung ist LCP die aussagekräftigere Metrik, da sie widerspiegelt, wann die Seite für den Besucher vollständig wirkt. FCP ist nützlich um zu diagnostizieren, ob der Browser überhaupt mit dem Rendering begonnen hat, aber LCP bestimmt, ob der Nutzer bleibt oder geht.

LCP misst den Moment, in dem deine Seite für echte Besucher als geladen empfunden wird. Halte ihn unter 2,5 Sekunden, indem du Bilder optimierst, render-blockierende Ressourcen minimierst und Above-the-Fold-Inhalte priorisierst — deine Suchrankings und das Nutzerengagement hängen davon ab.