First Contentful Paint (FCP) verstehen
Was First Contentful Paint misst, welcher FCP-Wert gut ist, warum FCP kein Core Web Vital ist, wie sich FCP von First Paint und LCP unterscheidet und wie Sie einen langsamen Wert beheben.
Sprachen
First Contentful Paint (FCP) ist die Zeit vom Beginn des Ladens einer Seite bis zum ersten Rendern eines beliebigen Teils ihres Inhalts — Text, Bild, SVG oder nicht weißes Canvas. Gut ist ≤ 1,8 s am 75. Perzentil echter Nutzer. FCP ist KEIN Core Web Vital: Die Ranking-Signale sind LCP, INP und CLS. FCP ist eine diagnostische Metrik aus Labor und Feld und ein Baustein von LCP — FCP tritt gleichzeitig mit oder vor LCP auf — und hilft vor allem beim Erkennen renderblockierender Ressourcen und einer langsamen TTFB. In Lighthouse 10 macht FCP 10 % des Performance-Scores aus. Beheben Sie den Wert durch das Entfernen renderblockierenden CSS/JS, das Verkürzen der TTFB, Inline-CSS für kritische Bereiche, font-display: swap und Preconnect zu benötigten Origins.
TL;DR — First Contentful Paint (FCP) ist der Moment, in dem ein Besucher den ersten Teil Ihrer Seite sieht — beliebigen Text, ein Bild oder eine Grafik — statt eines leeren weißen Bildschirms. Schneller ist besser; unter 1,8 Sekunden gilt als „gut“. Es ist eine nützliche Geschwindigkeitsprüfung, aber keine der Metriken, die Google fürs Ranking verwendet.
Was FCP tatsächlich ist
Wenn jemand auf einen Link zu Ihrer Seite klickt, gibt es eine kurze Phase, in der die Person auf nichts blickt — auf einen leeren Bildschirm — während der Browser Ihre Seite abruft und verarbeitet. First Contentful Paint ist der Augenblick, in dem aus diesem leeren Bildschirm etwas Reales wird: eine Überschrift, ein Logo, ein Foto, alles, was der Besucher tatsächlich sehen kann.
Das ist die ganze Idee. FCP beantwortet eine einfache Frage: „Wie lange dauert es, bis der Nutzer sieht, dass die Seite lebt und etwas tut?“ Eine Seite, die nach einer halben Sekunde Inhalt zeichnet, fühlt sich schnell an. Eine Seite, die drei Sekunden leer bleibt, wirkt kaputt — und Menschen gehen.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintWas als „Inhalt“ zählt
FCP wird ausgelöst, wenn der Browser eines dieser Elemente auf den Bildschirm zeichnet:
- Text (eine Überschrift, ein Absatz, ein Navigationslink)
- Bilder, einschließlich Hintergrundbildern
<svg>-Grafiken- ein nicht weißes
<canvas>-Element
Eine reine Hintergrundfarbe zählt nicht — das ist ein anderes, früheres Ereignis namens First Paint. FCP zählt erst, wenn echter Inhalt sichtbar wird.
Was ist ein guter Wert?
Die Google-Bänder, gemessen über echte Besucher:
| FCP-Zeit | Bewertung |
|---|---|
| 1,8 Sekunden oder weniger | Gut |
| 1,8 – 3,0 Sekunden | Verbesserungswürdig |
| Über 3,0 Sekunden | Schlecht |
Ihren FCP sehen Sie in Tools wie PageSpeed Insights und Lighthouse — denselben Berichten, die auch Ihre Core Web Vitals anzeigen.
Beeinflusst FCP mein Google-Ranking?
Nein — nicht direkt. Das ist der Teil, den die meisten Menschen falsch verstehen. Die Metriken, die Google tatsächlich fürs Ranking verwendet, sind die drei Core Web Vitals: LCP, INP und CLS. FCP gehört nicht dazu.
Warum sich die Beobachtung trotzdem lohnt: Die Dinge, die FCP langsam machen — ein träger Server sowie große Stylesheets und Skripte, die das Zeichnen der Seite blockieren — schaden oft auch Largest Contentful Paint (LCP), und LCP ist ein Ranking-Signal. Die Ursachen von FCP zu beheben hilft daher häufig auch LCP — garantiert ist das aber nicht, denn LCP hat eigene Ursachen (Größe und Ladepriorität seines konkreten größten Elements). Betrachten Sie FCP als Rauchmelder: prüfen lohnt sich, aber er beweist nicht, dass das Feuer aus ist.
Die schnellen Lösungen
Wenn Ihr FCP langsam ist, sind das die üblichen Verdächtigen — und das können Sie tun:
- Renderblockierende Dateien. CSS und JavaScript im
<head>Ihrer Seite können den Browser daran hindern, irgendetwas zu zeichnen, bis sie vollständig geladen sind. Das ist die häufigste Ursache. - Ein langsamer Server. Wenn Ihr Server lange für die Antwort braucht (hohe Time to First Byte), kann der Browser erst zeichnen, wenn die Bytes eintreffen.
- Schriftarten, die Ihren Text verbergen. Manche Schriftkonfigurationen lassen Text bis zu drei Sekunden unsichtbar, während eine Webschrift geladen wird. Mit
font-display: swapwird sofort ein Ersatztext angezeigt.
Möchten Sie die technische Fassung mit der Lücke zwischen Labor- und Felddaten, der diagnostischen Kette FCP/LCP und der vollständigen Maßnahmenliste? Wechseln Sie zum Tab Fortgeschritten.
TL;DR — FCP ist die Zeit vom Beginn der Navigation bis zum ersten Rendern irgendeines Seiteninhalts (Text, Bild,
<svg>oder nicht weißes<canvas>). Es ist kein Core Web Vital, sondern eine ergänzende Diagnosemetrik aus Labor und Feld und ein Baustein von LCP (FCP tritt gleichzeitig mit oder vor LCP auf). Feldschwellenwerte (p75): Gut ≤ 1,8 s, verbesserungswürdig ≤ 3,0 s, schlecht > 3,0 s. In Lighthouse 10 macht FCP 10 % des Performance-Scores aus. Da die FCP-Uhr bei der Navigation startet, umfasst sie Weiterleitungszeit, Verbindungsaufbau und TTFB; Laborwerte (Lighthouse) und Felddaten (CrUX) weichen daher oft voneinander ab. Beheben Sie die Ursache dort, wo sie liegt: zuerst renderblockierendes CSS/JS, dann TTFB, dann Schriftarten.
Was FCP genau misst
Googles Definition aus dem web.dev-Artikel von Philip Walton ist hier der Genauigkeitsmaßstab:
“First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (Übersetzung) „First Contentful Paint (FCP) misst die Zeit vom ersten Aufrufen der Seite durch den Nutzer bis zum Rendern eines beliebigen Teils des Seiteninhalts auf dem Bildschirm.“ “Content,” (Übersetzung) „Inhalt“ bedeutet laut demselben Dokument “text, images (including background images), <svg> elements, or non-white <canvas> elements.” (Übersetzung) „Text, Bilder (einschließlich Hintergrundbilder), <svg>-Elemente oder nicht weiße <canvas>-Elemente.“
Das entscheidende Wort ist beliebig. FCP ist egal, was gerendert wird — ein 40-Pixel-Logo zählt genauso wie ein vollständiges Hero-Bild. Es ist das Signal „Ist überhaupt schon etwas auf dem Bildschirm?“, genau deshalb ein früher Indikator und keine Metrik für die Fertigstellung.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful PaintEin leicht zu übersehendes Detail verändert die Lesart des Werts: Die FCP-Uhr startet bei der Navigation und bündelt daher alles, was geschieht, bevor Ihr HTML überhaupt geparst wird. Googles eigener Key Point lautet: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (Übersetzung) „FCP umfasst die Entladezeit der vorherigen Seite, den Verbindungsaufbau, die Weiterleitungszeit und Time To First Byte (TTFB), die bei der Messung im Feld erheblich sein kann.“ Ein Server, der 1,5 s für die Antwort braucht, hat den größten Teil Ihres Budgets von 1,8 s bereits verbraucht, bevor der Browser ein einziges Byte verarbeitet hat.
FCP ist kein Core Web Vital
Ich sage es deutlich, weil viele Seiten es abschwächen: FCP ist kein Core Web Vital und gehört nicht zu Googles Ranking-Signalen. Die Core Web Vitals sind LCP, INP und CLS — FCP wird auf Googles Seite zu den Core Web Vitals im Suchranking nirgends genannt.
In Googles Taxonomie ist FCP ein „Other Web Vital“ — eine ergänzende Metrik, die für die Diagnose nützlich ist. web.dev formuliert es so: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (Übersetzung) „Die Metriken Time to First Byte (TTFB) und First Contentful Paint (FCP) sind beide wichtige Aspekte des Ladeerlebnisses und helfen beide bei der Diagnose von LCP-Problemen (jeweils langsame Serverantwortzeiten oder renderblockierende Ressourcen).“
Die ehrliche Einordnung für Stakeholder hat zwei Seiten; nennen Sie beide ohne Ausflüchte:
- FCP beeinflusst Rankings nicht direkt. Optimieren Sie FCP nicht „für SEO“.
- FCP ist eine gute Diagnose für LCP, das Rankings beeinflusst. Renderblockierende Ressourcen zeigen sich zuerst in FCP.
FCP im Vergleich zu First Paint (FP)
Diese beiden Werte werden ständig verwechselt:
- First Paint (FP) wird ausgelöst, sobald der Browser irgendetwas zeichnet — auch eine bloße Hintergrundfarbe ohne echten Inhalt.
- FCP wird erst ausgelöst, wenn geeigneter Inhalt gerendert wird: Text, Bilder (einschließlich Hintergrundbilder),
<svg>-Elemente oder nicht weiße<canvas>-Elemente. Das ist eine konkrete, in der Spezifikation definierte Liste — keine lockere Regel für „beliebigen DOM-Inhalt“. Die Präzision ist wichtig, weil ein Hintergrundbild zählt, obwohl es kein Text im DOM ist.
Daher gilt FP ≤ FCP, immer. Auf den meisten Seiten sind die Werte fast identisch, weil eine Hintergrundfarbe ohne darüberliegenden Inhalt selten relevant ist. Gibt es eine deutliche Lücke, wurde meist ein kosmetischer Hintergrund vor jedem echten Inhalt gezeichnet. Die Paint Timing API liefert Einträge für first-paint und first-contentful-paint — analysierenswert ist aber FCP; FP liefert selten etwas, das Sie konkret umsetzen können.
FCP im Vergleich zu LCP
Das andere Paar, das häufig zusammengelegt wird:
- FCP = der Zeitpunkt, an dem irgendein Inhalt gezeichnet wird. Tritt früh auf; das kann ein winziges Logo oder ein Navigationslink sein.
- LCP = der Zeitpunkt, an dem das größte Element im Viewport gerendert wird. Tritt gleichzeitig mit oder nach FCP auf.
Googles Formulierung: FCP misst, wann beliebiger Inhalt gezeichnet wird, und LCP, wann der Hauptinhalt gezeichnet wird; LCP ist also selektiver. Lesen Sie „selektiver“ nicht als „nachweislich korrekt“ — keine der beiden Metriken beweist, dass der tatsächliche Hauptinhalt der Seite vollständig oder für Besucher nützlich ist. FCP bestätigt nur, dass etwas Geeignetes gezeichnet wurde; LCP bestätigt, dass der größte geeignete Kandidat gezeichnet wurde. Eine Seite kann einen schnellen FCP (Logo nach 0,5 s) und einen langsamen LCP (Hero-Bild nach 4 s) haben — diese Lücke ist selbst eine nützliche Diagnose. Liegt Ihr FCP nahe an LCP, ist das oft ein gutes Zeichen: Das zuerst gezeichnete Element ist zugleich das größte, ohne unnötigen frühen Paint für Chrome, die dem Nutzer nichts bringt.
Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)Eine Messbesonderheit ist wichtig: Wegen Sicherheitsbeschränkungen beim Timing von Cross-Origin-Bildern kann die Browser-API in seltenen Fällen LCP früher als FCP melden. Das ist ein Messartefakt und bedeutet nicht, dass es physisch so passiert ist.
Schwellenwerte — und warum Labor und Feld voneinander abweichen
Feldschwellenwerte (CrUX, p75): Gut ≤ 1,8 s · verbesserungswürdig ≤ 3,0 s · schlecht > 3,0 s. Google empfiehlt die Messung am 75. Perzentil der Seitenladevorgänge, getrennt nach Mobilgeräten und Desktop.
Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful PaintLighthouse Desktop verwendet jedoch andere, strengere Grenzwerte — Grün liegt ungefähr bei 0–0,9 s, Orange bei 0,9–1,6 s, Rot über 1,6 s — weil das Labor einen sauberen, gedrosselten Chrome auf einem simulierten Gerät ausführt, nicht reale Bedingungen. (Diese Bänder sind wie die unten genannten Score-Gewichte versionsabhängig; hier gilt die aktuelle Audit-Dokumentation zum Zeitpunkt der Erstellung.) Der Lighthouse-FCP-Score ist “a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (Übersetzung) „ein Vergleich der FCP-Zeit Ihrer Seite mit den FCP-Zeiten realer Websites auf Grundlage von Daten aus dem HTTP Archive.“
Das ist die häufigste Quelle für FCP-Verwirrung. Prägen Sie sich daher ein:
Die „gut“-Linie bei 1,8 s ist der Feld-Schwellenwert (CrUX p75). Die „grüne“ Linie von Lighthouse Desktop liegt bei etwa 0,9 s. Das sind unterschiedliche Skalen für unterschiedliche Aufgaben.
Feld- und Laborwerte weichen vor allem ab, weil sie unterschiedliche Populationen erfassen — nicht, weil einer universell „wahrer“ wäre. Lighthouse führt eine einzelne saubere Sitzung unter festen Geräte- und Netzwerkbedingungen aus. Feld/CrUX fasst echte Geräte, Netzwerke, Cache-Zustände und Navigationstypen zusammen — einschließlich Wiederherstellungen aus dem Back/Forward Cache und prerenderter Seiten, die nicht automatisch einen neuen FCP wie eine normale Navigation erhalten; dafür ist eine eigene Lebenszyklusbehandlung nötig (die web-vitals-Bibliothek erledigt das). Auf den meisten Websites liegt der Feldwert tatsächlich höher — echte Nutzer bringen Weiterleitungsketten, die Entladezeit der vorherigen Seite und kalte Verbindungen mit, die ein Labortest überspringt — aber das ist eine Tendenz, keine Regel. Prüfen Sie vor der Interpretation einer Labor/Feld-Lücke als Problem, ob Sie Gleiches mit Gleichem vergleichen (dieselbe Geräteklasse, dieselben Netzwerkbedingungen). Verwenden Sie Felddaten für den realen Wert und Lighthouse für die Diagnose.
Wo FCP im Lighthouse-Score steht
In Lighthouse 10 — der aktuellen Version zum Zeitpunkt der Erstellung, nicht einer dauerhaften Festlegung — macht FCP 10 % des Performance-Scores aus. Die vollständige Gewichtung:
| Metrik | Gewicht |
|---|---|
| Total Blocking Time (TBT) | 30 % |
| Largest Contentful Paint (LCP) | 25 % |
| Cumulative Layout Shift (CLS) | 25 % |
| First Contentful Paint (FCP) | 10 % |
| Speed Index | 10 % |
Der Performance-Score ist ein gewichteter Durchschnitt der einzelnen Metrik-Scores. Google weist darauf hin, dass sich die Gewichtungen mit der Weiterentwicklung der Forschung ändern — FCP lag von Lighthouse 8 bis 10 bei 10 %, aber prüfen Sie die Version, die Sie ausführen, bevor Sie „10 %“ als zeitlos behandeln. Praktisch bedeutet das: Ein perfekter FCP kann Ihre Lighthouse-Zahl nur begrenzt bewegen — und ein schlechter FCP deutet oft auch auf einen schlechten LCP hin (beide teilen Ursachen), doch diese Überschneidung muss geprüft werden; der Score garantiert sie nicht.
Was einen langsamen FCP verursacht
In grober Prioritätsreihenfolge:
- Renderblockierende Ressourcen — der größte Verursacher. CSS und synchrones JS in
<head>zwingen den Browser zu warten: Er kann CSSOM und Render Tree nicht aufbauen und daher nichts zeichnen, bis diese Dateien heruntergeladen und geparst sind. - Hohe TTFB — FCP kann nicht ausgelöst werden, bevor Bytes eintreffen. Ein langsamer Server ist der erste Dominostein und steckt innerhalb der FCP-Messung.
- Weiterleitungsketten — jede Weiterleitung fügt vor dem ersten Byte einen vollständigen Roundtrip hinzu.
- Ladestrategie für Webschriften —
font-display: block(oder keine Regel) kann Text bis zu etwa drei Sekunden unsichtbar lassen. Selbst wenn der Paint technisch im Hintergrund ausgelöst wird, sieht der Nutzer nichts Nützliches.
So beheben Sie es
Die vollständige Liste folgt hier einer Prioritätsreihenfolge, die nicht von der Dokumentation vorgegeben wird. Das sind übliche Stellschrauben, keine universellen Lösungen — prüfen Sie zuerst Ihren eigenen Trace oder Filmstrip, um zu sehen, welche Ressource oder Phase Ihren FCP-Kandidaten tatsächlich verzögert, bevor Sie zu Maßnahmen wie Preconnect, Preload oder einer Änderung von font-display greifen, die auf Ihre Seite vielleicht nicht zutreffen:
Das zuerst tun (größte Gewinne):
- Renderblockierendes CSS und JavaScript beseitigen. Kritisches CSS oberhalb des Folds direkt in
<head>inline einfügen; den Rest asynchron laden; bei nicht kritischen Skriptenasync/deferergänzen. Das Verschieben eines<link>-Tags hilft nicht — der Browser zeichnet erst, wenn sämtliches CSS geladen und geparst ist, unabhängig von der Position des Tags. - TTFB (Serverantwortzeit) reduzieren. Caching, ein CDN, ein schnellerer Origin — alles, was das erste Byte früher liefert, verkürzt FCP direkt.
- Schriftladen reparieren.
font-display: swap(zeigt sofort Ersatztext und tauscht die Webschrift nach dem Laden aus) oderfont-display: optional(überspringt die Webschrift, wenn sie nicht bereits im Cache liegt) verwenden.font-display: blockbei kritischem Text vermeiden — das ist für FCP am schlechtesten.
Dann den Rest aufräumen:
- Mit
<link rel="preconnect">zu benötigten Origins vorverbinden — frühe Verbindungen zu wichtigen Drittanbieter-Origins können 100–500 ms sparen. - Wichtige Anfragen vorladen (
<link rel="preload">), etwa eine kritische Schrift oder das LCP-Bild. - CSS minifizieren, ungenutztes CSS entfernen, ungenutztes JavaScript entfernen — kleinere Dateien werden schneller geparst und geben den Paint früher frei.
- Mehrere Weiterleitungen vermeiden, übermäßig große Netzwerk-Payloads vermeiden, statische Assets mit einer effizienten Cache-Richtlinie ausliefern, eine übermäßige DOM-Größe vermeiden und die Tiefe kritischer Anfragen minimieren. Allgemeine Payload-Hygiene wirkt sich auf den ersten Paint aus.
Die diagnostische Kette FCP → TTFB → LCP
So würde ich FCP tatsächlich einsetzen — und so rahmen es die Dokumente an, ohne es ausführlich zu entwickeln. Behandeln Sie die drei Lademetriken als einen Workflow:
- FCP ist hoch → renderblockierende Ressourcen prüfen (CSS/JS in
<head>). Das ist die häufigste Ursache und der schnellste Gewinn. - Auch TTFB prüfen — FCP umfasst TTFB, daher macht ein langsamer Server FCP länger, bevor renderblockierende Ressourcen überhaupt ins Spiel kommen. Die Empfehlung von web.dev: Da TTFB FCP und LCP vorausgeht, sollte Ihr Server schnell genug antworten, damit das 75. Perzentil der Nutzer einen „guten“ FCP erreicht.
- Dieselben Probleme können sich auf LCP ausweiten — die Metrik, die tatsächlich ein Ranking-Signal ist —, weil FCP und LCP häufig Ursachen teilen. Das ist eine Überschneidung, die geprüft werden sollte, keine Garantie: LCP hat eigene Faktoren (Größe, Priorität und Ladepfad seines konkreten größten Elements). Die Ursachen von FCP zu beheben verspricht daher keinen behobenen LCP. Es ist der richtige erste Blick, nicht der letzte Schritt.
Das ist der Wert von FCP für SEOs: ein kostengünstiger, früher Hinweis darauf, ob der Ladepfad gesund ist, bevor die selektivere LCP-Messung überhaupt abgeschlossen ist.
KI-Zusammenfassung
Eine komprimierte Zusammenfassung der Advanced-Version:
- FCP = Zeit vom Navigationsbeginn bis zum ersten Rendern irgendeines Inhalts — Text, Bilder (einschließlich Hintergrundbilder),
<svg>oder nicht weißes<canvas>. Das Signal lautet: „Ist schon etwas auf dem Bildschirm?“ - FCP ist KEIN Core Web Vital. Die Ranking-Signale sind LCP, INP und CLS. FCP ist eine ergänzende Diagnosemetrik aus Labor und Feld — kein direkter Ranking-Faktor.
- FCP ist ein Baustein von LCP (FCP tritt gleichzeitig mit oder vor LCP auf) und erkennt daher oft dieselben renderblockierenden Ressourcen und die hohe TTFB, die LCP schaden — LCP beeinflusst Rankings —, aber die Ursachen von FCP zu beheben garantiert keinen behobenen LCP; LCP hat eigene Faktoren.
- Feldschwellenwerte (CrUX p75): Gut ≤ 1,8 s · verbesserungswürdig ≤ 3,0 s · schlecht > 3,0 s.
- Labor ≠ Feld, und „Feld ist immer höher“ ist eine Tendenz, keine Regel. Die grüne Lighthouse-Desktop-Linie bei etwa 0,9 s ist wegen des einzelnen sauberen Laufs unter festen Bedingungen strenger als der Feldschwellenwert von 1,8 s; Feld/CrUX fasst echte Geräte, Netzwerke, Cache-Zustände und Navigationstypen zusammen (einschließlich bfcache-Wiederherstellungen und prerenderter Seiten). Populationen abgleichen, bevor eine Lücke als Problem gilt — Feld für die Realität, Labor für die Diagnose verwenden.
- FCP vs. FP: First Paint wird bei jedem Paint ausgelöst (auch bei einer Hintergrundfarbe); FCP braucht geeigneten Inhalt (Text, Bilder einschließlich Hintergrundbildern, SVG, nicht weißes Canvas). FP ≤ FCP gilt immer.
- FCP vs. LCP: FCP = jeder geeignete Inhalt; LCP = der größte geeignete Kandidat. Keine der beiden Metriken beweist, dass der reale Hauptinhalt vollständig oder nützlich ist — es sind Proxys. Schneller FCP plus langsamer LCP ist eine reale, häufige Lücke.
- Gewichtung in Lighthouse 10 (zum Zeitpunkt der Erstellung): 10 % — TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, Speed Index 10 %; Gewichte ändern sich zwischen Lighthouse-Versionen.
- Wichtigste Lösungen in Reihenfolge: renderblockierendes CSS/JS beseitigen → TTFB reduzieren → Schriftarten reparieren (
font-display: swap/optional) → Preconnect/Preload → Minifizierung/Cache/DOM-Hygiene.
Offizielle Dokumentation
Primärquellen von Google zu FCP.
web.dev (Google)
- First Contentful Paint (FCP) — Philips Waltons kanonische Definition, die Liste „was als Inhalt zählt“, der Schwellenwert von 1,8 s, der Key Point zu TTFB/Weiterleitungen sowie die Messung mit Paint Timing API und web-vitals-Bibliothek.
- Web Vitals — wo FCP steht: ein „Other Web Vital“, ergänzend zu den Core Web Vitals (LCP, INP, CLS), nützlich für die Diagnose von LCP.
- Largest Contentful Paint (LCP) — der Unterschied zwischen FCP und LCP und ihr Verhältnis.
- Time to First Byte (TTFB) — warum TTFB FCP vorausgeht und darin enthalten ist.
- User-centric performance metrics — FCP als Labor- und Feldmetrik.
Lighthouse / Chrome Developers
- First Contentful Paint audit — die Desktop-Bewertungsbänder von Lighthouse (Grün ≤ 0,9 s) und die Berechnung des FCP-Scores anhand von HTTP-Archive-Daten.
- Lighthouse performance scoring — die Metrik-Gewichte, einschließlich FCP mit 10 % des Performance-Scores in Lighthouse 10.
Google Search Central
- Core Web Vitals & Google Search — die Ranking-Seite; sie listet LCP, INP und CLS. FCP fehlt dort — genau darum geht es.
Zitate aus der Quelle
Wörtliche Aussagen aus Googles Dokumentation. Jeder Link ist ein Deeplink, der direkt zur zitierten Passage auf der Quellseite springt.
web.dev — die Definition
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (Übersetzung) „First Contentful Paint (FCP) misst die Zeit vom ersten Aufrufen der Seite durch den Nutzer bis zum Rendern eines beliebigen Teils des Seiteninhalts auf dem Bildschirm.“ — Philip Walton, First Contentful Paint (FCP), web.dev (aktualisiert am 6. Dezember 2023). Zum Zitat springen
web.dev — der Schwellenwert
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” (Übersetzung) „Websites sollten einen First Contentful Paint von 1,8 Sekunden oder weniger anstreben.“ — dieselbe Quelle. Zum Zitat springen
web.dev — was FCP umfasst (der Key Point)
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (Übersetzung) „FCP umfasst die Entladezeit der vorherigen Seite, den Verbindungsaufbau, die Weiterleitungszeit und Time To First Byte (TTFB), die bei der Messung im Feld erheblich sein kann.“ — dieselbe Quelle.
web.dev — FCPS Rolle im Verhältnis zu den Core Web Vitals
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (Übersetzung) „Die Metriken Time to First Byte (TTFB) und First Contentful Paint (FCP) sind beide wichtige Aspekte des Ladeerlebnisses und helfen beide bei der Diagnose von LCP-Problemen (jeweils langsame Serverantwortzeiten oder renderblockierende Ressourcen).“ — Web Vitals, web.dev. Zum Zitat springen
Lighthouse — wie der FCP-Score berechnet wird
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (Übersetzung) „Ihr FCP-Score ist ein Vergleich der FCP-Zeit Ihrer Seite mit den FCP-Zeiten realer Websites auf Grundlage von Daten aus dem HTTP Archive.“ — First Contentful Paint audit, developer.chrome.com.
Lighthouse — wie der Performance-Score funktioniert
- “The Performance score is a weighted average of the metric scores.” (Übersetzung) „Der Performance-Score ist ein gewichteter Durchschnitt der Metrik-Scores.“
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” (Übersetzung) „Die Gewichtungen haben sich im Laufe der Zeit geändert, weil das Lighthouse-Team regelmäßig forscht und Feedback sammelt, um zu verstehen, was die von Nutzern wahrgenommene Performance am stärksten beeinflusst.“ — Lighthouse performance scoring, developer.chrome.com.
#:~:text=-Deeplink zitiert; gleichen Sie solche Passagen mit den Live-Seiten ab, bevor Sie ein Zitat als endgültig behandeln. Die Lighthouse-Gewichte werden für Lighthouse 10 zitiert — prüfen Sie die Angaben erneut, falls eine neuere Lighthouse-Version erschienen ist. Checkliste zur Triage eines langsamen FCP
Wenn FCP hoch ist, arbeiten Sie diese Liste der Reihe nach ab — grob vom größten Gewinn zum kleinsten:
- Die Feld-Zahl prüfen, nicht nur Lighthouse. Das p75-FCP aus CrUX/PageSpeed Insights zeigt den realen Wert; Lighthouse dient nur zur Diagnose.
- Renderblockierende Ressourcen suchen. CSS und synchrones JS in
<head>sind die häufigste Ursache — Lighthouse listet sie im Audit „Renderblockierende Ressourcen beseitigen“. - Kritisches CSS oberhalb des Folds inline einfügen; den Rest asynchron laden.
-
async/deferergänzen bei nicht kritischen Skripten; Drittanbieter-Tags erst nach dem ersten Paint laden. - TTFB messen. Sie steckt in FCP — ein langsamer Server erhöht FCP, bevor irgendetwas anderes geschieht. Caching, ein CDN oder einen schnelleren Origin einsetzen.
- Weiterleitungsketten beseitigen — jeder Hop ist ein vollständiger Roundtrip vor dem ersten Byte.
- Schriftarten reparieren:
font-display: swapoderoptionalverwenden, bei kritischem Text nieblock. Die kritische Schriftdatei vorladen. - Zu benötigten Drittanbieter-Origins vorverbinden; das LCP-Bild und wichtige Anfragen vorladen.
- Payload verkleinern: CSS minifizieren, ungenutztes CSS/JS entfernen, effiziente Cache-Richtlinie, kleineres DOM, kürzere Tiefe kritischer Anfragen.
- Danach LCP erneut prüfen — dieselben Maßnahmen sollten ihn bewegt haben, und LCP ist der Wert, der Rankings beeinflusst.
FCP-Spickzettel
Feldschwellenwerte (CrUX, 75. Perzentil)
| FCP-Zeit | Bewertung |
|---|---|
| ≤ 1,8 s | Gut |
| 1,8 – 3,0 s | Verbesserungswürdig |
| > 3,0 s | Schlecht |
Lighthouse-Desktop-Bewertung (Labor — Hinweis: strenger als das Feld)
| FCP-Zeit | Farbe |
|---|---|
| 0 – 0,9 s | Grün (schnell) |
| 0,9 – 1,6 s | Orange (mittel) |
| Über 1,6 s | Rot (langsam) |
Gewichte des Lighthouse-10-Performance-Scores (zum Zeitpunkt der Erstellung aktuell — Gewichte ändern sich zwischen Lighthouse-Versionen)
| Metrik | Gewicht |
|---|---|
| Total Blocking Time | 30 % |
| Largest Contentful Paint | 25 % |
| Cumulative Layout Shift | 25 % |
| First Contentful Paint | 10 % |
| Speed Index | 10 % |
Die drei Lademetriken entwirrt
| Metrik | Wird ausgelöst, wenn … | Core Web Vital? |
|---|---|---|
| First Paint (FP) | der Browser irgendetwas zeichnet, sogar eine Hintergrundfarbe | Nein |
| First Contentful Paint (FCP) | echter Inhalt gezeichnet wird (Text/Bild/SVG/Canvas) | Nein (Diagnose) |
| Largest Contentful Paint (LCP) | das größte Element im Viewport gerendert wird | Ja |
Reihenfolge der Ereignisse: FP ≤ FCP ≤ LCP.
Was für FCP als „Inhalt“ zählt
Text · Bilder (einschließlich Hintergrundbilder) · <svg>-Elemente · nicht weiße <canvas>-Elemente
Schnelle Fakten
- Die FCP-Uhr startet bei der Navigation — sie umfasst Weiterleitungszeit, Verbindungsaufbau und TTFB.
- FCP ist im Labor und im Feld messbar.
- Bei
font-display:swap/optionalverwenden;blockvermeiden (bis zu etwa 3 s unsichtbarer Text). - Preconnect zu Drittanbieter-Origins kann 100–500 ms sparen.
Tools zum Messen von FCP
Feld- (Echtbenutzer-)Daten
- PageSpeed Insights — zeigt das CrUX-p75-FCP Ihrer URL (Feld) neben einem Lighthouse-Lauf (Labor).
- Chrome User Experience Report (CrUX) — der Echtbenutzer-Datensatz hinter den Feldwerten, über API oder BigQuery.
- web-vitals-JavaScript-Bibliothek —
onFCP(console.log)aufrufen (oder an Ihre Analytics senden), um FCP Ihrer eigenen Besucher zu erfassen; sie behandelt bfcache- und Hintergrund-Tab-Sonderfälle.
Labor- (simulierte) Daten
- Lighthouse — in Chrome DevTools, PageSpeed Insights oder der CLI. Zur Diagnose von FCP verwenden (das Audit „Renderblockierende Ressourcen beseitigen“ ist das wichtigste).
- Chrome-DevTools-Performance-Panel — exakt sehen, wann First Paint und First Contentful Paint bei einem aufgezeichneten Ladevorgang ausgelöst werden.
Mit der Paint Timing API selbst messen
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});Oder die web-vitals-Bibliothek verwenden (empfohlen)
import {onFCP} from 'web-vitals';
onFCP(console.log);Einige Einschränkungen der rohen API behandelt die web-vitals-Bibliothek selbst: Sie ignoriert FCP-Auslösungen in Hintergrund-Tabs, meldet FCP weiterhin, wenn eine Seite aus dem Back/Forward Cache wiederhergestellt wird (ein frisches Navigationsereignis wird bei einer bfcache-Wiederherstellung nicht automatisch ausgelöst und erfordert daher eine explizite Behandlung) und verwendet bei vorgerenderten Seiten activationStart statt des Navigationsbeginns als Zeitursprung. Das Paint-Timing in Cross-Origin-Iframes bleibt eine bekannte Lücke — eine Seite, deren Hauptinhalt in einem solchen Iframe gerendert wird, kann einen irreführend schnellen FCP anzeigen.
FCP-Fehler, die den eigentlichen Engpass verbergen
- FCP als Core Web Vital behandeln. FCP ist eine nützliche Diagnose, aber LCP, INP und CLS sind die Core Web Vitals, die in Googles Rankingsystemen verwendet werden. Verwenden Sie FCP, um die Phase des leeren Bildschirms zu untersuchen, nicht als Ersatz für CWV-Felddaten.
- Ein winziges Logo optimieren, weil es zum First Paint wird. Ein früher, aber bedeutungsloser Paint kann FCP verbessern, während der nützliche Seiteninhalt weiterhin spät eintrifft. LCP und Filmstrip gemeinsam mit FCP prüfen, damit die Änderung das verbessert, was ein Besucher tatsächlich sieht.
- Mit Bildkomprimierung beginnen, wenn die Seite leer ist. Wenn nichts gezeichnet werden kann, sind die üblichen Blocker Serverantwortzeit, renderblockierendes CSS, synchrones JavaScript oder Schriftarten. Den Anfrage-Wasserfall verfolgen, bevor Sie andere Assets ändern.
- Unzusammenhängende Lighthouse-Läufe vergleichen. Gerätesimulation, Netzwerkbedingungen, Cache-Zustand und Lauf-zu-Lauf-Schwankungen verändern den Labor-FCP. Wiederholte Läufe unter denselben Einstellungen vergleichen und das Ergebnis, wo verfügbar, mit Felddaten bestätigen.
Das Budget für den leeren Bildschirm
FCP in drei aufeinanderfolgende Fragen aufteilen, statt die Endzahl als ein einziges Problem zu behandeln:
- Wie lange dauert es, bis das HTML eintrifft? TTFB prüfen. Eine langsame Antwort bedeutet, dass der Browser keine nützliche Arbeit beginnen kann; daher mit Server, Cache, Weiterleitungen oder Verbindungsaufbau beginnen.
- Wie lange dauert es, bis der Browser rendern kann? Renderblockierende Stylesheets, synchrone Skripte und das Verhalten von Schriftarten prüfen. Das HTML kann bereits vorhanden sein, während Hauptthread oder Rendering-Pfad noch blockiert sind.
- Was wird tatsächlich zum ersten Inhalt? Einen Filmstrip oder Trace verwenden, um zu bestätigen, dass der erste Paint aus bedeutungsvollem Text oder Bild besteht und nicht aus einem Token-Element, das die Metrik verbessert, ohne das Erlebnis zu verbessern.
Das Framework hält die Reihenfolge der Korrekturen ein: zuerst Auslieferung, dann Rendering, dann Nützlichkeit. Nach jeder Änderung dasselbe Laborprofil erneut ausführen, damit sichtbar ist, welche Phase sich bewegt hat.
Testen Sie sich selbst: First Contentful Paint
Fünf kurze Fragen dazu, was FCP misst und wie man es diagnostiziert. Für jede Frage eine Antwort auswählen und anschließend prüfen.
Ressourcen, die Ihre Zeit wert sind
Google / web.dev
- First Contentful Paint (FCP) — die kanonische Referenz: Definition, Schwellenwerte, Messcode und die vollständige Optimierungsliste.
- Web Vitals — wo FCP im Verhältnis zu den Core Web Vitals einzuordnen ist und warum FCP eine Diagnosemetrik ist.
- Largest Contentful Paint (LCP) — die Metrik, bei deren Diagnose FCP hilft, und ein Core Web Vital.
- Time to First Byte (TTFB) — die Serverantwortmetrik, die in FCP steckt.
Lighthouse
- First Contentful Paint audit — Desktop-Bewertungsbänder und die Berechnung des Scores.
- Lighthouse performance scoring — die Metrik-Gewichte, FCP mit 10 %.
Meine verwandten Texte
- Der Einsteigerleitfaden für technisches SEO — wo Seitengeschwindigkeit in das größere Bild passt.
- Core Web Vitals: Was sie sind und wie man sie verbessert — die Ranking-Signal-Metriken, bei deren Diagnose FCP hilft.
Aus der Branche
- First Contentful Paint (FCP) — Philip Waltons kanonischer Google-Artikel: Definition, Schwellenwerte, Paint-Timing-API-Code und die vollständige Optimierungsliste.
- Web Vitals — Googles Framework erklärt, wo FCP steht (ein „Other Web Vital“, ergänzend zu den Core Web Vitals) und welche Rolle FCP bei der Diagnose von LCP spielt.
- First Contentful Paint audit — die Chrome-Developers-Dokumentation zu Lighthouse-Desktop-Bändern und der Berechnung des FCP-Scores anhand von HTTP-Archive-Daten.
- Time to First Byte (TTFB) — Googles Erklärung, warum TTFB FCP vorausgeht und darin enthalten ist und wie ein langsamer Server das FCP-Budget verbraucht, bevor der Browser ein Pixel zeichnet.
- Eliminate render-blocking resources — der Chrome-Developers-Leitfaden zum größten FCP-Killer: CSS und synchrones JS in <head>, die das Zeichnen des Browsers blockieren.
- Ensure text remains visible during webfont load — das Chrome-Developers-Audit erklärt font-display-Werte und warum
blockFCP verzögert, währendswapoderoptionalText sichtbar hält. - First Contentful Paint — NitroPacks praktischer FCP-Leitfaden mit CMS-spezifischen Optimierungstipps und einer klaren Erklärung von Feld- und Labordaten.
Zitierwürdige Statistiken
- Guter FCP = ≤ 1,8 s am 75. Perzentil echter Nutzer; verbesserungswürdig bis 3,0 s, darüber schlecht (Feld-/CrUX-Schwellenwerte). Quelle
- Lighthouse Desktop ist strenger: etwa 0–0,9 s ist „grün“, weil das Labor eine gedrosselte, simulierte Umgebung statt realer Bedingungen verwendet. Quelle
- FCP macht 10 % des Lighthouse-10-Performance-Scores aus (zum Zeitpunkt der Erstellung aktuell — Gewichte ändern sich zwischen Lighthouse-Versionen) — neben TBT 30 %, LCP 25 %, CLS 25 % und Speed Index 10 %. Quelle
- Preconnect zu Drittanbieter-Origins kann 100–500 ms Ladezeit sparen, weil Verbindungen früh aufgebaut werden. Quelle
Änderungsprotokoll
Aktualisiert am 11. Aug. 2026.
Redaktionelle Zusammenfassung und aufgezeichnete Änderungsdetails.Änderungsdetails
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
Vollständiger Vergleich nicht verfügbar — für diese Version wurde kein früherer Schnappschuss archiviert.
Aktualisiert am 11. Aug. 2026.
Redaktionelle Zusammenfassung und aufgezeichnete Änderungsdetails.Änderungsdetails
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
Vollständiger Vergleich nicht verfügbar — für diese Version wurde kein früherer Schnappschuss archiviert.
Aktualisiert am 17. Juli 2026.
Redaktionelle Zusammenfassung und aufgezeichnete Änderungsdetails.Änderungsdetails
-
Detaillierte Änderungsangaben sind derzeit auf Englisch verfügbar.
Vollständiger Vergleich nicht verfügbar — für diese Version wurde kein früherer Schnappschuss archiviert.