Core Web Vitals: Der ultimative Guide 2021

Die Core Web Vitals sind ein essenzieller Bestandteil des Page Experience Rankingfaktors. Damit rücken sie in den Fokus, wenn es um technische Optimierung, bessere Rankings und User Experience geht. Doch was genau sind die Core Web Vitals und welchen Einfluss haben sie auf die Page Experience? Das Thema ist komplex, aber wir haben das Wichtigste verständlich zusammengefasst. Ganz nach dem Motto der Fantastischen Vier: „CLS, FID und LCP. TTFB, CSS ojemine.“

Was sind die Core Web Vitals?

Die Core Web Vitals sind Qualitätssignale von Google, um darzustellen, wie die Erfahrung der Nutzer auf einer Website ist. Mit diesen Signalen lässt sich die User Experience einer Webseite bewerten. Der Fokus liegt hier auf den gemessenen Werten des Chrome User Experience Reports. Die Daten werden also nicht wie beispielsweise beim Lighthouse Report simuliert und gemessen, sondern basieren auf echten Nutzerdaten.

Das sind die Kennzahlen:

• First Input Delay (FID)
• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)

Da es auch kleine Webseiten mit zu wenig Daten gibt, misst Google PageSpeed Insights zusätzlich noch live – die sogenannten Labdaten. Hierzu wird ein Seitenzugriff aus dem mobilen Netz für den mobilen Score simuliert.

In den Labdaten werden zusätzliche Messwerte angezeigt (Speed Index, Time to Interactive und Total Blocking Time), aber der First Input Delay (FID) fehlt. Das liegt daran, dass der First Input Delay durch eine Interaktion mit der Webseite gemessen wird, beispielsweise ein Klick auf die Webseite. Da in diesem simulierten Test keine solche Interaktion simuliert werden kann, fehlt dieser Wert.

Mit welchen Tools können Sie die Core Web Vitals messen?

Es gibt mehrere Online-Tools von Google zur Messung der Core Web Vitals.

Außerdem misst die Google Search Console die Core Web Vitals für die jeweilige Property. Die Daten stammen aber aus dem Chrome User Experience Report. Dort können Sie die zeitliche Entwicklung der Bewertungen – aufgeteilt in mobil und Desktop – nachvollziehen. Google unterscheidet die URLs lediglich nach:

• „schlechte URLs“
• „zu optimierende URLs“
• „gute URLs“

Außerdem werden nur Beispiel-URLs aufgelistet und nicht alle betroffenen Seiten. Das macht es natürlich schwierig, einen genauen Überblick über die betroffenen URLs zu bekommen.

Es erscheinen allerdings immer mehr Browser-Plugins zur Messung der Core Web Vitals, sodass Sie auf einem Blick erkennen, ob es Probleme mit einer URL gibt.

Was ist der Page Experience Rankingfaktor?

Der Page Experience Rankingfaktor ist eine Erweiterung der bestehenden Signale, die Google nutzt, um die Page Experience zu bewerten. Neu sind die Kennzahlen aus den Core Web Vitals. Somit ist der Page Experience Rankingfaktor kein neuer Faktor zur Bestimmung des Rankings, sondern dieser wird nun um weitere Signale erweitert.

Der Page Experience Rankingfaktor lässt folgende Signale zur Bewertung der Page Experience einfließen:

• Ladezeit / Largest Contentful Paint (LCP)
• Interaktivität / First Input Delay (FID)
• Visuelle Stabilität / Cumulative Layout Shift (CLS)
• Mobile Friendliness
• HTTPS
• Keine aufdringlichen Pop-ups

Das Ziel dieses Rankingfaktors ist es, Webseiten mit einer guten Seitenerfahrung besser zu gewichten.

Was ist der Largest Contentful Paint (LCP)?

Der Largest Contentful Paint (LCP) gibt an, wie viel Zeit die Webseite benötigt, um den größten Inhalt der Seite zu laden. Dieser Inhalt kann ein Bild oder Textelement sein. Hier gibt es drei Stufen zur Bewertung der Ladezeit.

• Unter 2,5 Sekunden: Die Webseite hat einen optimalen Wert (grüner Bereich).
• Zwischen 2,5 und 4 Sekunden: Die Webseite ist verbesserungswürdig (gelber Bereich).
• Über 4 Sekunden: Die Webseite ist schlecht (roter Bereich).

Der LCP hat momentan die höchste Gewichtung bei der Bewertung des Performance Scores und kann somit auch der größte Hebel bei der Optimierung sein.

So identifizieren Sie den Largest Contentful Paint

Der PageSpeed Insights Report gibt Empfehlungen, um den Performance Score zu verbessern. Diese Empfehlungen sind jedoch auf alle Messwerte bezogen.

Möchten Sie iterativ vorgehen und speziell den LCP optimieren, müssen Sie diesen auf der jeweiligen Seite zunächst identifizieren.

Hier eine Anleitung:

1. Öffnen Sie Google Chrome im Inkognito-Modus.
2. Navigieren Sie zur gewünschten Webseite.
3. Öffnen Sie die DevTools mit F12 (Alternativ: Rechtsklick → Untersuchen).
4. Wenn Sie die mobile Ansicht testen wollen, dann klicken Sie auf das Mobil-Symbol oben links in den DevTools (Toggle Device Toolbar).
5. Navigieren Sie in den DevTools zum Reiter Performance.
6. Nun können Sie eine Aufnahme starten und die Seite währenddessen neu laden.
7. Warten Sie mindestens 5 Sekunden und stoppen Sie die Aufnahme.

Nach einer kurzen Ladezeit ist das Netzwerkprofil erstellt und es sollte ein ähnliches Bild wie im obigen Screenshot zu sehen sein. Dieses Profil zeichnet den Seitenaufbau mit allen Ressourcen auf.

Links sehen Sie die einzelnen Elemente – aufgeteilt in Kategorien. Uns interessiert die Kategorie Timings: Hier wurden Marker gesetzt, um zu visualisieren, wann bestimmte Elemente im Ladevorgang abgeschlossen wurden.

So optimieren Sie den Largest Contentful Paint

In unserem Beispiel haben wir ein Bild als größten zu ladenden Inhalt identifiziert. Das ist oftmals der Fall, jedoch ist es auch möglich, dass beispielsweise ein Textelement der größte Inhalt ist. Somit gibt es mehrere Lösungsansätze, um den LCP zu optimieren.

Außerdem macht es in seltenen Fällen Sinn, ausschließlich ein Element zu optimieren, da das zweitgrößte Element nach der Optimierung möglicherweise an die erste Stelle rückt. Dieses Element kann aber ebenfalls eine zu lange Ladezeit besitzen. Also sollte man hier ganzheitlich vorgehen und alle Elemente der Seite optimieren.

Häufige Gründe für einen schlechten LCP sind:

• eine langsame Serverantwortzeit
• eine langsame Ressourcen-Ladezeit
• JavaScript und/oder CSS blockieren das Rendering der Seite

1. Langsame Serverantwortzeit optimieren

Wenn ein Element auf der Webseite eine zu hohe Ladezeit hat, kann es am Server liegen: Der Webserver, auf dem die Seite gehostet wird, benötigt zu lange, die Inhalte an den Browser zu senden.

Das beeinflusst unter anderem auch den Largest Contentful Paint. Ein guter Indikator für die Frage, ob Sie die Serverantwortzeit optimieren sollten, ist die Time to First Byte (TTFB). Eine gute Time to First Byte liegt bei unter 0,2 Sekunden, jedoch ist dieser Wert nicht in Stein gemeißelt und hängt von vielen weiteren Faktoren ab. In unserem Fall nutzen wir die TTFB dazu, um herauszufinden, ob eine Optimierung den LCP auf der Domain verbessern kann.

Zur Verbesserung der langsamen Serverantwortzeit können folgende Dinge Abhilfe schaffen:

Implementierung eines Content Delivery Networks (CDN)

Ein Content Delivery Network (CDN) hostet Kopien der eigenen Webseite auf verschiedenen Servern an verschiedenen Orten. Hat die Webseite viel internationalen Traffic, doch der Server liegt in Deutschland, so sind die Antwortzeiten alleine aus rein physikalischen Gründen länger, da die Anfrage des Browsers um die halbe Welt geleitet werden muss.

Caching von Assets

Wenn Ihre Webseite viel statischen Content beinhaltet, der sich nicht bei jeder Anfrage ändert, so sollten Sie diese Inhalte schon vorab speichern (cachen). Bei einer Anfrage wird das schon fertig generierte Element direkt an den Browser gesendet, ohne dass es erst generiert werden muss. Das spart Zeit.

Natürlich gibt es noch einige weitere Möglichkeiten zur Verbesserung von langsamen Serverantwortzeiten.

2. Langsame Ressourcen-Ladezeit optimieren

Anders als eine zu langsame Antwortzeit vom Server betrifft die Ressourcen-Ladezeit nur bestimmte Ressourcen der Seite. Beispielsweise können diese Ressourcen Textelemente, Bilder oder Videos sein, die above-the-fold, also im sichtbaren Bereich der Seite, bei einem Aufruf geladen werden. Diese Elemente beeinflussen den Largest Contentful Paint (LCP).

Für die Optimierung der Ressourcen-Ladezeit wiederum gibt es folgende Möglichkeiten:

Komprimierung von Bildern und/oder Konvertierung in ein anderes Format

Oft werden Bilder als sogenannte Hero-Images verwendet. Das sind Bilder, die an oberster Stelle einer Seite platziert sind und häufig die gesamte Breite des Bildschirms einnehmen. Diese Hero-Images sollten nicht zu groß sein – sowohl in Bezug auf die Dateigröße als auch in der Dimensionierung.

Das Bild sollte nur in der Dimensionierung bereitgestellt werden, in der es auch auf der Seite zu sehen ist, ansonsten vergeuden Sie unnötig Speicher.

Außerdem sollten alle Bilder komprimiert werden, bevor diese auf den Webserver geladen werden. Hierfür gibt es verschiedene Tools, wie zum Beispiel tinypng.

Zusätzlich ist es auch möglich, die Bilder in modernen Formaten bereitzustellen. Das derzeit beliebteste Format dürfte hier wohl WebP sein. Allerdings sollten Sie darauf achten, welche Browser dieses Format unterstützen. Safari ist bei neuen Formaten etwas langsamer. Sie können aber auch Bildformate dynamisch je nach Browser ausspielen, jedoch bedeutet das zusätzlichen technischen Aufwand.

Preload von wichtigen Ressourcen

Wird ein HTML-Dokument aufgerufen, werden zusätzlich viele Anfragen gestellt, um die nötigen Ressourcen zu laden, die innerhalb des Quellcodes verlinkt sind.

Oft sind das CSS-Dateien, JavaScript-Dateien und Fonts. Jedoch ist es möglich, das Laden dieser Ressourcen zu priorisieren bzw. wichtige Ressourcen einer Seite schon vorab zu laden. Hier kommt preload ins Spiel.

Wird eine Ressource mit dem Wert preload im Quelltext ausgezeichnet, so wird dem Browser mitgeteilt, dass er diese Ressource früher als normalerweise laden soll. Der Wert preload wird in das rel-Attribut geschrieben und sieht so aus:

Beispiel einer Implementierung von rel=preload

Da Fonts im anonymous mode geladen werden, muss hier noch zusätzlich das crossorigin-Attribut gesetzt werden.

3. Javascript und CSS blockieren das Rendern der Seite

Der Browser versucht alle Inhalte der HTML-Datei anzuzeigen. Sobald er eine externe Datei wie ein CSS-File oder eine JS-Datei entdeckt, pausiert er das Rendern um diese aufzurufen. Dieser Vorgang blockiert das Rendern der Seite und kann für einen zu hohen Messwert beim Largest Contentful Paint (LCP) sorgen.

Minifizierung von CSS und JavaScript

Um die blocking time der CSS- und JavaScript-Dateien zu reduzieren, gibt es verschiedene Möglichkeiten. Die zunächst einfachste ist die Minifizierung.

Viele Content Management Systeme (CMS) und Shopsysteme bieten Plugins an, mit denen sich die CSS- und JS-Dateien minifizieren lassen. Bei diesem Vorgang werden der Whitespace und Kommentare aus dem Code entfernt, sodass die Größe der Dateien reduziert wird und diese schneller geladen werden können.

Aufschieben von nicht kritischen CSS (defer non-critical CSS) und Verwendung von inline CSS

Diese Optimierung kann den wohl größten Einfluss auf den LCP haben, ist aber gleichzeitig auch mit dem größten Aufwand verbunden. Die Idee dahinter ist folgende:

Oft werden beim initialen Seitenaufruf zwar CSS-Dateien geladen, jedoch werden nur Bruchteile der Dateien überhaupt genutzt. Beispielsweise die Styles der Schrift oder die Farbe des Hintergrunds.

Die CSS-Dateien enthalten aber noch viele andere Styles, die entweder gar nicht oder weit unten auf der Seite genutzt werden. Diese Elemente könnten somit vorerst aufgeschoben werden, sodass nicht genutzte Styles das Rendern der Seite nicht blockieren.

Hier ist es möglich eine Kombination aus inline CSS und Aufschieben der restlichen Styles anzuwenden. Doch hierfür ist es nötig, zu wissen, welche Styles in den CSS-Dateien überhaupt für eine spezifische Seite initial benötigt werden, damit diese inline verwendet werden können. Der Rest wird dann aufgeschoben.

Identifizierung von kritischen CSS

1. Öffnen Sie Google Chrome und navigieren Sie auf die Seite, auf der das kritische CSS identifiziert werden soll.
2. Öffnen Sie die DevTools mit F12 (Alternativ: Rechtsklick → Untersuchen).
3. Klicken Sie auf den Tab Sources und dann unten links auf das Dreipunkt-Menü und wählen Coverage aus.
4. Laden Sie die Seite neu.

Nun sehen Sie im sogenannten Coverage Report alle Ressourcen nach Typ sortiert. Interessant für Sie sind rechts die Unused Bytes und die Usage Visualization. Hier sehen Sie bei der ersten CSS-Datei, dass 94,8 % des Inhalts überhaupt nicht genutzt werden.

Also könnten Sie die 5,2 %, die genutzt werden, inline verwenden und den Rest aufschieben. Um genau herauszufinden, um welche Styles es sich handelt, klicken Sie einfach auf das entsprechende Element. In unserem Fall auf die erste CSS-Datei.

Optimierung von kritischen CSS

Nun sehen Sie im oberen Bereich des DevTools den Inhalt der entsprechenden CSS-Datei. Links ist farblich markiert, welche Styles genutzt werden, und welche nicht. Die rot markierten sind die ungenutzten, während die grünen die kritischen sind. Diese werden also für den initialen Seitenaufbau benötigt.

Die grün markierten Klassen oder CSS-Selektoren werden nun inline in einem <style>-Tag im head des HTML-Dokuments eingetragen. Das kann so aussehen:

In diesem Beispiel sind der Übersicht halber nicht alle grün markierten Anweisungen aus dem Screenshot aufgelistet. In der Praxis sollte das aber unbedingt getan werden.

Der Rest der CSS muss nun noch asynchron geladen werden. Dazu muss die bisherige Implementierung zum Aufruf der CSS geändert werden. Dies würde bei einer CSS-Datei mit dem Namen „td_style.css“ folgendermaßen aussehen:

Was ist der First Input Delay (FID)?

Der First Input Delay (FID) ist eine Core Web Vitals Metrik, welche die Interaktivität und Reaktionszeit einer Seite misst. Im Gegensatz zum Largest Contentful Paint (LCP) oder dem Cumulative Layout Shift (CLS) ist der First Input Delay eine Metrik, die nur mit Hilfe echter Userdaten messbar ist. Das liegt daran, dass diese Metrik sich auf reale Klicks bezieht. Ein simulierter Test über Labdaten ist somit nicht möglich.

Damit es unabhängig von den Felddaten möglich ist, den First Input Delay zu testen, empfiehlt Google die TBT (Total Blocking Time) als alternativen Richtwert. Die Total Blocking Time ist die Zeit zwischen dem First Contentful Paint und der Time to Interactive, also die Zeit zwischen dem Laden des ersten Inhalts und der Zeit bis zur ersten Interaktivität.

So identifizieren Sie einen schlechten First Input Delay (FID)

Möchten Sie im PageSpeed Test herausfinden, ob Sie den First Input Delay optimieren sollten, schauen Sie sich die TBT (Total Blocking Time) an. Die Total Blocking Time sollte 300 ms nicht überschreiten. Sind genügend echte Daten von Usern vorhanden, so können Sie auch in den Felddaten nachsehen, ob der First Input Delay von Google als verbesserungswürdig eingestuft wird.

So optimieren Sie den First Input Delay (FID)

Wenn der Browser JavaScript ausführt, ist in der Regel keine Interaktion mit der Webseite möglich. Aus diesem Grund sind die Optimierungsmöglichkeiten alle auf technische Anpassungen im JavaScript Code bezogen.

1. Nutzung von Web Workers

Der Flaschenhals bei modernen Webseiten ist oft der sogenannte Main Thread. In der Regel wird ein Main Thread pro Browser Tab genutzt, um eine Seite zu rendern und JavaScript auszuführen. Um Webseiten außerhalb des Main Threads auszuführen, helfen uns sogenannte Web Worker.

Um nicht zu sehr in technische Feinheiten abzudriften, sei an dieser Stelle nur gesagt, dass Web Workers parallel zum Main Thread laufen und diesen somit entlasten können. Die Implementierung kann jedoch ziemlich komplex sein und sollte definitiv nur von erfahrenen Entwickler:innen durchgeführt werden. Bei der Optimierung des FID kann die Erstellung eines Web Workers jedoch ein großer Hebel sein.

2. Aufschieben von nicht kritischen JavaScript (defer non-critical JavaScript)

Genauso, wie es möglich ist, nicht genutztes CSS beim initialen Laden einer Webseite aufzuschieben, ist dies auch bei JavaScript möglich. Genaugenommen geht es darum, nur den Code zu laden, der auch tatsächlich für die Seite gebraucht wird.

Identifizierung von kritischem JavaScript

Die Identifizierung von kritischem JavaScript funktioniert genauso, wie die Identifizierung von kritischem CSS. Im Coverage Report müssen Sie stattdessen nur die .js Dateien markieren.

Sollte der Webauftritt lediglich eine oder wenige JS-Dateien haben, so sollte der Code aufgesplittet werden. Das alleine kann schon einen gewünschten Effekt auf den FID haben.

Optimierung von kritischem JavaScript

Alle nicht kritischen JavaScript Implementationen können nun mithilfe dieser Anpassung aufgeschoben werden:

Alle Third-Party Scripte sollten ebenfalls mit Hilfe dieser Anpassung optimiert werden.

Was ist der Cumulative Layout Shift (CLS)?

Der Cumulative Layout Shift (CLS) ist eine Core Web Vitals Metrik, welche die Instabilität von Content auf einer Seite misst. Der Fokus liegt auf der Stärke und Weite von Verschiebungen von Elementen wie Bildern oder Buttons im Viewport der Seite.

Ruft der User eine Webseite auf und nach ein paar Sekunden wird der Text nach unten verschoben, weil ein Element am Anfang des Textes nachgeladen wurde, spricht man von einem Layout Shift. Diese Art von Verschiebung führt zu einer schlechten User Experience, da der User sich schnell „verklicken“ kann.

So identifizieren Sie einen Layout Shift

1. Öffnen Sie Google Chrome und navigieren Sie im Inkognito-Modus auf die gewünschte URL.
2. Öffnen Sie die Dev Tools mit F12.
3. Klicken Sie oben in den Dev Tools auf den Reiter Performance (Leistung).
4. Starten Sie eine Aufnahme und laden Sie die Seite neu.
5. Warten Sie etwas und stoppen Sie die Aufnahme.

Nun wurde der Seitenaufbau aufgenommen und Sie sehen in der Kategorie „Experience“ (links zu sehen) das Label „Layout Shift“ (sofern ein Layout Shift vorhanden ist).

Dort, wo das Label erscheint, ist in der Zeitleiste der Aufnahme ein Layout Shift aufgetreten. Klicken Sie nun auf eines der Labels, so wird auf der Webseite das Element mit dem Layout Shift hervorgehoben.

So optimieren Sie einen Layout Shift

Ein Layout Shift kann auf verschiedene Elemente einer Webseite zurückzuführen sein, weshalb es für jede Art von Element unterschiedliche Möglichkeiten gibt, diesen zu beheben.

Die gängigsten Ursachen für einen Layout Shift sind:

• Bilder ohne definierte Dimensionen
• Display Ads ohne definierte Dimension
• Web Fonts die FOIT (Flash of Invisible Text) oder FOUT (Flash of Unstyled Text) verursachen

1. Bilder ohne definierte Dimension optimieren

Wie der Name schon vermuten lässt, lassen sich Bilder, die einen Layout Shift verursachen, durch eine Zuweisung von Dimension bzw. Abmessung optimieren.

Sie sollten den Bildern width und height Attribute zuweisen, damit dieser Platz beim Ladevorgang der Seite reserviert ist und es somit nicht zu einem Layout Shift kommt.

Dies könnte dann so aussehen:

2. Display Ads ohne definierte Dimension optimieren

Display Ads können optimiert werden, indem Sie das Element der Anzeige stylen, bevor die Anzeigenbibliothek im Quelltext geladen wird.

Hierzu sollten Sie das DOM-Element statisch stylen, indem Sie dieselben Abmessungen wählen, die an die tag library übergeben werden.

Außerdem sollten Anzeigen möglichst weit unten im Viewport platziert werden, da weit oben platzierte Anzeigen bei einem Layout Shift auch mehr Inhalte nach unten verschieben. Generell sind Positionen für Display Ads zu bevorzugen, die möglichst wenig Main Content nach unten verschieben könnten.

3. Web Fonts optimieren

Wenn Web Fonts geladen und gerendert werden, können sie zum einen einen Layout Shift verursachen, indem das Fallback beim Ladevorgang durch das neue Font ausgetauscht wird (FOUT – flash of unstyled text). Außerdem kann unsichtbarer Text angezeigt werden, bis das Web Font geladen und gerendert wird (FOIT – flash of invisible text).

Nutzen Sie <link rel=preload> bei den Web Fonts, kann dies Abhilfe schaffen, indem die Fonts vorab geladen werden. Somit können diese noch in den First Paint des Ladevorgangs der Webseite „rutschen“, was wiederum keinen Layout Shift verursacht.

Jedoch ist diese Optimierung kein Garant für die Vermeidung eines Layout Shift, eventuell müssen weitere Optimierungen für Web Fonts vorgenommen werden.

Fazit zur Optimierung der Page Experience

Es gibt viele mögliche Baustellen bei der Optimierung der Page Experience. Mit den Core Web Vitals hilft Google Webseitenbetreiber:innen allerdings, endlich einen Überblick über die verschiedenen Kennzahlen zu erhalten.

In der Vergangenheit war es in puncto PageSpeed schwierig, die Relevanz von Metriken für die Suchmaschine einzuschätzen. Nicht immer ist es notwendig, alle Vorschläge umzusetzen, um den Core Web Vitals Check bei Google zu bestehen.

Außerdem unterscheiden sich die nötigen Optimierungen je nach Shopsystem, CMS oder Verwendung von JavaScript stark. Fakt ist, dass die Core Web Vitals schon jetzt sinnvolle Metriken sind, um die User Experience auf Webseiten zu verbessern.

Es ist zu erwarten, dass in Zukunft noch weitere Metriken hinzukommen und die Core Web Vitals ergänzen. Diese Rankingfaktoren sind jedoch im Gegensatz zu den inhaltlichen Rankingfaktoren (zum Beispiel EAT) technischer Natur. Das macht eine gute Zusammenarbeit mit dem Entwicklungsteam oder technischen Dienstleister:innen unerlässlich. Bedenken Sie aber, dass die Page Experience mit ihren Core Web Vitals nur ein Faktor von vielen ist, den es beim Aufbau einer nachhaltigen Webseite zu beachten gilt.

Ihnen gefällt der Artikel, jedoch sind sie von der Menge der Informationen erschlagen und benötigen Unterstützung bei der Optimierung des PageSpeed? Rufen Sie uns an oder schreiben Sie uns eine Nachricht und wir werden Ihnen bei Ihrem Problem weiterhelfen.