Core Web Vitals: Alles, was Du über Googles neuesten Rankingfaktor wissen musst

Die Core Web Vitals sind Messwerte, mit denen Google die Qualität der User Experience (UX) bzw. Nutzererfahrung einer Website realitätsnah bewertet. Wie der Name „Core Web Vitals“ verrät, erachtet Google diese Messwerte als entscheidend dafür.

Und ab Mai Juni (Update wurde verschoben) 2021… werden sie direkten Einfluss auf Deine Suchmaschinen Rankings haben.

Willst Du Deinen organischen Traffic erhalten und in Zukunft weiter steigern? Dann solltest Du dafür sorgen, dass Deine Core Web Vitals im grünen Bereich sind.

Aber keine Panik. In diesem Guide erklären wir Dir alles, was Du über Core Web Vitals wissen musst, einschließlich:

• wofür sie genau stehen
• welchen Einfluss sie auf Deine Google Rankings haben
• wie Google sie misst
• wo Du die Core Web Vitals Deiner Website prüfen kannst
• wie Du häufige Probleme für alle drei Core Web Vitals findest und löst

Über das Inhaltsverzeichnis kannst Du direkt zu den einzelnen Themen springen.

Lass uns damit beginnen, was Core Web Vitals genau sind und welchen Einfluss sie auf Deinen Suchmaschinen Traffic haben.

Was sind Core Web Vitals?

Google möchte Websites belohnen, die ihren Nutzern eine gute User Experience (UX) bieten.

Doch dabei gibt es ein Problem: User Experience ist schwer zu messen.

Zwar geben Statistiken wie Bounce Rate oder Verweildauer Hinweise, doch beide Kennzahlen können manipuliert werden. Des Weiteren gibt es ja nach Zweck einer einzelnen Seite oder Website große Unterschiede.

Hier kommen die „Web Vitals“ ins Spiel.

Sie bestehen aus mehreren Statistiken und Signalen, von denen Google mit Sicherheit weiß, dass sie sich positiv (oder negativ) auf die User Experience auswirken, und die vom Algorithmus gemessen (oder beobachtet) werden können.

Googles Web Vitals konzentrieren sich auf Ladezeit und Layoutstabilität, sowie darauf, wie schnell eine Seite auf eine Aktion eines Nutzers reagiert.

Warum Google genau diese Werte ausgewählt hat? Weil sie objektiv sind:

• Eine schnelle Website ist für Nutzer immer besser als eine langsame.
• Eine Website, die schnell auf Userinteraktionen reagiert, führt bei Nutzern nicht zu Frustration.
• Ein stabiles Layout verhindert unabsichtliche Klicks.

Macht soweit Sinn, oder?

In Zukunft werden Web Vitals einen noch größeren Einfluss darauf haben, wie Google Websites rankt. Konkret bedeutet das:

Indem Du die User Experience Deiner Website verbesserst, erhöhst Du Deinen organischen Traffic.

Aber aufgepasst… nicht alle „Web Vitals“ gehören zu den „Core Web Vitals“.

Sehen wir uns das genauer an.

So beeinflussen die Core Web Vitals zusammen mit anderen Speed- und UX-Faktoren in Zukunft Deine Google Rankings

Damit es nicht zu unübersichtlich wird, halte ich die Unterscheidung ganz einfach: Die Core Web Vitals (CWV) sind eine Untergruppe der Web Vitals. Mit der Zeit wird Google die CWV um zusätzliche Kennzahlen erweitern, doch im Moment gibt es nur drei.

Beachte: Die Kennzahlen sind komplex und nicht so einfach in nur einem Absatz zu erklären. Darum keine Sorge, falls Du die Begriffe noch nicht kennst. Wir gehen später im Detail auf alle drei ein.

1. Largest Contentful Paint (LCP)

Dieser Begriff bezeichnet die Dauer, bis das größte sichtbare „Above the fold“-Element auf einer Seite vollständig geladen ist. Um Googles Core Web Vitals Test zu bestehen, muss das Largest Contentful Paint-Element einer Seite innerhalb von 2,5 Sekunden komplett geladen sein.

2. First Input Delay (FID)

Dieser Begriff bezeichnet die Dauer zwischen der ersten Aktion, die ein Nutzer auf einer Seite durchführt (z.B. der Klick auf einen Button oder in ein Suchfeld, oder das Öffnen eines Menüs) und der Antwort der Website. Um Googles Core Web Vitals Test zu bestehen, darf der First Input Delay einen Wert von 100 Millisekunden nicht überschreiten.

3. Cumulative Layout Shift (CLS)

Dieser Begriff bezieht sich auf die visuelle Stabilität einer Seite. Alle Elemente, die sich während der Ladephase verschieben, erhöhen den CLS-Wert einer Seite. Um Googles Core Web Vitals Test zu bestehen, muss eine Seite einen Cumulative Layout Shift-Wert unter 0,1 erzielen.

Neben den „Core“ Kennzahlen gibt es noch weitere Web Vitals:

• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Total Blocking Time (TBT)
• Time to Interactive (TTI)

Und zu guter Letzt gibt es noch vier traditionelle UX Faktoren:

• Ist eine Website für mobile Endgeräte optimiert?
• Nutzt sie HTTPS?
• Kann sie sicher gebrowst werden?
• Verzichtet sie auf störende Interstitial-Werbung (zum Beispiel lästige Pop-up-Anzeigen)?

Diese Punkte gehören laut Google zwar nicht konkret zu den Core Web Vitals, doch wir würden sie trotzdem dazu zählen, da sie gemeinsam Googles Signale für die Nutzerfreundlichkeit einer Seite bilden.

Ab Juni 2021 haben diese Signale direkten Einfluss auf die Google Rankings.

„Heute können wir bekanntgeben, dass die Signale für die Nutzerfreundlichkeit von Seiten im Ranking im Juni 2021 eingeführt werden. Mit diesen neuen Signalen kombinieren wir die Funktionen von Core Web Vitals mit den bestehenden Funktionen der Google Suche, darunter Optimierung für Mobilgeräte, Safe Browsing, HTTPS-Sicherheit und Richtlinien zur Vermeidung störender Einflüsse in der mobilen Erfahrung.“

Das bedeutet, dass Du den Core Web Vitals Test bestehen musst, wenn Du im Suchmaschinen Ranking weit oben stehen möchtest.

Traditionelle UX Signale wie die mobile Optimierung, HTTPS, und der Verzicht auf Interstitials gelten übrigens bereits als Rankingfaktor.

Mit großer Wahrscheinlichkeit werden sie auch weiterhin als einzelne Rankingfaktoren gewertet und tragen zusätzlich zum allgemeinen “UX Score” einer Seite bei.

Warum die Optimierung der Core Web Vitals Deiner Website aus SEO Sicht unerlässlich ist

Die Core Web Vitals werden Deine Rankings in Zukunft direkt beeinflussen.

Bestehst Du Googles CWV-Test, dann stehen die Chancen für Deine Website gut, in den Suchergebnissen höher zu ranken.

Bestehst Du den Test nicht, kann es hingegen passieren, dass Deine Rankings sich verschlechtern.

Falls Du immer noch nicht davon überzeugt bist, wie wichtig die Optimierung Deiner Core Web Vitals ist, dann haben wir einen weiteren guten Grund für Dich:

1. Seiten mit guter Page Experience kommen für Googles Top Stories in der mobilen Ansicht infrage

Für viele Suchanfragen, die sich auf aktuelle News beziehen, zeigt Google einen sogenannten „Top Stories“ Abschnitt oberhalb der Suchergebnisse.

Damit belegen diese den besten Platz in den Suchergebnissen.

Im Moment muss Deine Website AMP verwenden, um für Googles „Top Stories“ in der mobilen Ansicht infrage zu kommen. Doch ab Juni 2021 wird sich dies ändern:

„Alle Seiten, die den Inhaltsrichtlinien von Google News entsprechen, sind zulässig. Wir priorisieren beim Ranking von Ergebnissen Seiten mit hoher Nutzerfreundlichkeit, unabhängig davon, ob sie mit AMP oder einer anderen Webtechnologie implementiert wurden.“

Falls Deine Website den Core Web Vitals Test nicht besteht, verpasst Du damit die Chance auf ziemlich viel Traffic.

2. Seiten mit guten Core Web Vitals werden möglicherweise in den Suchergebnissen hervorgehoben

Du willst noch einen Beweis dafür, wie wichtig die Core Web Vitals und Page Experience in Zukunft sein werden?

Google überlegt, Seiten, die die Core Web Vitals und Page Experience Kriterien erfüllen, möglicherweise direkt in den Suchergebnissen zu markieren:

„Zusätzlich zu den oben beschriebenen Änderungen planen wir auch das Testen eines visuellen Indikators, mit dem Seiten mit einer guten Nutzerfreundlichkeit in den Suchergebnissen hervorgehoben werden.“

Für Deine Click-Through-Rate könnte diese Maßnahme mit Sicherheit einen großen Unterschied machen!

Nun weißt Du, wie wichtig es ist, Deine Core Web Vitals zu optimieren. Im nächsten Schritt sehen wir uns an, wie Google sie überhaupt misst.

Wie misst Google die Core Web Vitals?

Wenn Du Deine Website mit Googles PageSpeed Insights Tool prüfst, siehst Du, dass der Bericht in zwei Abschnitte aufgeteilt ist: „Labdaten“ und „Felddaten“.

Der Unterschied zwischen den beiden? Laut Google basieren Labdaten

auf einem simulierten Seitenaufbau auf einem einzelnen Gerät und unter festgelegten Netzwerkbedingungen.

Mit anderen Worten: Diese Daten basieren nicht auf tatsächlichen Nutzerinteraktionen mit Deiner Website.

Felddaten hingegen werden von Googles Chrome User Experience Report bereitgestellt.

The Chrome User Experience Report is powered by real user measurement of key user experience metrics across the public web, aggregated from users who have opted-in to syncing their browsing history, have not set up a Sync passphrase, and have usage statistic reporting enabled.

Laut Google basiert dieser Bericht also auf dem Verhalten von echten Benutzern auf öffentlich zugänglichen Websites, gemessen anhand der wichtigsten User-Experience-Kennzahlen. Diese Daten werden mithilfe von Usern gesammelt, die ihr Einverständnis zum Synchronisieren ihres Browserverlaufs gegeben, kein Synchronisierungspasswort festgelegt und Berichte zu Nutzungsdaten aktiviert haben.

Kurz gesagt sammelt Google Millionen von Daten von Chrome Nutzern auf der ganzen Welt. Zu diesen Daten gehören unter anderem auch die drei Core Web Vitals.

Die Felddaten, die Dir angezeigt werden, basieren also auf tatsächlichen Besuchen Deiner Website.

Für Datenschutz-Kritiker sind dies zwar keine guten Neuigkeiten, als Websitebesitzer kann man so jedoch verfolgen, wie sich die eigene Website bei echten Nutzern bewährt.

Beachte: Weiter unten gehen wir auf zusätzliche Tests ein, mit denen Du die Core Web Vitals Deiner Website prüfen kannst. Zuerst wollen wir die drei Core Web Vitals jedoch im Detail betrachten.

Warum Du alle drei Core Web Vitals optimieren solltest

Nachdem wir jetzt wissen, woher die Daten kommen, nehmen wir die drei Core Web Vitals einmal genauer unter die Lupe.

Zur Erinnerung, es geht um diese drei Messwerte:

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

Google stuft die drei Core Web Vitals jeweils in drei Kategorien ein: „Good“ (gut), „Needs Improvement“ (verbesserungswürdig) und „Poor“ (schlecht).

Viele der Faktoren, die Largest Contentful Paint beeinflussen, haben auch auf First Input Delay und zum Teil sogar auf Cumulative Shift Auswirkungen.

Normalerweise ist LCP der erste Baustein der Core Web Vitals (Ladevorgang > Interaktivität > Visuelle Stabilität), doch wir befassen uns zuerst mit First Input Delay. Der Grund dafür ist ein gängiges Problem beim Ladevorgang, das in der Regel den größten Effekt auf FID hat.

Grundsätzlich gilt jedoch, dass alle drei Core Web Vitals in Verbindung zueinander stehen. Optimiert man LCP, hat das zum Beispiel oft auch positive Auswirkungen auf FID und CLS.

Und um Googles Core Web Vitals Test zu bestehen, müssen alle drei Messwerte im grünen Bereich sein.

Lass uns also den ersten Teil der Core Web Vitals betrachten.

First Input Delay (FID)

Bei First Input Delay geht es um die Reaktionszeit Deiner Seite. Genauer gesagt gibt er die Dauer an, bis Deine Seite auf die erste „Aktion“ eines Nutzers reagiert.

Was zählt bei der Messung von FID als Aktion?

• Klicken oder Tippen auf einen Button
• Klicken eines Links
• Öffnen eines Menüs
• Klicken auf ein Formularfeld

Was zählt nicht?

Fortlaufende Aktionen wie Scrollen oder Zoomen.

Ganz oben auf der Seobility Startseite (in der mobilen Ansicht) siehst Du zwei Elemente, die Nutzer mit großer Wahrscheinlichkeit zuerst anklicken:

1. Ein Hamburger-Menü-Icon (mobiles Menü)
2. Einen Button zur kostenlosen Registrierung

Beide befinden sich gut sichtbar „above the fold“. Und wenn wir bei der Conversion-Optimierung alles richtig gemacht haben, sollte der darauffolgende Button zur kostenlosen Registrierung eines der ersten Elemente sein, das Nutzer anklicken.

Sehen wir uns als Nächstes also die Performance unserer Startseite an. FID und die anderen Core Web Vitals können mit mehreren Tools geprüft werden. Wir verwenden für den Moment jedoch Googles PageSpeed Insights.

Hier können wir sehen, dass der First Input Delay für unsere Startseite in den letzten 28 Tagen im Durchschnitt bei 17ms lag.

Ist das nun gut oder schlecht? Googles Obergrenze für einen guten FID-Wert sind 100 Millisekunden:

“To provide a good user experience, pages should have a FID of less than 100 milliseconds.”

Das bedeutet, dass Seiten, die erst nach mehr als 100 Millisekunden auf eine Aktion reagieren, laut Google optimierungsbedürftig sind.

Unser Ergebnis ist also ziemlich gut. Es dauert weniger als eine Fünfzigstel Sekunde, bis unsere Website auf die erste Aktion eines Nutzers reagiert. Für menschliche Nutzer fühlt es sich damit an, als reagiere die Website unmittelbar.

Anmerkung: Du fragst Dich, warum Google einen Wert von 100 Millisekunden festgelegt hat? Dieser gilt schon lange als Grenzwert für Zeitspannen, die sich für Nutzer noch als unmittelbar anfühlen. Reaktionszeiten darunter können wir gar nicht wahrnehmen.

Welche Gründe gibt es für First Input Delay Probleme?

Ein Browser liest den Code eine Seite von oben nach unten. Trifft er auf ein externes Skript, insbesondere JavaScript, muss er:

1. Das Laden anderer Elemente vorübergehend pausieren
2. Nutzerinteraktionen vorübergehend deaktivieren, bis er die Datei heruntergeladen und verarbeitet hat

Der Grund dafür ist, dass ein externes Skript unter Umständen das Verhalten einzelner Elemente auf der Hauptseite verändern kann.

Du kannst Dir darunter nichts vorstellen? Hier ist ein Beispiel, das Dir mit Sicherheit bekannt vorkommt:

Viele Bildergalerien verwenden JavaScript, um eine Pop-up Lightbox zu öffnen, wenn ein Nutzer eines der Bilder anklickt.

Ein gängiges Beispiel für JavaScript: Wir klicken auf ein Bild und es öffnet sich ein Pop-up

Das funktioniert jedoch erst, nachdem die JavaScript-Datei, die die Lightbox bereitstellt, vom Browser heruntergeladen und verarbeitet wurde.

Klicken Nutzer vorher auf das Element, gelangen sie lediglich zur Bild-URL. JavaScript verändert also, wie sich der Link verhält, indem es den Nutzer nicht mehr auf eine neue Seite führt, sondern stattdessen eine Lightbox öffnet.

Stößt ein Browser auf eine externe JS Datei, denkt er daher: „Am besten prüfe ich erstmal, ob diese JavaScript Datei die Funktionalität der Seite ändert, ehe ich weitermache. Alles andere stoppen!“

Dieses Verhalten nennt sich „Render-Blocking“, denn die JavaScript Datei blockiert das Rendering.

Falls die FID-Werte Deiner Website nicht im grünen Bereich sind, ist dieser Vorgang mit großer Wahrscheinlichkeit der Grund dafür.

So vermeidest Du, dass JavaScript Deine Seite blockiert

Die gute Nachricht ist, dass Du das Render-Blocking durch JavaScript-Dateien auf Deiner Seite relativ leicht verhindern kannst.

Dafür musst Du nur eines der folgenden zwei Attribute in Deinen Script-Tags integrieren:

1. „Defer“
2. „async“

Welches davon Du verwenden solltest, hängt von der Art des Skripts ab.

Option 1: Ladevorgang einer JavaScript-Datei mit dem Defer-Attribut aufschieben

Ideal für: Skripte, die die Funktionalität Deiner Seite verändern, oder die in einer bestimmten Reihenfolge geladen werden müssen.

<script src=”yourscript.js” defer></script>

Das Defer-Attribut gibt dem Browser die Anweisung, nicht zu warten, bis das Skript geladen ist und die Seite währenddessen zu „blockieren“, sondern es einfach im Hintergrund zu laden, während der Rest der Seite gerendert wird.

Warum die Reihenfolge dabei wichtig ist? Weil Skripte mit dem Defer-Attribut in der Reihenfolge ausgeführt werden, in der sie im HTML-Code einer Seite erscheinen.

Verwendest Du zum Beispiel eine Custom jQuery Funktion, dann solltest Du sicherstellen, dass die jQuery Bibliothek vor Deinem Custom Skript geladen ist:

<script src=”jquery.js” defer></script><script src=”customquery.js” defer></script>

Ansonsten kann das Skript nicht ausgeführt werden!

Option 2: JavaScript asynchron laden

Ideal für: Externe Skripte, die die Funktionalität Deiner Seite nicht beeinflussen und demnach nicht in einer bestimmten Reihenfolge geladen werden müssen.

<script src=”externalscript.js” async></script>

Ähnlich wie mit dem Defer-Attribut werden die Skripte im Hintergrund geladen, während der Rest der Seite gerendert wird.

Unterschiedlich ist hier jedoch, dass Skripte mit dem Async-Attribut in keiner bestimmten Reihenfolge ausgeführt werden, sondern bereits, sobald das jeweilige Skript geladen ist.

Analytics und Werbe-Skripte sowie Tracking Pixel können in der Regel problemlos asynchron geladen werden, da sie weder auf andere Bibliotheken zugreifen müssen, noch die Funktionalität Deiner Seite im Allgemeinen beeinflussen.

Weitere Informationen zum Async- und Defer-Attribut findest Du hier.

So findest und korrigierst Du Skripte, die das Rendering blockieren

In Googles PageSpeed Insights erhältst Du einen ersten Überblick über alle Skripte, die im Moment Deine Seite blockieren.

Um dies zu veranschaulichen haben wir eine einfache Testseite erstellt, die drei Skripte aufruft, welche das Rendering blockieren (darunter ein lokales und zwei externe Skripte).

Prüfen wir die Seite nun in PageSpeed Insights, sehen wir, dass die Skripte das Laden der eigentlichen Seite 1,22 Sekunden lang verhindern.

PageSpeed Insights > Empfehlungen > Ressourcen beseitigen, die das Rendering blockieren

Beachte auch „Time to Interactive“ mit 2 Sekunden (mehr dazu in Kürze).

Nun fügen wir für das lokale Skript das Defer-Attribut und für die externen Skripte das Async-Attribut hinzu.

Hier ist die neue Seite.

So konnten wir Ressourcen entfernen, die das Rendering blockieren…

…und auch unsere „Time to Interactive“ ist mit 0,8 Sekunden jetzt besser.

Das war doch ganz einfach, oder?

An eine Sache solltest Du jedoch denken…

Vorsicht beim Verschieben von Skripten, die die UX beeinflussen

Bei den Core Web Vitals geht es hauptsächlich darum, die User Experience zu verbessern. Darum sollten wir keinerlei Änderungen vornehmen, die sich darauf negativ auswirken können.

Erinnerst Du Dich an unseren großen Button für die kostenlose Registrierung?

Nehmen wir Mal an, dass ein Klick darauf ein Pop-Up-Fenster öffnet, anstatt den Nutzer zur nächsten Seite zu bringen.

Zudem wissen wir bereits, dass Nutzer den Button oft als erste Aktion auf unserer Startseite anklicken.

Was passiert aber, wenn wir die Ausführung der JavaScript-Datei, die das Pop-Up aufruft, verschieben?

In diesem Fall klicken Nutzer den Button vielleicht schon ehe das Skript geladen ist, worauf hin gar nichts geschieht. Für Besucher der Website ist das eine frustrierende Erfahrung.

Gibt es dafür eine andere Lösung?

Wichtige JavaScripts haben beim Laden Priorität

Das Laden dieses Skripts sollte hier Vorrang haben, auch wenn es das Rendering für einige Millisekunden blockiert.

Warum wir uns so entscheiden? Weil das Skript hier grundlegend wichtig für den „above the fold“ Inhalt ist.

Im Idealfall implementieren wir das Pop-Up-Skript direkt im HTML-Code der Seite und sparen dem Browser so ein wenig Zeit, da er keine externe JavaScript-Datei herunterladen muss.

Ist das nicht möglich, dann sollten wir das Skript in eine separate Datei auslagern und sofort laden.

Zusammengefasst kann man also sagen: Ist ein Skript für die Funktionalität Deines „above the fold“ Contents unverzichtbar, dann solltest Du Dir das Aufschieben dieses Skripts sehr gut überlegen.

Für alle Skripte, die nicht essentiell sind, gilt hingegen: Mit „Defer“ und Async“ ist das Problem schnell behoben.

„Time to Interactive“ als Indiz für mögliche FID Probleme

First Input Delay zählt zu den Felddaten. Wie schon erwähnt bedeutet dies, dass die Statistik auf tatsächlichen Besuchen Deiner Website basiert.

Theoretisch kannst Du diesen Wert auch selbst messen (wie das geht, erfährst Du weiter unten in diesem Guide), allerdings hängt das Ergebnis dann von Deiner Computer-/Internet-Verbindung zum Messzeitpunkt ab.

Während Du also darauf wartest, dass Google neue Felddaten sammelt und anzeigt, kannst Du Dich in der Zwischenzeit mit den Labdaten beschäftigen.

Ehe wir in dieses Thema eintauchen jedoch eine Warnung: Time to Interactive ist eine etwas ungewöhnliche Kennzahl, die man mit einer gewissen Vorsicht betrachten sollte. In diesem Blogartikel von dareboost wird gut verständlich erklärt, was hinter der Statistik steckt und was mit „time to interactive“ genau gemeint ist.

Wir betrachten „Time to Interactive“ an dieser Stelle jedoch ganz simpel: Indem man Skripte entfernt, die das Rendering blockieren, sollte auch der Messwert für „Time to Interactive“ in den PageSpeed Insights sinken.

Reduzierst Du also das Render-blocking um eine Sekunde, dann sollte sich auch Deine „Time to Interactive“ um etwa denselben Wert verkürzen.

Oft (aber nicht immer) lässt sich eine Korrelation zwischen den folgenden Werten beobachten:

• “First Contentful Paint” (FCP): Der Moment, sobald ein Nutzer etwas auf Deiner Seite sieht
• Time to Interactive
• Die Dauer des Render-blockings

Wenn wir uns das PageSpeed Insights Ergebnis zur Seobility Startseite ansehen, können wir erkennen, dass „Time to Interactive“ in etwa der Summe von FCP + Render-Blocking Dauer entspricht.

Fazit:

Es kann nie schaden, „Time to Interactive“ zu optimieren, indem Du Ressourcen entfernst, die das Rendering blockieren. Wenn diese Zahl schrumpft, während Du an Deiner Website arbeitest, ist das schon mal ein gutes Zeichen – auch für den FID-Wert, der ebenfalls sinken sollte.

Denke aber daran, dass es sich bei First Input Delay und Time to Interactive nicht um denselben Messwert handelt.

Largest Contentful Paint (LCP)

Als Nächstes sehen wir uns den zweiten Messwert der Core Web Vitals an: Largest Contentful Paint.

Die gute Nachricht ist, dass diese Kennzahl einfacher zu verstehen ist. Largest Contentful Paint misst, wie lange es dauert, bis das größte Element über der Browserkante eines Nutzerbildschirms komplett gerendert ist.

Zu den Elementen, die unter LCP fallen können, gehören:

• Bilder
• Videos
• Container mit Hintergrundbildern
• Textelemente, wie Überschriften, Absätze etc.

Als LCP wird jeweils das Element betrachtet, das oberhalb der Browserkante den meisten Platz einnimmt.

In unserem SEO Audit Guide beispielsweise ist die Überschrift das LCP Element…

… während in unserem Meta Description Guide das Beitragsbild mehr Platz einnimmt, da die Überschrift kürzer ausfällt.

Keine Sorge, Du musst hier nicht selbst mit dem Lineal nachmessen.

Im Gegensatz zu FID erscheint Largest Contentful Paint sowohl in den Feld- wie in den Labdaten.

Gib einfach eine Seite in Googles PageSpeed Insights ein und Dir wird angezeigt, welches das Largest Contentful Paint-Element ist.

PageSpeed Insights > Diagnose > Largest Contentful Paint-Element

Die Messung der LCP-Dauer beginnt mit dem Zeitpunkt, an dem ein Nutzer Deine URL eingibt, und endet, sobald das LCP-Element komplett geladen ist.

Sehen wir uns das einmal für unseren Meta Description Blogartikel an.

Das sieht nicht gut aus! Mit einem Wert von 5,7 Sekunden für Largest Contentful Paint fällt diese Seite ganz klar in den roten Bereich.

Hier kannst Du sehen, wie Google Seiten einstuft:

1. Ein LCP-Wert unter 2,5 Sekunden gilt als gut
2. Ein LCP-Wert zwischen 2,5 und 4 Sekunden fällt unter verbesserungswürdig
3. Ein LCP-Wert über 4 Sekunden ist schlecht

Doch diese Auswertung allein ist noch kein Grund zur Sorge…

Vielleicht hast Du bereits bemerkt, dass es sich hier um Labdaten handelt? Wie schon erwähnt, wird LCP jedoch auch basierend auf realen Nutzerdaten angegeben.

Wie also sehen die LCP-Felddaten aus?

Dieser Wert ist um einiges besser. Dabei sollten wir jedoch darauf hinweisen, dass nur 3% des Seitentraffics über mobile Geräte kommt (wo die Daten erfasst werden), und es sich damit um eine eher kleine Testgruppe handelt.

Um auf der sicheren Seite zu sein, sollten wir den LCP-Wert daher optimieren.

So verbesserst Du den Largest Contentful Paint

Wir können wir also den LCP-Wert verbessern? Die Antwort darauf kannst Du vielleicht schon erraten: Ein wichtiger Schritt ist die Optimierung Deiner Seitenladegeschwindigkeit.

Einen ausführlichen Guide zur Verbesserung Deines Page Speeds gibt es schon bald hier auf unserem Blog. In der Zwischenzeit findest Du einige Tipps zu diesem Thema in unserem Page Speed Wiki Artikel und SEO Audit Guide.

An dieser Stelle möchten wir Dir stattdessen zeigen, wie Du langsame Seiten mit Seobility findest, und uns einige Faktoren ansehen, die Deinen LCP-Wert beeinflussen.

Langsame Seiten mit Seobility finden

Seobility misst für jede Seite Deiner Website die Server-Antwortzeit, welche ein wichtiger Teil der gesamten Ladedauer ist.

Dabei bewerten wir:

• eine Antwortzeit unter 0,5 Sekunden als gut,
• eine Antwortzeit zwischen 0,5 und 1 Sekunde als optimierungsbedürftig,
• und eine Antwortzeit über 1 Sekunde als langsam.

Natürlich gilt zudem: Je schneller, desto besser!

Um langsame Seiten auf Deiner Website ausfindig zu machen, benötigst Du einen Seobility Account. Du hast Dich noch nicht registriert? Dann empfehlen wir Dir, unseren Premium Account 30 Tage kostenlos zu testen. Damit kannst Du bis zu 25.000 Seiten crawlen.

Der nächste Schritt ist, ein neues Projekt anzulegen und das Crawling zu starten. Klicke dazu einfach auf den Button „Projekt anlegen“ im Dashboard. Gib anschließend die URL ein, mit der Du beginnen möchtest, lege einen Projektnamen fest und klicke auf „Projekt anlegen und Crawling beginnen“.

Seobility > Dashboard > Neues Projekt

Der Seobility Crawler macht sich nun auf Deiner Website an die Arbeit. Das Ergebnis zur Antwortzeit findest Du im „Technik & Meta“ Bereich unter „Onpage“, in der Analyse „Verteilung der Antwortzeiten“.

Seobility > Dashboard > Onpage > Technik & Meta > Verteilung der Antwortzeiten

Im obigen Beispiel sehen wir, dass 7 Seiten als langsam eingestuft werden, da sie eine Antwortzeit von mehr als 1 Sekunde aufweisen.

Mit einem Klick auf die Zahl gelangen wir zu einer Auflistung der langsamen Seiten, sowie:

1. ihrer Antwortzeit, und
2. dem Verhältnis ihrer Antwortzeit zum Durchschnitt der Website

In unserem Fall sind die gefundenen Seiten etwa 2,5-mal langsamer als der Durchschnitt aller Seiten der Website. Wir sollten sie uns darum genauer ansehen und die Ursache für das schlechte Ergebnis finden.

Zwei Tipps für die Optimierung des Largest Contentful Paint

Bei der Optimierung des Largest Contentful Paint haben wir den großen Vorteil, dass wir genau wissen, welches das LCP-Element ist. Somit können wir uns darauf konzentrieren, den Ladevorgang für dieses einzelne Element zu optimieren.

Genau genommen könnten wir das Largest Contentful Paint Element sogar austauschen. Ist das LCP-Element zum Beispiel das Beitragsbild, dann könnten wir die Größe der Überschrift anpassen. Sobald der Textblock mehr Platz einnimmt, wird er das neue LCP-Element.

Grundsätzlich gilt jedoch, dass wir neben solchen Tricks und “Hacks” hauptsächlich daran arbeiten sollten, dass alles, was sich „above the fold“ befindet, so schnell wie möglich geladen wird.

Hier sind zwei Tipps:

1. Binde „Critical Path“ CSS direkt im HTML-Dokument ein + lade nicht essenzielle CSS asynchron

Wie JavaScript blockiert auch CSS grundsätzlich das Rendering.

Verlinkst Du also regulär im Head-Element zu einer CSS-Datei, dann muss ein Browser die Stylesheets erst herunterladen und verarbeiten, ehe er Inhalte anzeigen kann.

<head>
<link rel="stylesheet" href="yourstylesheet.css">
</head>

Dieser Vorgang beeinflusst natürlich den FCP-Wert, doch zum Glück kannst Du dieses Problem einfach umgehen.

Dazu müssen wir den Ladevorgang folgendermaßen aufteilen:

1. Lade die Stylesheets, die für das Rendering des „above the fold“ Inhalts wichtig sind, als Inline CSS.
2. Lade die restlichen Stylesheets asynchron und vermeide damit, dass das Rendering blockiert wird.

Als Erstes müssen wir bestimmen, welche CSS-Regeln wir für den Inhalt oberhalb der Browserkante benötigen. Praktischerweise gibt es ein Tool, das uns diese Arbeit abnimmt.

1. Gehe auf https://www.sitelocity.com/critical-path-css-generator
2. Gib die URL ein, für die Du Critical Path CSS erstellen willst
3. Klicke auf „Generate Critical Path CSS“
4. Kopiere den CSS Inhalt des Kastens

Füge das Critical Path CSS dann im HTML Head-Element Deiner Seite ein. Nun werden alle CSS-Regeln sofort geladen, die benötigt werden, um den „above the fold“ Inhalt anzuzeigen.

Anschließend musst Du den Link zum CSS-Stylesheet durch folgenden Code ersetzen:

<link rel="preload" href="yourstylesheet.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

Damit wird nicht-essentielles CSS asynchron geladen. Außerdem enthält der <noscript>-Tag eine Alternative für Browser, die JavaScript nicht ausführen.

Beachte: Die meisten guten Caching Plugins übernehmen dies für Dich.

Falls Du zum Beispiel WP Rocket nutzt, musst Du lediglich „Optimize CSS delivery“ im Abschnitt „File Optimization“ auswählen…

…und damit hast Du die Arbeit erledigt.

Du willst mehr über die manuelle Lösung lesen? Hier findest Du einen web.dev Guide von Google.

2. Optimiere Deine Beitragsbilder

Auf Blogseiten ist das Beitragsbild in der Regel das LCP-Element, weswegen wir sicherstellen sollten, dass dieses so schnell wie möglich lädt.

Hier sind einige Ansatzpunkte für die Optimierung Deiner Bilder mit Links zu weiteren Informationen und Tools:

1. Verwende srcset, um alternative Bilder passend zur Viewport-Größe anzuzeigen (Anleitung)
2. Komprimiere Deine Bilder (imagify ist ideal für WordPress)
3. Möglicherweise kommt für Dich das WebP-Format in Betracht, das Du zum Beispiel mit Imagify erstellen kannst (hier erfährst Du, was es genau ist)
4. Nutze ein CDN, um Deine Bilder auszuliefern (web.dev Guide)

Cumulative Layout Shift (CLS)

Cumulative Layout Shift misst die Layoutstabilität einer Webseite. Jedes Mal, wenn sich ein Element auf einer Seite unbeabsichtigt (also nicht durch eine Aktion des Nutzers bedingt) bewegt, erhöht dies den CLS-Wert.

Layout Shifts können für Nutzer äußerst frustrierend sein.

Der folgende Mitschnitt zeigt die Startseite einer schottischen Zeitung während eines 5-sekündigen Ladevorgangs.

 

Dir ist sicher nicht entgangen, wie die Navigation nach oben und unten springt, während die Werbeanzeigen geladen werden.

Diese Einzelbilder des Ladevorgangs zeigen deutlich, wie sich das Layout immer wieder verändert, ehe wir eine stabile Version zu sehen bekommen.

Im letzten Bild nimmt eine Werbeanzeige die Position ein, an der zu Anfang die Navigation zu sehen war. Was also passiert, wenn Nutzer die Navigation anklicken, während sich das Layout noch verschiebt? Genau, mit großer Wahrscheinlichkeit klicken sie stattdessen auf die Anzeige und gelangen zu einer anderen Seite!

Dieses Beispiel macht deutlich, wie ärgerlich Layout Shifts für Nutzer sind. Aus diesem Grund will Google, dass Du sie weitestgehend vermeidest.

Die genaue Berechnung des CLS-Werts einer Seite ist kompliziert und für Dich nicht unbedingt relevant, weswegen wir das Thema an dieser Stelle nicht näher behandeln. Falls Du trotzdem mehr darüber wissen möchtest, findest Du hier alle Details.

Uns reicht im Moment zu wissen, dass wir einen CLS-Wert unter 0,1 erzielen wollen.

Wo siehst Du den CLS-Wert Deiner Seite?

Cumulative Layout Shift kann sowohl in der Theorie wie auch basierend auf echten Nutzerdaten gemessen werden und erscheint daher in den Lab- und Felddaten, wenn Du eine Seite in den PageSpeed Insights prüfst.

Welche Ursachen haben Layout Shifts? (Und wie korrigiert man sie?)

Für Layout Shifts gibt es unterschiedliche Gründe. Auf die wichtigsten davon gehen wir weiter unten ein.

Die gute Nachricht ist, dass Dir Google genau anzeigt, welche Seitenelemente zum CLS-Wert beitragen.

Wenn Du Deine Seite in den PageSpeed Insights prüfst, findest Du dort unter Diagnose einen Abschnitt namens „Umfangreiche Layoutverschiebungen vermeiden“.

Für die Seobility Startseite listet Google drei Elemente mit Optimierungsbedarf auf:

Die <h1> und <h2> Tags tragen hier zum CLS-Wert bei, was zum Glück ganz einfach behoben werden kann.

1. Stelle sicher, dass Texte während des Webfont-Ladevorgangs sichtbar bleiben

Zahlreiche Websites einschließlich unserer verwenden individuelle Schriften. Google bietet zum Beispiel eine große Auswahl an Schriften, mit denen Websites nicht nur ansprechender gestaltet werden können, sondern auch die Lesbarkeit verbessert werden kann.

Das Problem dabei: Diese speziellen Schriften müssen erst heruntergeladen werden, ehe ein Browser sie anzeigen kann.

Bis dieser Vorgang abgeschlossen ist:

1. sehen Nutzer keinen Text
2. weiß der Browser nicht, wie viel Platz die Textelemente einnehmen werden, was beim Laden zu Layout Shifts führen kann.

Mit der CSS-Funktion font-display können wir diese Probleme minimieren, indem wir einfach eine Systemschrift verwenden, bis die individuelle Schrift der Seite geladen ist.

Falls Du diese Lösung noch nicht verwendest, wird sie Dir unter „Diagnose“ in den PageSpeed Insights angezeigt.

Du verwendest eine der Google Fonts? Dann ist die Lösung ganz einfach. Setze einfach den Zusatz „&display=swap“ ans Ende der Google Font Stylesheet URL.

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans:ital,wgh[email protected],400;0,700;1,400;1,700&display=swap" rel="stylesheet">

Inzwischen fügt Google diesen Zusatz sogar automatisch hinzu, wenn Du den Code zum Einbetten einer Schrift aus der Google Bibliothek kopierst.

In unserem Fall konnten wir den CLS-Wert durch den Zusatz von „display=swap“ von 0,026 auf 0,004 reduzieren.

Damit haben wir kaum noch Layoutverschiebungen im Header-Element. War doch gar nicht schwer, oder?

2. Lass Platz für Werbeanzeigen im Layout

Individuelle Schriftarten sorgen in der Regel immer für kleine Layoutverschiebungen, die Nutzern jedoch meistens nicht weiter auffallen. Anders sieht es hingegen mit Werbeanzeigen aus, die das Layout Deiner Seite ziemlich durcheinander bringen können, wie das Beispiel der News-Website zu Beginn dieses Abschnitts zeigt.

Diesem Problem kannst Du vorbeugen:

1. falls Du weißt, welche Größe die Anzeigen haben, die Dein Werbenetzwerk ausspielt, und
2. Du sie manuell bestimmten Bereichen zuweist.

Mit den automatischen Anzeigen von Googles AdSense klappt dies leider nicht, da die Automatisierung speziell dazu da ist, Anzeigen an unterschiedlichen Stellen zu testen und den Umsatz so zu maximieren. Das bedeutet, dass Du nie genau weißt, wo die Anzeigen erscheinen, wenn Nutzer Deine Seite aufrufen.*

Lass uns trotzdem für den Moment davon ausgehen, dass Du die Größe und Position der Anzeigen kennst.

In diesem Fall kannst Du Layoutverschiebungen vorbeugen, indem Du einfach eine minimale Höhe und Breite für Deinen Ad Container festlegst. Die Werte hängen dabei von den Größen der Anzeigen ab, die Du ausspielst.

<div id="ad-slot1" style="min-width: 300px; min-height: 250px;"></div>

Mit Media Queries kannst Du anschließend die minimale Höhe und Breite passend zur Bildschirmgröße der Nutzer anpassen.

@media screen and (max-width: 960px) {
#ad-slot1 {
min-height: 100px;
}
}

Eine ausführliche Anleitung findest Du hier.

*Du kennst eine Lösung für das Problem mit den automatisierten Werbeanzeigen? Wir würden uns freuen, wenn Du sie in den Kommentaren mit uns teilst!

3. Stelle sicher, dass alle Bilder ein “width” und “height” Attribut haben

Die meisten Websites haben ein responsives Layout, in dem Bilder automatisch für die Bildschirmgröße eines jeden Nutzers angepasst werden. Mit dem srcset-Attribut können Browser Bilder in unterschiedlichen Größen, zum Beispiel in einer kleinen, mittleren und großen Version passend zum Bildschirm anzeigen.

Trotzdem ist es wichtig, die “width” (Breite) und “height” (Höhe) eines Bildes im Tag festzulegen.

Warum diese Information nicht fehlen darf? Weil der Browser ohne die Attribute den Platz, den er für das Bild reservieren muss, erst berechnen kann, sobald das Bild komplett geladen ist. Und das führt wiederum zu Layoutverschiebungen.

Darum solltest Du immer Größenattribute für Deine Bilder festlegen, besonders für Elemente above the fold wie zum Beispiel das Logo Deiner Website.

Wie (und wo) Du die Core Web Vitals Deiner Website prüfen kannst

In diesem Guide haben wir uns bisher auf Googles PageSpeed Insights konzentriert, weil es das Tool

1. schon lange gibt, und
2. sich die meisten Webmaster/SEOs damit auskennen.

Doch es gibt noch viele andere Tools, mit denen Du die Core Web Vitals Deiner Website oder einzelner Seiten prüfen kannst:

Sehen wir uns die verschiedenen Tools einmal kurz an.

1. Google Search Console

Google berichtet über Probleme mit den Core Web Vitals Deiner Website inzwischen in der Google Search Console (GSC).

Du findest den Bericht links unter „Core Web Vitals“ im Abschnitt „Verbesserungen“.

Sehen wir uns das einmal im Detail an.

Wie Du siehst, führt Google hier ebenfalls die drei Kategorien “gut”, “schlecht” und “verbesserungswürdig” auf.

Wenn Du auf „Bericht öffnen“ (Open Report) klickst, siehst Du alle Probleme.

Beispiel: “LCP issue: longer than 4s (mobile)” – Deutsch: “Problem mit LCP: länger als 4s (Mobilgerät)”

Klicke auf eines der Probleme und Du siehst Beispielseiten, die davon betroffen sind.

Google gruppiert hier Seiten mit ähnlichen Problemen und zeigt Dir die Gesamtzahl unter “Ähnliche URLs” an. Für weitere Details müssen wir also auf eine der Beispielseiten klicken.

Die weiteren URLs siehst Du rechts in der Seitenleiste.

2. Web Vitals Chrome Erweiterung

Wie vorher schon erwähnt, kannst Du den First Input Delay auch manuell prüfen. Bedenke dabei, dass dieser Test jedoch von Deinem eigenen Computer und Netzwerk (sowie Deiner ganz persönlichen Reaktionszeit) abhängt, und damit nicht so verlässlich ist wie die gesammelten Felddaten.

Wenn Du den Test dennoch durchführen willst, gehst Du dabei folgendermaßen vor.

Als Erstes musst die Web Vitals Chrome Erweiterung installieren.

Sobald die Installation abgeschlossen ist, kannst Du mit einem Klick auf die Erweiterung die Core Web Vitals für jede beliebige Seite sehen.

Während Du das Ganze ausprobierst, solltest Du für „Display HUD overlay“ in den Einstellungen ein Häkchen setzen. Damit werden Dir für jede Seite automatisch CWV-Werte angezeigt, ohne dass Du erst auf die Erweiterung klicken musst.

Hier siehst Du, was die Erweiterung für die Google Startseite anzeigt.

Nicht schlecht Google! Die Suchmaschine hat natürlich ein ideales Ergebnis.

3. Google Lighthouse (Chrome Dev Tools)

Mit Google Lighthouse in den Chrome Dev Tools kannst Du Labdaten für Largest Contentful Paint und Cumulative Layout Shift sehen.

Klicke F12 auf Deiner Tastatur während Du Googles Chrome Browser verwendest und wähle den Lighthouse Tab aus, um zu den Chrome Dev Tools zu gelangen.

Im Moment stellt Lighthouse keine Daten zu First Input Delay zur Verfügung.

4. Google PageSpeed Insights

Nochmal zur Erinnerung – mit Googles PageSpeed Insights erhältst Du:

1. Labdaten zu LCP und CLS, aber nicht FID
2. Felddaten zu allen drei Core Web Vitals (falls ausreichend Daten zur Verfügung stehen)

Damit hast Du einen umfassenden Bericht, weswegen wir PageSpeed Insights für die Beispiele in diesem Guide verwenden.

5. Chrome User Experience Report

Technisch Begabte können CWV-Daten auch direkt in der Chrome User Experience Report API einsehen.

In diesem Guide erfährst Du, wie Du dabei vorgehst.

Jetzt bist Du ideal auf den neuen Rankingfaktor Core Web Vitals vorbereitet

Damit bist Du am Ende unseres Core Web Vitals Guides angelangt.

Auch wenn die Werte Deine Rankings im Moment noch nicht direkt beeinflussen, dauert es nicht mehr lang bis sie im Juni 2021 zu einem direkten Rankingfaktor werden!

Google hat die Bedeutung der Kennzahlen bisher vehement vorangetrieben, daher werden Websites mit schlechter CWV Performance wahrscheinlich einen Abfall an Suchmaschinentraffic verzeichnen.

Im Umkehrschluss bedeutet das für Seiten mit guten CWV-Werten voraussichtlich einen spürbaren Boost.

Im Gegensatz zu anderen Google Updates gab es hier eine lange Vorlaufzeit. Trotzdem wissen wir, dass dieses Thema ziemlich komplex ist. Hinterlasse uns darum gerne einen Kommentar mit Deinen Fragen zu den Core Web Vitals und wir beantworten sie so schnell wie möglich.

Viel Erfolg beim Optimieren Deiner Core Web Vitals!

PS: Erhalte neue Blog Artikel direkt in Dein Postfach!