FCP
First Contentful Paint – der Zeitpunkt, an dem der Browser das erste sichtbare Element rendert. Zeigt dem Nutzer, dass die Seite lädt.
Aktualisiert: 23. Februar 2026
Was ist FCP?
FCP (First Contentful Paint) ist der Zeitpunkt, an dem der Browser das erste sichtbare Element einer Seite rendert — sei es Text, ein Bild, ein SVG oder ein Canvas-Element. FCP ist nicht dasselbe wie LCP: LCP misst das größte Element, FCP misst das allererste. Der Nutzer sieht bei FCP, dass die Seite lädt — aber nicht zwingend den eigentlichen Inhalt.
Der Zielwert liegt unter 1,8 Sekunden. FCP ist kein direkter Core Web Vitals-Faktor im strengen Sinne, aber er fließt in den Lighthouse Performance Score ein (mit 10 % Gewichtung) und ist ein relevantes Diagnosesignal.
Kurzprofil FCP
- Typ: Web-Performance-Metrik (kein Core Web Vital, aber Lighthouse-Faktor)
- Entwickelt von: Google / W3C
- Gut: < 1,8 Sekunden
- Verbesserungswürdig: 1,8–3,0 Sekunden
- Schlecht: > 3,0 Sekunden
- Lighthouse-Gewichtung: 10 %
- Abgrenzung zu LCP: FCP = erstes Element, LCP = größtes Element
Wie funktioniert FCP?
Der Browser startet die FCP-Messung mit dem Navigationsbeginn. Der erste Render-Zeitstempel irgendeines sichtbaren Inhalts (nicht nur Hintergrundfarbe oder leeres Canvas) wird als FCP-Wert festgehalten.
Typische FCP-Elemente auf WordPress-Seiten:
- Der Seiten-Header-Text (wenn er vor dem Hero-Bild gerendert wird)
- Ein Lade-Indikator oder Skeleton-Screen
- Das erste sichtbare Textblock-Element
Ein schlechter FCP entsteht meist durch:
- Render-blocking Ressourcen: CSS und JavaScript im
<head>, die den Browser blockieren bevor er rendern kann - Langsame TTFB (Time to First Byte): Wenn der Server lange braucht, verschiebt sich alles
- Große CSS-Dateien: Der Browser wartet mit dem Rendern bis das CSSOM aufgebaut ist
FCP für WordPress-Betreiber
FCP ist bei WordPress-Seiten meist ein Symptom anderer Probleme. Die häufigsten Ursachen:
Render-blocking CSS: WordPress-Plugins laden oft unnötige CSS-Dateien synchron im <head>. Diese blockieren den FCP direkt. Tools wie unused CSS Remover oder kritisches CSS inline einbetten helfen.
Render-blocking JavaScript: Jedes <script src="..."> ohne async oder defer im <head> blockiert den HTML-Parser und damit FCP.
Langsame TTFB: Wenn der Server 1–2 Sekunden für die erste Antwort braucht, kann FCP gar nicht gut sein. Redis-Object-Cache und Page-Caching reduzieren TTFB drastisch.
FCP verbessern
- Kritisches CSS inline in
<style>einbetten, Rest asynchron laden - JavaScript:
deferoderasyncfür alle nicht-kritischen Scripts - TTFB optimieren: Server-Cache (Redis, APCu), PHP optimieren
- Google Fonts:
display=swapund preconnect-Hint nutzen - Unnötige WordPress-Plugins deaktivieren (jedes Plugin kann Scripts laden)
- Lighthouse-Report: "Render-blocking resources" zeigt die konkreten Verursacher
Was passiert bei schlechtem FCP?
Ein schlechter FCP (über 3 Sekunden) bedeutet: Der Nutzer sieht eine weiße Seite und weiß nicht, ob etwas passiert. Das erhöht die Abbruchrate deutlich — besonders auf mobilen Geräten mit langsamen Verbindungen. Studien zeigen, dass 53 % der mobilen Nutzer eine Seite verlassen, wenn sie nach 3 Sekunden noch nicht geladen hat.
Für den Lighthouse-Score kostet schlechter FCP direkt Punkte, auch wenn er kein Core Web Vital ist.
Häufige Fragen
Was ist der Unterschied zwischen FCP und TTFB? TTFB (Time to First Byte) misst, wann der erste Byte der HTML-Antwort vom Server ankommt. FCP misst, wann der Browser etwas auf dem Bildschirm rendert. Zwischen TTFB und FCP liegt die gesamte HTML-Parsierung und der Aufbau des Render-Trees.
Ist FCP ein Google-Ranking-Faktor? Nicht direkt. FCP ist kein Core Web Vital und fließt nicht direkt ins Page-Experience-Signal ein. Er wirkt sich aber auf den Lighthouse-Score aus und ist ein gutes Diagnosesignal für LCP-Probleme.