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

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 einzelnen Zeitpunkt zusammenfassen; es gibt tatsächlich mehrere Momente während des Ladeprozesses, in denen ein Besucher die Seite als schnell oder langsam ladend empfinden könnte. Der FCP misst die Zeitdifferenz zwischen dem Anfordern der Seite und dem Moment, in dem der erste bedeutungsvolle Inhalt zum ersten Mal auf dem Bildschirm gerendert wird.

Was genau sagt Ihnen das? Es zeigt, dass der FCP primär eine "benutzerzentrierte Metrik" ist, weil er etwas über die Ladegeschwindigkeit aussagt, die ein Besucher erlebt. Er sagt etwas über die user experience 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 exakten Moment, in dem etwas Substanzielles 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 erscheinen kann.

FCP vs LCP: Was ist der Unterschied?

FCP und LCP (Largest Contentful Paint) messen beide die Ladeleistung, erfassen aber 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. Zum Beispiel 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 auch 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 bei allen Performance-Metriken gilt: Ein schnellerer First Contentful Paint Wert ist besser als ein langsamerer.

Wie misst man den First Contentful Paint (FCP)?

Der FCP wird von Google gemessen, indem Daten von echten Nutzern gesammelt werden. Diese Daten werden im CrUX-Datensatz gespeichert. Diese Daten sind öffentlich über die CrUX-API oder Google BigQuery verfügbar. 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 über Google BigQuery abgelesen werden.

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

RUM 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 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 die Plugins nicht stören und möglicherweise den FCP Ihrer Seite verlangsamen.
2. Klicken Sie mit der rechten Maustaste auf die Seite und wählen Sie Element untersuchen. Auf diese Weise öffnen Sie die Chrome-Entwicklerkonsole.
3. Am oberen Rand der Konsole sehen Sie den Lighthouse-Tab. Klicken Sie darauf. Wählen Sie dann unter Kategorien Performance (lassen Sie die anderen leer) und wählen Sie 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, wie hoch der FCP Ihrer Seite ist.

Dies ist ein Screenshot des Lighthouse-Berichts für diese Seite. Der FCP dieser Seite auf einem mobilen Gerä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 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 bei 392ms insgesamt, wobei Desktop bei 372ms und Mobile bei 692ms (1,9x langsamer) liegt. Die Differenz zwischen FCP und TTFB beträgt nur 248ms auf Desktop und 376ms auf Mobile, was darauf hindeutet, dass die Render-blockierende Zeit bei einer gut optimierten Seite einen relativ kleinen Anteil am FCP ausmacht.

Global gesehen erreichen laut dem HTTP Archive Web Almanac 2024 68% der Desktop-Seiten einen guten FCP, während nur 51% der mobilen Seiten dies schaffen. FCP erholte sich 2024 nach einem leichten Rückgang in 2023, was darauf hindeutet, dass Webentwickler zunehmend Render-blockierende Ressourcen angehen.

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

Den First Contentful Paint verbessern

Jetzt, da Sie wissen, was der First Contentful Paint ist, können wir daran arbeiten, ihn schneller zu machen. Die Idee hinter einem schnellen FCP ist eigentlich ganz 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. Ressourcenladeverzögerung: Die Zeit zwischen TTFB und dem Moment, in dem der Browser beginnt, die FCP-Ressource zu laden.
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 nur noch die Time to First Byte und die Element-Render-Verzögerung zu optimieren.

Im Folgenden finden Sie 14 Lösungen, die ich häufig verwende, um den FCP zu verbessern. Aber Vorsicht: Eine Lösung an der falschen Stelle einzusetzen, 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 Auswirkung weiterer Optimierungen beginnt abzunehmen. 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: niedriger ist immer besser.

Sie können die Time to First Byte einfach selbst messen. Das geht folgendermaßen:

1. Verwenden Sie die Tastenkombination Strg-Umschalt-I, um die Entwicklerkonsole von Google Chrome zu öffnen.
2. Am oberen Rand der Konsole sehen Sie einen Network-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, das ist die Anfrage für Ihre Seite selbst.
6. Nun erhalten Sie weitere Informationen über diese Netzwerkanfrage. Klicken Sie auf den Timing-Tab oben in diesen Informationen, um zu sehen, was die TTFB für Ihre 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. Zum Beispiel können Sie seit HTTP/2 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, besonders 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 prü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 Tabellenüberschrift und wählen Sie Protokoll. Laden Sie nun die Seite neu, um zu sehen, welches Protokoll Ihre Seite verwendet.

3. 103 Early Hints

103 Early Hints ist ein relativ neuer HTTP-Statuscode, der es einem Server ermöglicht, vorläufige Response-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 (zum Beispiel eine Datenbankabfrage oder serverseitige Logik). Anstatt den Browser untätig warten zu lassen, sendet der Server eine 103-Antwort mit Preload- und Preconnect-Hinweisen, damit der Browser sofort mit dem Abrufen 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 eintrifft. Die Auswirkung ist am größten bei Seiten mit hoher 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 hat integrierte Unterstützung für Early Hints, und Apache und Nginx können so konfiguriert werden, dass sie diese senden. Lesen Sie mehr in unserem vollständigen 103 Early Hints Leitfaden.

4. Browser-Caching

Die Netzwerkverbindung ist oft ein Schwachpunkt, wenn es um Seitengeschwindigkeit geht. Wäre es nicht viel einfacher, das Netzwerk ganz zu umgehen?

Wenn ein Besucher bereits auf Ihrer Seite 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 wieder benötigt, erscheinen sie blitzschnell aus dem Browser-Cache. 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 "schalten" zu viele Webmaster die Komprimierung "ein" und schauen dann nicht mehr darauf. Und das ist schade, denn es ist einfach ein leichter Weg, die Dinge etwas 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 hat 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 Komprimierung und statischer Komprimierung. Bei dynamischer Komprimierung komprimieren Sie die Datei kurz bevor Sie sie über Ihren Webserver senden; bei statischer Komprimierung wird die komprimierte Datei auf dem Server gespeichert. Dies ist oft eine viel klügere Art zu komprimieren, wird aber selten verwendet.

6. Frühzeitige Web-Fonts mit Resource Hints

Resource Hints initiieren einen Download oder eine Netzwerkverbindung, bevor der Browser dies von selbst tun würde. Einige Netzwerkressourcen, wie Web-Fonts 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 Seite benötigen, ist es fast immer eine gute Idee, einen "Resource Hint" einzufügen. Dadurch wird sichergestellt, dass der Browser sofort mit dem Herunterladen oder Verbinden zur Ressource beginnt. Dadurch ist die Ressource früher verfügbar und der Browser kann früher mit dem Rendern beginnen.

Aber seien Sie vorsichtig mit Resource Hints. Wenn Sie sie falsch einsetzen, 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. Über den Preload-Link laden Sie eine Netzwerkressource herunter, die Sie später benötigen werden. Dies ist oft eine sehr gute Idee bei Fonts, kritischen Skripten und Bildern im sichtbaren Bereich der Seite.

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. Dadurch entfällt die Drittanbieter-Verbindung vollständig und Sie haben die volle Kontrolle über Caching und Auslieferung.

7. Die nächste Seite mit Prefetch vorladen

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

Mit Prefetch können Sie Ressourcen mit niedriger Priorität abrufen. Dies ist eine nützliche Methode, um Ressourcen abzurufen, von denen Sie denken, dass Sie sie später benötigen werden, 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 Seite läuft wahrscheinlich über eine sichere Verbindung. Wenn ein Besucher Ihre Seite eingibt, ohne https hinzuzufügen, wird der Besucher zur nicht-gesicherten Version Ihrer Website weitergeleitet. Wenn jedoch alles richtig eingerichtet ist, wird der Besucher zur sicheren Website weitergeleitet. Sie können dies im grünen Beispiel unten sehen.

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 zur richtigen Seite gelangen.

9. CSS minimieren

Eine externe CSS-Datei ist immer Render-blockierend. Das bedeutet, dass ein Browser normalerweise nicht mit der Anzeige von Inhalten beginnen 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 auf das Herunterladen des Stylesheets warten. Für einen ausführlicheren Leitfaden lesen Sie unseren Artikel über das Beheben und Entfernen von ungenutztem CSS.

Die CSS-Größe mit Shortcode reduzieren

Eine der Möglichkeiten, die CSS-Größe zu reduzieren, ist die Verwendung von Shortcodes. Dies 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 man Selektoren mit einem Komma zusammenführt, Zeilenumbrüche und Leerzeichen entfernt und kürzere Farbcodes schreibt.

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

Könnte so gekürzt werden:

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

10. Critical CSS

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

Critical CSS ist eine Sammlung aller Selektoren (wie body, p, h1 usw.), die Sie benötigen, um den sichtbaren Teil der Seite anzuzeigen. Fügen Sie dieses Critical CSS nicht in ein separates Stylesheet ein; fügen Sie es stattdessen direkt in den <head> der Seite ein. Auf diese Weise 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 nicht direkt für den sichtbaren Teil der Seite benötigen, wird nach dem ersten Rendering-Zyklus geladen. Für Ihren Besucher ist die Seite bereits fertig; niemand bemerkt die neuen Styles, die im Hintergrund noch hinzugefügt werden.

Critical 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 verzögert laden

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 dem Bildschirm anzeigen, und das schließt den FCP ein. Für eine vollständige Übersicht der Verzögerungstechniken lesen Sie 14 Methoden zum Verzögern von JavaScript.

Wir können dies umgehen, indem wir JavaScript verzögern. Sie können dies 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 stattfinden 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 ebenfalls 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 Fonts, externe Bilder, externe Stylesheets oder externe Skripte sind ein potenzieller Engpass, wenn es um den First Contentful Paint geht. 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, wenn es um den First Contentful Paint geht. Bei etwa 99% der Seiten, die wir uns ansehen, ist das FCP-Element eine Textzeile. Wenn Sie externe Web-Fonts verwenden, müssen Sie diese Fonts zuerst von einem Server herunterladen, was natürlich Zeit kostet.

In letzter Zeit haben Web-Fonts mehr Aufmerksamkeit bekommen, und es gibt neuere, schnellere Schriftformate. Das schnellste Schriftformat ist derzeit woff2, gefolgt von woff. Woff2 wird von jedem modernen Browser unterstützt.

Sie können die bevorzugte Reihenfolge Ihrer Web-Font in der CSS font-face Deklaration angeben. Das machen Sie folgendermaßen:

 @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 Web-Fonts ist das Standardverhalten dieser Fonts, den Text auf der Seite nicht anzuzeigen, bis der Font geladen ist. Dies geht normalerweise direkt auf Kosten des First Contentful Paint. Lesen Sie unseren vollständigen Leitfaden zum Thema Sicherstellen, dass Text während des Webfont-Ladens sichtbar bleibt.

Sie können dies lösen, indem Sie die font-display:swap Deklaration verwenden. Damit können Sie wählen, den Text auf der Seite trotzdem anzuzeigen, in einer dem Browser bekannten Schrift, während der Webfont 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 zur 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 der Webfont wird nur angezeigt, wenn er bereits im Browser-Cache vorhanden ist. Für die meisten Seiten ist swap die bessere Wahl für 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 mit dem 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 sind, 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 wiederum direkt auf Kosten des FCP.

Lösen Sie dies durch:

• Teile Ihrer Webseite verzögert laden
  Um die anfängliche Anzeige zu beschleunigen, sollten Sie in Betracht ziehen, 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 Renderns zu überspringen. Sie tut dies, kurz bevor das Element sichtbar wird.
• Große Seiten in mehrere Seiten aufteilen
  Die Anzahl der DOM-Knoten kann reduziert werden, indem große Seiten in mehrere Seiten aufgeteilt werden.
• Infinite Scroll implementieren
  Infinite Scrolling ist im Grunde Lazy Loading: Beim Scrollen durch wiederholte 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. Zum Beispiel kann die Überprüfung des last-child-Status für jedes div-Element auf Ihrer Seite aufwendig sein.
• Web Workers verwenden, um den Haupt-Thread Ihres Browsers zu entlasten
  Web Workers sind JavaScript, das parallel zu Ihrer Webseite laufen 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 Detailartikel:

• Google Fonts selbst hosten: Eliminieren Sie eine Drittanbieter-Verbindung und erhalten Sie die volle Kontrolle über die Font-Auslieferung.
• Sicherstellen, dass Text während des Webfont-Ladens 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 abrufen, bevor das HTML eintrifft.
• Largest Contentful Paint (LCP) Leitfaden: FCP und LCP teilen viele Optimierungsstrategien. Wenn Ihr FCP langsam ist, wird Ihr LCP es auch sein.
• Time to First Byte (TTFB) Leitfaden: TTFB ist der größte einzelne Beitrag zum FCP. Beginnen Sie hier, wenn Ihre Serverantwort langsam ist.