First Contentful Paint (FCP): Was es ist, wie man es misst und behebt

First Contentful Paint beheben

Der First Contentful Paint (FCP) ist der Moment, in dem ein Browser das erste bedeutungsvolle Element auf einer Seite für den Besucher sichtbar darstellt. Mit anderen Worten: Es ist der Moment, in dem ein Browser zum ersten Mal etwas auf dem Bildschirm rendert. Daher ist der FCP ein guter Maßstab für die wahrgenommene Seitenladegeschwindigkeit.

Sie können den FCP verbessern, indem Sie sicherstellen, dass ein Browser ohne Verzögerung mit dem Rendern beginnen kann. Im Folgenden erfahren Sie, was FCP ist, wie Sie ihn messen und 15 bewährte Techniken, um ihn zu beschleunigen.

Was ist der First Contentful Paint (FCP)?

Der First Contentful Paint (FCP) ist eine Methode zur Messung der Seitenladegeschwindigkeit. Die Seitengeschwindigkeit lässt sich nicht als einzelner Zeitpunkt zusammenfassen; es gibt tatsächlich mehrere Momente während des Ladevorgangs, in denen ein Besucher die Website als schnell oder langsam ladend wahrnehmen kann. Der FCP misst die Zeitdifferenz zwischen der Seitenanfrage und dem ersten Rendern des bedeutungsvollen Inhalts auf dem Bildschirm.

Was genau sagt Ihnen das? Es zeigt, dass der FCP in erster Linie eine „nutzerzentrierte Metrik" ist, denn sie sagt etwas über die Ladegeschwindigkeit aus, die ein Besucher erlebt. Sie sagt etwas über die Benutzererfahrung aus. Zum FCP-Zeitpunkt können Sie sicher sein, dass ein Besucher tatsächlich „etwas" auf dem Bildschirm sieht.

Lassen Sie uns die Wörter aufschlüsseln: 'First', 'Contentful' und 'Paint'.

1. First: Mit First meinen wir natürlich den ersten genauen Moment, in dem etwas Wesentliches in Ihrem Browser erscheint.
2. Contentful: Mit Contentful meinen wir ein HTML-Element mit Inhalt. Also kein Layout-Element wie ein leeres Element oder eine Hintergrundfarbe, sondern eher Text, ein Bild (einschließlich Hintergrundbild), SVG oder Canvas.
3. Paint: Paint bedeutet (mehr oder weniger), dass der Browser bereit ist, etwas auf den Bildschirm zu bringen. Das klingt einfach, ist aber tatsächlich die komplizierteste Aufgabe des Browsers. Um etwas auf den Bildschirm zu bringen, muss ein Browser bereit sein, alle Eigenschaften eines Elements zu berechnen. Unten finden Sie ein Beispiel des Rendering-Prozesses, der erforderlich ist, bevor etwas auf dem Bildschirm angezeigt werden kann.

FCP vs LCP: Was ist der Unterschied?

FCP und LCP (Largest Contentful Paint) messen beide die Ladeleistung, erfassen jedoch unterschiedliche Momente in der Seitenlade-Timeline. Das Verständnis des Unterschieds hilft Ihnen, Ihre Optimierungsarbeit richtig zu priorisieren.

In der Praxis wird FCP oft deutlich vor LCP ausgelöst. Beispielsweise kann eine Seite eine Überschrift (FCP) innerhalb von 400ms rendern, aber weitere 2 Sekunden auf das Laden des Hero-Bildes (LCP) warten. Wenn Ihr FCP langsam ist, wird Ihr LCP mit ziemlicher Sicherheit ebenfalls langsam sein, da FCP den allerersten Engpass in der Rendering-Pipeline erfasst. Lesen Sie mehr in unserem vollständigen LCP-Leitfaden.

Was ist ein guter First Contentful Paint-Wert?

Ein guter FCP-Wert liegt unter 1,8 Sekunden. Wenn Ihr FCP-Wert zwischen 1,8 und 3 Sekunden liegt, besteht Verbesserungsbedarf. Jeder FCP-Wert über 3 Sekunden gilt als schlecht. Um den empfohlenen Schwellenwert für den First Contentful Paint zu erreichen, müssen mindestens 75% Ihrer Besucher einen „guten" FCP-Wert haben.

Wie immer bei Leistungsmetriken ist ein schnellerer First Contentful Paint-Wert besser als ein langsamerer.

Wie messen Sie Ihren First Contentful Paint (FCP)?

Der FCP wird von Google gemessen, indem Daten von echten Nutzern gesammelt werden. Diese Daten werden im CrUX-Datensatz gespeichert. Die Daten sind öffentlich zugänglich über die CrUX API oder Google BigQuery. Der FCP kann auch durch sogenannte Lab-Tests gemessen werden. Der bekannteste Lab-Test heißt Lighthouse.

Den First Contentful Paint aus dem CrUX-Datensatz abrufen

Der First Contentful Paint kann aus dem CrUX-Datensatz über pagespeed.web.dev, die CrUX API oder Google BigQuery ausgelesen werden.

Den First Contentful Paint durch Real User Monitoring (RUM) messen

RUM Tracking steht für Real User Monitoring. Mit Real User Monitoring können Sie den First Contentful Paint durch echte Nutzerinteraktionen verfolgen. Der Vorteil von RUM Tracking ist, dass Sie nicht 28 Tage auf frische Daten warten müssen und die Daten wesentlich detaillierter abgefragt und analysiert werden können.

Den FCP in Lighthouse messen

1. Öffnen Sie die Seite (in Chrome), deren FCP Sie messen möchten. Stellen Sie sicher, dass Sie dies im Inkognito-Modus tun, damit Plugins den FCP Ihrer Seite nicht beeinträchtigen und möglicherweise verlangsamen.
2. Klicken Sie mit der rechten Maustaste auf die Seite und wählen Sie Element untersuchen. So öffnen Sie die Chrome-Entwicklerkonsole.
3. Oben in der Konsole sehen Sie den Lighthouse-Tab. Klicken Sie darauf. Wählen Sie dann unter Kategorien Performance (lassen Sie die anderen leer) und unter Gerät Mobile.
4. Klicken Sie nun auf Bericht erstellen. Lighthouse erstellt einen Geschwindigkeitsbericht Ihrer Seite. In der oberen linken Ecke des Berichts sehen Sie den FCP Ihrer Seite.

Dies ist ein Screenshot des Lighthouse-Berichts für diese Seite. Der FCP dieser Seite auf einem Mobilgerät beträgt 0,8 Sekunden! Nicht schlecht, oder?

FCP mit einem Online-Tool messen

Sie können den FCP auch mit einer Reihe von Online-Tools messen. Die bekanntesten sind GTMetrix, pingdom und pagespeed.web.dev. Diese Tools sind einfach zu bedienen und liefern einige Daten über den FCP unter bestimmten Lab-Bedingungen.

Was echte FCP-Daten zeigen

CoreDash-Daten zeigen, dass FCP eng mit TTFB korreliert: Der p75-FCP liegt insgesamt bei 392ms, mit 372ms auf Desktop und 692ms auf Mobilgeräten (1,9x langsamer). Die FCP-zu-TTFB-Differenz beträgt nur 248ms auf Desktop und 376ms auf Mobilgeräten, was darauf hindeutet, dass die Render-Blockierungszeit einen relativ kleinen Teil des FCP auf einer gut optimierten Website ausmacht.

Weltweit erreichen laut dem Web Almanac 2025 70% der Desktop-Seiten einen guten FCP, während nur 55% der Mobilseiten dies schaffen. Beide haben sich gegenüber 2024 verbessert, wobei Mobilgeräte 4 Prozentpunkte zugelegt haben, was darauf hindeutet, dass Webentwickler zunehmend Render-blockierende Ressourcen adressieren.

Die enge Korrelation zwischen FCP und TTFB bedeutet, dass die Verbesserung Ihrer Time to First Byte oft der einzeln wirksamste Weg ist, Ihren First Contentful Paint zu verbessern. Auf dieser Website liegt der FCP nur etwa 250ms über dem TTFB, was bedeutet, dass die meiste FCP-Zeit mit dem Warten auf die Serverantwort verbracht wird und nicht mit Render-blockierender Arbeit.

Den First Contentful Paint verbessern

Zeit, den FCP schneller zu machen. Die Idee hinter einem schnellen FCP ist eigentlich recht einfach: Sicherstellen, dass ein Browser sofort mit dem Rendern beginnen kann. Alles, was das Rendern verzögern kann, führt zu einem schlechten FCP-Wert.

Genau wie beim Largest Contentful Paint kann der First Contentful Paint in 2 oder 4 Kategorien unterteilt werden:

1. Time to First Byte (TTFB): Die Zeit vom Beginn des Seitenladens bis zum Empfang des ersten Bytes des HTML durch den Browser.
2. Ressourcenlade-Verzögerung: Die Zeit zwischen TTFB und dem Beginn des Ladens der FCP-Ressource durch den Browser.
3. Ressourcenladezeit: Die Zeit, die das Laden der FCP-Ressource selbst benötigt.
4. Element-Render-Verzögerung: Die Zeit zwischen dem Abschluss des Ladens der FCP-Ressource und dem vollständigen Rendern des FCP-Elements.

Speed-Tipp: Sie können die Schritte 2 und 3 leicht eliminieren, indem Sie sicherstellen, dass das FCP-Element keine Netzwerkressource benötigt. Bei einem Textelement sollten Sie font-display:swap verwenden. Bei einem kleinen Bildelement sollten Sie das Bild inline platzieren.

Damit bleiben uns nur noch die Time to First Byte und die Element-Render-Verzögerung zum Optimieren.

Unten finden Sie 14 Lösungen, die ich häufig verwende, um den FCP zu verbessern. Aber Vorsicht: Die Verwendung einer Lösung an der falschen Stelle kann tatsächlich Verzögerungen verursachen. Deshalb ist es am besten, einen Pagespeed-Experten zu konsultieren, bevor Sie selbst beginnen.

1. Schnelle Serverantwort (TTFB)

Die TTFB (die Zeit zwischen der Anfrage und dem ersten Byte, das der Server sendet) ist immer der erste Schritt im Rendering-Prozess. Ab diesem Punkt beginnt Ihr Browser mit Multitasking, und die Wirkung weiterer Optimierungen nimmt ab. Der HTML-Code ist die einzige Anfrage, die alle Geschwindigkeitsmetriken direkt beeinflusst.

Die Geschwindigkeit, mit der der HTML-Code vom Server gesendet wird, wird oft als Time to First Byte (TTFB) gemessen. Es ist wichtig, diese so schnell wie möglich zu machen. Oft erreichen Sie dies durch die Aktivierung von serverseitigem Caching.

Bei der Time to First Byte gilt: je niedriger, desto besser.

Sie können die Time to First Byte selbst einfach messen. Das geht wie folgt:

1. Verwenden Sie die Tastenkombination Strg-Umschalt-I, um die Entwicklerkonsole von Google Chrome zu öffnen.
2. Oben in der Konsole sehen Sie einen Netzwerk-Tab. Klicken Sie darauf.
3. Laden Sie die Seite über Strg-R neu.
4. Sie sehen nun alle Netzwerkanfragen, die Chrome an Ihren Server gesendet hat.
5. Klicken Sie auf die oberste Netzwerkanfrage, also die Anfrage für Ihre Seite selbst.
6. Nun erhalten Sie weitere Informationen zu dieser Netzwerkanfrage. Klicken Sie oben in diesen Informationen auf den Timing-Tab, um zu sehen, wie hoch die TTFB Ihrer Seite ist.

2. HTTP/3

HTTP/3 ist die dritte Version des HTTP-Protokolls. HTTP/3 löst viele der Probleme, die in den älteren HTTP/1.1- und HTTP/2-Protokollen gefunden wurden. Seit HTTP/2 können Sie beispielsweise mehrere Dateien gleichzeitig über dieselbe Verbindung senden. HTTP/3 bietet eine schnellere Erstverbindung und weniger Probleme durch kleinere Netzwerkunterbrechungen.

Ohne zu sehr ins Detail zu gehen: HTTP/3 ermöglicht einen erheblichen Geschwindigkeitsgewinn, insbesondere in einem langsameren Netzwerk wie einem Mobilfunknetz. Ihr Netzwerkadministrator kann Ihnen sagen, ob Ihr Webserver bereits für das schnellere HTTP/3-Protokoll geeignet ist.

Sie können selbst überprüfen, ob Ihre Website bereits das schnellere HTTP/3-Protokoll verwendet. Verwenden Sie die Tastenkombination Strg-Umschalt-I, um den Netzwerk-Inspektor von Google Chrome zu öffnen. Klicken Sie mit der rechten Maustaste auf die Tabellenkopfzeile und wählen Sie Protokoll. Laden Sie nun die Seite neu, um zu sehen, welches Protokoll Ihre Website verwendet.

3. 103 Early Hints

103 Early Hints ist ein relativ neuer HTTP-Statuscode, der es einem Server ermöglicht, vorläufige Antwort-Header zu senden, bevor die endgültige Antwort bereit ist. Dies ist besonders nützlich, wenn Ihr Server Zeit benötigt, um das HTML zu generieren (z.B. Datenbankabfragen oder serverseitige Logik). Anstatt den Browser warten zu lassen, sendet der Server eine 103-Antwort mit Preload- und Preconnect-Hints, damit der Browser sofort mit dem Herunterladen kritischer Ressourcen beginnen kann.

Dies verbessert den FCP direkt, da der Browser mit dem Herunterladen von Schriftarten, Stylesheets und anderen Render-kritischen Ressourcen beginnen kann, bevor das HTML überhaupt ankommt. Die Auswirkung ist am größten bei Seiten mit einem hohen TTFB.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Noch nicht alle Hosting-Anbieter unterstützen 103 Early Hints. Cloudflare bietet integrierte Unterstützung für Early Hints, und Apache sowie Nginx können entsprechend konfiguriert werden. Lesen Sie mehr in unserem vollständigen 103 Early Hints-Leitfaden.

4. Browser-Caching

Die Netzwerkverbindung ist oft ein Schwachpunkt in Bezug auf die Seitengeschwindigkeit. Wäre es nicht viel einfacher, das Netzwerk ganz zu überspringen?

Wenn ein Besucher bereits auf Ihrer Website war, können Sie angeben, ob und wie lange die Netzwerkressourcen (zum Beispiel ein Stylesheet) vom Browser des Besuchers gespeichert werden können. Jedes Mal, wenn der Besucher eine dieser Dateien erneut benötigt, werden sie im Handumdrehen aus dem Browser-Cache geladen. Dadurch kann der Browser viel schneller mit dem Rendern beginnen und den FCP beschleunigen.

5. Komprimierung

Die Netzwerkgeschwindigkeit ist in fast allen Fällen ein Schwachpunkt. Für einen guten First Contentful Paint ist es so wichtig, dass die Dateien so schnell wie möglich durch das Netzwerk gesendet werden. Komprimierung reduziert die Anzahl der Bytes, die vom Server gesendet werden müssen; weniger Bytes bedeuten weniger Wartezeit auf eine Netzwerkressource. Komprimierung ist meiner Meinung nach eine Technik, die nicht die Aufmerksamkeit bekommt, die sie verdient. Leider „aktivieren" zu viele Webmaster die Komprimierung und schauen dann nicht mehr darauf. Und das ist schade, denn es ist einfach ein leichter Weg, Dinge ein wenig schneller zu machen.

Es gibt zwei beliebte Komprimierungstechniken: Gzip und Brotli. Gzip ist die am häufigsten verwendete Komprimierungstechnik, aber Brotli holt schnell auf. Brotli wurde von Google selbst entwickelt und liefert 15 bis 20% bessere Ergebnisse bei HTML-, JavaScript- oder CSS-Dateien. Brotli ist daher ideal für das Web.

Es gibt auch einen Unterschied zwischen dynamischer und statischer Komprimierung. Bei der dynamischen Komprimierung komprimieren Sie die Datei kurz bevor Sie sie über Ihren Webserver senden; bei der statischen Komprimierung wird die komprimierte Datei auf dem Server gespeichert. Dies ist oft eine viel klügere Art zu komprimieren, wird aber selten eingesetzt.

6. Frühzeitige Webschriften mit Resource Hints

Resource Hints initiieren einen Download oder eine Netzwerkverbindung, bevor der Browser dies von selbst tun würde. Einige Netzwerkressourcen, wie Webschriften oder Bilder, werden erst heruntergeladen, nachdem der Browser sicher ist, dass er sie anzeigen muss.

Wenn Sie sicher sind, dass Sie eine Ressource zum Rendern des sichtbaren Teils der Website benötigen, ist es fast immer eine gute Idee, einen „Resource Hint" einzufügen. Damit stellen Sie sicher, dass der Browser sofort mit dem Herunterladen oder der Verbindung zur Ressource beginnt. Dadurch ist die Ressource früher verfügbar und der Browser kann früher mit dem Rendern beginnen.

Aber Vorsicht mit Resource Hints. Wenn Sie sie falsch verwenden, können sie Ihre Seite tatsächlich verlangsamen.

Frühzeitiger Download mit „Preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

Der Preload-Link ist eines der leistungsstärksten Werkzeuge im Pagespeed-Arsenal. Durch den Preload-Link laden Sie eine Netzwerkressource herunter, die Sie später benötigen. Dies ist oft eine sehr gute Idee bei Schriftarten, kritischen Skripten und Bildern im sichtbaren Bereich der Website.

Vorab verbinden mit Preconnect

Der Preconnect-Link stellt bereits eine Verbindung zu einem Server her. Dies ist nützlich, wenn Sie Dateien auf einem Drittanbieter-Server wie einem CDN oder Google Analytics hosten.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Noch besser als Preconnect zu Google Fonts ist das Selbst-Hosten Ihrer Google Fonts. Dies eliminiert die Drittanbieter-Verbindung vollständig und gibt Ihnen die volle Kontrolle über Caching und Auslieferung.

7. Die nächste Seite mit Prefetch vorab laden

<link rel="prefetch" href="/page2.html">

Mit Prefetch können Sie Ressourcen mit niedriger Priorität vorab laden. Dies ist eine nützliche Methode, um Ressourcen zu laden, von denen Sie denken, dass Sie sie später benötigen, zum Beispiel wenn Sie erwarten, dass jemand auf den Link zur nächsten Seite klickt.

8. Weiterleitungen vermeiden

Ein häufiger Fehler ist eine zu lange Weiterleitungskette. Lassen Sie mich erklären: Ihre Website läuft wahrscheinlich über eine sichere Verbindung. Wenn ein Besucher Ihre Website ohne https eingibt, wird der Besucher auf die ungesicherte Version Ihrer Website weitergeleitet. Wenn jedoch alles richtig eingerichtet ist, wird der Besucher auf die sichere Website weitergeleitet. Dies sehen Sie im grünen Beispiel unten.

Aber manchmal erfolgt die Weiterleitung über einen oder mehrere Zwischenschritte, wie im roten Beispiel gezeigt. Es sind diese Zwischenschritte, die die Website langsam machen und zu einem schlechten First Contentful Paint-Wert führen. Jeder Zwischenschritt kostet zusätzliche Zeit, die sich schnell summieren kann. Stellen Sie also immer sicher, dass Sie innerhalb einer Weiterleitung auf der richtigen Seite ankommen.

9. CSS minimieren

Eine externe CSS-Datei ist immer Render-blockierend. Das bedeutet, dass ein Browser normalerweise keinen Inhalt anzeigen kann, bis alle Stylesheets heruntergeladen und analysiert wurden. Daher ist es am besten, Stylesheets so klein wie möglich zu halten. So müssen Sie nicht so lange warten, bis das Stylesheet heruntergeladen ist. Für einen ausführlicheren Leitfaden lesen Sie unseren Artikel über das Beheben und Entfernen von ungenutztem CSS.

Die CSS-Größe mit Kurzschreibweisen reduzieren

Eine der Möglichkeiten, die CSS-Größe zu reduzieren, ist die Verwendung von Kurzschreibweisen. Das sind Einzeiler, mit denen Sie die wichtigsten Eigenschaften eines CSS-Selektors in einer Zeile zusammenfassen können.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Sie können es auch so schreiben:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Die CSS-Größe weiter reduzieren

Es ist möglich, die CSS-Größe noch weiter zu reduzieren, indem Sie Selektoren mit einem Komma zusammenführen, Zeilenumbrüche und Leerzeichen entfernen und kürzere Farbcodes schreiben.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Könnte verkürzt werden zu

h1,h2,h3,h4,h5{color:#000}

10. Kritisches CSS

Wir können CSS einen Schritt weiter bringen, indem wir kritisches CSS verwenden. Kritisches CSS ist ein Muss für eine schnelle Website und einen schnellen First Contentful Paint.

Kritisches CSS ist eine Sammlung aller Selektoren (wie body, p, h1 usw.), die Sie benötigen, um den sichtbaren Teil der Seite anzuzeigen. Packen Sie dieses kritische CSS nicht in ein separates Stylesheet; fügen Sie es stattdessen direkt im <head> der Seite hinzu. So müssen Sie keine neue Datei herunterladen und der Browser kann blitzschnell mit dem Rendern beginnen. Das sorgt für einen schnelleren FCP. Das CSS, das Sie für den sichtbaren Teil der Seite nicht direkt benötigen, wird geladen, nachdem der erste Rendering-Zyklus abgeschlossen ist. Für Ihren Besucher ist die Seite bereits fertig; niemand wird bemerken, dass im Hintergrund noch neue Styles hinzugefügt werden.

Kritisches CSS kann einfach mit unserem eigenen Critical CSS Tool generiert werden. Fügen Sie einfach die URL Ihrer Webseite in das Tool ein und wir erledigen den Rest für Sie!

Inline Critical CSS Beispiel

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. JavaScript-Laden verzögern

Einer der häufigsten Gründe für einen langsamen First Contentful Paint ist JavaScript. Je nachdem, wie Sie JavaScript verwenden, kann es das Rendern der Seite blockieren. Normalerweise wird JavaScript heruntergeladen und ausgeführt, bevor der Render Tree aufgebaut wird. Ohne den Render Tree kann ein Browser nichts auf den Bildschirm bringen, und das betrifft auch den FCP. Für eine vollständige Übersicht über Verzögerungstechniken lesen Sie 14 Methoden zum Verzögern von JavaScript.

Wir können dies umgehen, indem wir JavaScript verschieben. Das können Sie auf drei Arten tun.

Async JavaScript

<script async src="async.js"></script>

Durch das Hinzufügen des async-Attributs zu einem Script-Tag wird der Seitenaufbau nicht mehr blockiert, während das JavaScript heruntergeladen wird. Das async-Attribut gibt an, dass der Download und der Aufbau des Render Trees gleichzeitig erfolgen können.

Sobald das Skript ausgeführt wird, wird die Seite blockiert. In den meisten Fällen hatte der Browser dank des async-Attributs genug Zeit, einen wichtigen Teil der Seite aufzubauen, wobei der First Contentful Paint bereits auf der Seite ist.

Defer JavaScript

<script defer src="deferred.js"></script>

Das defer-Attribut funktioniert mehr oder weniger genauso wie das async-Attribut. Durch das Hinzufügen des defer-Attributs zu einem Script-Tag darf das Skript ebenfalls gleichzeitig mit dem Seitenaufbau heruntergeladen werden. Nachdem alle Skripte heruntergeladen wurden, werden sie in der Reihenfolge ausgeführt, in der sie im HTML-Code gefunden wurden. Dies kann auch die Anzeige der Seite blockieren, aber in vielen Fällen ist der First Contentful Paint bereits auf dem Bildschirm.

12. Nicht auf externe Ressourcen verlassen

Externe Ressourcen wie externe Schriftarten, externe Bilder, externe Stylesheets oder externe Skripte sind ein potenzieller Engpass beim First Contentful Paint. Da Sie keine Kontrolle über den Server haben, auf dem die Dateien gehostet werden, wissen Sie nicht, wie schnell sie gesendet werden. Außerdem können Sie die bestehende Verbindung zum Webserver nicht nutzen. Eine neue Verbindung zu einem neuen Server muss aufgebaut werden, und das kostet Zeit.

Eine der häufigsten externen Ressourcen im Web ist Google Fonts. Das Selbst-Hosten Ihrer Google Fonts eliminiert eine komplette Drittanbieter-Verbindung und gibt Ihnen die volle Kontrolle über Caching, Komprimierung und font-display-Verhalten.

Blockierende externe Ressourcen

Keine externen Ressourcen

13. Das richtige Schriftformat verwenden

Schriftarten verdienen besondere Aufmerksamkeit beim First Contentful Paint. Auf etwa 99% der Seiten, die wir uns ansehen, ist das FCP-Element eine Textzeile. Wenn Sie externe Webschriften verwenden, müssen Sie diese Schriftarten zuerst von einem Server herunterladen, was natürlich Zeit kostet.

In letzter Zeit haben Webschriften mehr Aufmerksamkeit erhalten, und es gibt mehr neue, schnellere Schriftformate. Das schnellste Schriftformat im Moment ist woff2, gefolgt von woff. Woff2 wird von jedem modernen Browser unterstützt.

Sie können die bevorzugte Reihenfolge Ihrer Webschrift in der CSS font-face-Deklaration angeben. Das machen Sie wie folgt:

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

Bei der Verwendung von Webschriften ist das Standardverhalten, den Text auf der Seite nicht anzuzeigen, bis die Schrift geladen ist. Dies geht normalerweise direkt auf Kosten des First Contentful Paint. Lesen Sie unseren vollständigen Leitfaden darüber, wie Sie sicherstellen, dass Text während des Ladens von Webschriften sichtbar bleibt.

Sie können dies lösen, indem Sie die font-display:swap-Deklaration verwenden. Damit können Sie den Text auf der Seite trotzdem anzeigen, in einer dem Browser bekannten Schriftart, während die Webschrift im Hintergrund geladen wird.

Ohne font-display:swap

Mit font-display:swap

font-display: swap vs optional

Es gibt zwei gängige font-display-Strategien für die FCP-Optimierung:

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

Die Verwendung von font-display: swap garantiert den schnellstmöglichen FCP, da Text sofort in der Fallback-Schrift gerendert wird. Die Verwendung von font-display: optional vermeidet den Flash of Unstyled Text (FOUT) beim ersten Besuch vollständig, aber die Webschrift wird nur angezeigt, wenn sie bereits im Browser-Cache ist. Für die meisten Websites ist swap die bessere Wahl für den FCP.

15. Die DOM-Größe minimieren

Eine Webseite besteht aus HTML. Das Erste, was ein Browser tut, ist das HTML in DOM-Knoten umzuwandeln. Das ist eine Baumstruktur von HTML-Elementen, die später zum Aufbau des Render Trees verwendet wird. Aus dem Render Tree beginnt ein Browser zu rendern; schließlich erscheint die Webseite auf dem Bildschirm.

Wie viele DOM-Knoten (HTML-Elemente) Sie haben und wie tief diese DOM-Knoten in der Baumstruktur liegen, bestimmt, wie kompliziert es für einen Browser ist, Ihre Seite aufzubauen. CSS und JavaScript benötigen ebenfalls mehr Zeit zur Analyse, wenn Sie zu viele DOM-Knoten haben. Dies geht wieder alles direkt auf Kosten des FCP.

Lösen Sie dies durch:

• Teile Ihrer Webseite per Lazy Loading laden
  Um die anfängliche Anzeige zu beschleunigen, sollten Sie erwägen, Teile Ihrer Website, wie den Footer, zu einem späteren Zeitpunkt per AJAX zu laden.
• Content-visibility nutzen
  Die CSS-Eigenschaft content-visibility weist einen Browser an, Style, Layout und Paint während des Renderings zu überspringen. Dies geschieht kurz bevor das Element sichtbar wird.
• Große Seiten in mehrere Seiten aufteilen
  Die Anzahl der DOM-Knoten kann durch die Aufteilung großer Seiten in mehrere Seiten reduziert werden.
• Infinite Scroll implementieren
  Infinite Scrolling ist im Grunde Lazy Loading: Beim Scrollen durch sich wiederholende Elemente wie Bilder (Pinterest) oder große Datentabellen kann Infinite Scroll Ihre Seite erheblich beschleunigen.
• JavaScript-DOM-Interaktion vermeiden
  Seien Sie besonders vorsichtig mit JavaScript, wenn Sie eine große Anzahl von DOM-Knoten auf Ihrer Seite haben. Ein Befehl wie querySelectorAll kann dann eine große Anzahl von DOM-Knoten laden und den Speicherverbrauch erhöhen.
• Komplizierte CSS-Deklarationen vermeiden
  Seien Sie besonders vorsichtig mit komplizierten CSS-Befehlen bei einer großen Anzahl von DOM-Knoten. Beispielsweise kann die Überprüfung des last-child-Status für jedes div-Element auf Ihrer Seite aufwendig sein.
• Web Workers verwenden, um den Main Thread des Browsers zu entlasten
  Web Workers sind JavaScript, das parallel zu Ihrer Webseite ausgeführt werden kann. Sie können diesen Web Workers Befehle geben, die im Hintergrund ausgeführt werden. Wenn der Web Worker den Befehl ausgeführt hat, gibt er ihn an die ursprüngliche Seite weiter. Der Vorteil davon ist, dass Sie weiterhin komplexes JavaScript ausführen können, ohne dass die Seite einfriert.

Verwandte Optimierungsleitfäden

Die Verbesserung des FCP erfordert Arbeit in mehreren Bereichen. Hier sind unsere relevantesten Leitfäden:

• Google Fonts selbst hosten: Eliminieren Sie eine Drittanbieter-Verbindung und erhalten Sie die volle Kontrolle über die Schriftauslieferung.
• Sicherstellen, dass Text während des Ladens von Webschriften sichtbar bleibt: Verwenden Sie font-display, um schnelles Text-Rendering zu garantieren.
• 14 Methoden zum Verzögern von JavaScript: Jede Technik, um JavaScript daran zu hindern, Ihren FCP zu blockieren.
• Ungenutztes CSS beheben und entfernen: Reduzieren Sie Render-blockierendes CSS auf ein Minimum.
• 103 Early Hints: Lassen Sie den Browser Ressourcen herunterladen, bevor das HTML ankommt.
• Largest Contentful Paint (LCP) Leitfaden: FCP und LCP teilen viele Optimierungsstrategien. Wenn Ihr FCP langsam ist, wird es Ihr LCP auch sein.
• Time to First Byte (TTFB) Leitfaden: TTFB ist der größte Einzelbeitrag zum FCP. Beginnen Sie hier, wenn Ihre Serverantwort langsam ist.