First Contentful Paint (FCP)
First Contentful Paint (FCP) misst, wie lange es dauert, bis das erste Stück Inhalt, also Text, Bild, SVG oder eine nicht weiße Canvas, auf dem Bildschirm gerendert wird, nachdem der Nutzer eine Seite angefordert hat. Es ist der Moment, in dem Nutzer das erste Anzeichen dafür sehen, dass "diese Seite reagiert."
First Contentful Paint (FCP) misst, wie lange es dauert, bis das erste Stück Inhalt, also Text, Bild, SVG oder eine nicht weiße Canvas, auf dem Bildschirm gerendert wird, nachdem der Nutzer eine Seite angefordert hat. Es ist der Moment, in dem Nutzer das erste Anzeichen dafür sehen, dass "diese Seite reagiert."
Warum es wichtig ist
Nutzer, die auf einen leeren Bildschirm starren, springen schnell ab. Untersuchungen der Nielsen Norman Group zeigen, dass die Aufmerksamkeit stark abfällt, sobald die erste visuelle Reaktion eine Sekunde überschreitet. FCP ist heute kein offizieller Core Web Vital, aber eine zentrale Komponente des Lighthouse-Performance-Scores und ein Frühindikator für LCP. Wenn FCP langsam ist, kann LCP niemals gut sein.
Schwellenwerte
| Bewertung | FCP |
|---|---|
| Gut | ≤ 1,8 s |
| Verbesserungswürdig | 1,8 bis 3,0 s |
| Schlecht | > 3,0 s |
Gemessen am 75. Perzentil (p75) der Realnutzerdaten aus dem Chrome User Experience Report.
TTFB → FCP → LCP → INP
Das Laden einer Seite ist eine zeitliche Abfolge aufeinanderfolgender Metriken.
- TTFB: Zeit, bis der Server das erste Byte sendet
- FCP: Zeit, bis der erste Inhalt gezeichnet wird
- LCP: Zeit, bis das größte Inhaltselement gezeichnet wird
- INP: Zeit, bis eine Nutzerinteraktion visuell reagiert
Die Reihenfolge ist entscheidend: Wenn TTFB langsam ist, kann FCP nicht schnell sein, und auch LCP kann nicht schnell sein. Performance-Arbeit muss "von oben" beginnen.
Was FCP verlangsamt
Langsames TTFB: Ein langsamer Server verlangsamt FCP um denselben Betrag.
Render-blockierende Ressourcen: Externes CSS und synchrones JS im <head> müssen heruntergeladen und ausgeführt werden, bevor der Browser zeichnen kann. Sind es zu viele oder zu große, stockt FCP.
Große DOM-Größe: Tausende Elemente im anfänglichen HTML kosten Zeit für Parsing und Layout.
Laden von Webfonts: Noch nicht geladene benutzerdefinierte Schriften verursachen FOIT (Flash of Invisible Text) und lassen FCP verzögert wirken.
Clientseitiges Rendering (CSR): React- und Vue-Anwendungen, die Inhalte erst nach dem Herunterladen und Ausführen des JS-Bundles zeichnen, verzögern FCP erheblich.
Wie Sie optimieren
TTFB verbessern: CDN, serverseitiges Caching und Datenbankoptimierung als Grundlage.
Render-blockierende Ressourcen beseitigen: Verwenden Sie async und defer, um JS aufzuschieben. Betten Sie kritisches CSS inline ein und laden Sie den Rest asynchron.
Serverseitiges Rendering (SSR): Verwenden Sie Frameworks wie Next.js, Astro oder Remix, um HTML auf dem Server vorab zu generieren.
Schriftoptimierung: font-display: swap zeigt sofort Ersatztext an, während benutzerdefinierte Schriften laden. Verwenden Sie preload nur für kritische Schriften.
JS-Bundles verkleinern: Tree Shaking, Code Splitting und das Entfernen ungenutzter Bibliotheken senken allesamt das anfängliche Bundle.
Bildoptimierung: Verwenden Sie <link rel="preload"> für das Hero-Bild und liefern Sie WebP oder AVIF aus.
Messwerkzeuge
- PageSpeed Insights: CrUX-Felddaten + Labordaten
- Lighthouse: Diagnose auf Seitenebene
- Chrome DevTools → Performance: FCP auf der Zeitachse
- web-vitals JS-Bibliothek: Erfassen von Realnutzerdaten auf Ihrer eigenen Website
Quellen: