Der ultimative Leitfaden zu Core Web Vitals

Core Web Vitals sind derzeit ein heißes Thema in der SEO-Community. Das hat gute Gründe: Ihre Verbesserung führt zu einer besseren Nutzererfahrung, und außerdem sind sie ein Rankingfaktor für die Google-Suche und wirken sich speziell auf das „Page Experience“-Rankingsignal aus.

Um die Core-Web-Vitals-Bewertung zu bestehen, müssen Sie bei allen drei Core Web Vitals – Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) – basierend auf Felddaten mit „gut“ bewertet werden.

In diesem Artikel sprechen wir häufig von Felddaten und Labordaten. Da diese oft missverstanden werden, müssen wir den Unterschied gleich zu Anfang erklären:

1. Felddaten werden von echten Nutzern über den Chrome User Experience Report (kurz „CrUX“) erfasst.
2. Labordaten werden in einer kontrollierten Umgebung ohne Beteiligung echter Nutzer erfasst.

Nachdem das geklärt ist: Wo passen Core Web Vitals in Googles Ranking-Algorithmen?

Google hat die Nutzererfahrung früher danach bewertet, ob eine WebsiteWebsite
Eine Website ist eine Sammlung an HTML-Dokumenten, die als einzelne Webseiten über jeweils eine URL mit einem Client wie einem Browser im Web abgerufen werden kann.
Mehr erfahren:

1. mobilfreundlich ist
2. HTTPS anbietet
3. frei von aufdringlichen Interstitials ist

Zu diesen drei Faktoren haben sie nun einen vierten hinzugefügt – Core Web Vitals – und zusammen bilden diese eine Gruppe von Signalen, mit denen Google die „Page Experience “ bewertet, wie diese anschauliche Abbildung zeigt:

Wichtig zu wissen: Core Web Vitals – sowohl Felddaten- als auch Labordaten-Metriken – sind ein bewegliches Ziel: Sie sind ein Stellvertreter zur Messung der Nutzererfahrung, und da sich das Web und seine Nutzer ständig weiterentwickeln, ist es nur natürlich, dass sich auch Core Web Vitals weiterentwickeln.

Warum dieser Leitfaden zu Core Web Vitals?

Weil es viele Falschinformationen zu Core Web Vitals gibt – und die korrekten Informationen über viele verschiedene Stellen verteilt sind. Selbst Google schafft es nicht, alles an einem Ort zu bündeln. Mit diesem Leitfaden möchten wir eine dauerhafte Ressource mit korrekten Informationen zu Core Web Vitals bieten – und zeigen, wo Sie tiefer eintauchen können.

Was sind Core Web Vitals?

Wir können Sie schon das berühmte Top-Gun-Zitat „I feel the need… the need for speed!“ denken hören, aber bei den Core-Web-Vitals-Metriken geht es um mehr als nur Geschwindigkeit.

Core Web Vitals sind eine Reihe nutzerorientierter Metriken rund um Geschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität, die Website-Betreibern helfen, die Nutzererfahrung im Web zu messen.

Die Web-Vitals-Metriken werden in Core Web Vitals und Nicht-Core-Web-Vitals unterteilt.

Die Core Web Vitals sind:

• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)

Und die Nicht-Core-Web-Vitals sind:

• Total Blocking Time (TBT)
• First Contentful Paint (FCP)
• Speed Index (SI)
• Time to Interactive (TTI)

Jede Metrik misst, wie „gut“ ein Teil der Page Experience ist. Die folgende Abbildung zeigt, wie eine Seite lädt und wo die verschiedenen Metriken ins Spiel kommen:

Doch bevor wir alle Web Vitals durchgehen, müssen wir zunächst erklären, warum sie wichtig sind. Wir möchten, dass Sie mit den richtigen Argumenten ausgestattet sind, um beim Management oder Kunden ein wasserdichtes Plädoyer für die Verbesserung der Core Web Vitals einer Website zu halten.

Warum sollten Sie sich um Core Web Vitals kümmern?

Hier sind die drei Hauptgründe, warum Sie (und alle anderen) sich um Core Web Vitals kümmern sollten:

1. Besucher lieben schnelle Websites , die auf jedem Gerät und von jedem Standort aus einfach und angenehm zu nutzen sind. Fazit: Sie verdienen mehr Geld, wenn Sie eine großartige Nutzererfahrung bieten.
2. Wie in der Einleitung erwähnt, sind Core Web Vitals seit Mitte Juni 2021 ein Rankingfaktor. Auch wenn wir nicht sofort eine große Verschiebung erwarten und Relevanz weiterhin deutlich wichtiger bleibt , gehen wir davon aus, dass ihre Bedeutung mit der Zeit zunehmen wird.
3. Wenn Sie die Core-Web-Vitals-Bewertung bestehen, kehren wahrscheinlich weniger Nutzer zu den SERPs zurück, weil Sie eine gute Nutzererfahrung bieten – und Google hat angedeutet, dass es in den Suchergebnissen möglicherweise ein „Good Page Experience“-Badge einführen könnte. Wir nennen das „indirekte Rankingfaktoren“, weil sie das Verhalten der Suchenden beeinflussen (z. B. mehr Klicks für Seiten mit diesem Badge), was wiederum in Googles Algorithmen einfließt. Im Februar 2021 stieß JR Oakes beim Durchsuchen des Frontend-Codes der Google Search Console auf Hinweise, dass Google in diesem Bereich möglicherweise bereits Vorbereitungen getroffen hat:

Google versucht schon lange, Pagespeed über Pagespeed Insights und AMP zu forcieren. Und jetzt, mit Core Web Vitals, ist es wirklich untrennbar mit SEO verbunden geworden. Pagespeed-Optimierung ist wie jeder andere Teil von SEO — eine einzelne Verbesserung allein bringt möglicherweise keine Ergebnisse, aber nachdem man mehrere Verbesserungen vorgenommen hat, sieht man einen Schub in der SEO-Performance.

Für mich sind es die Grenzfälle, die die Pagespeed-Nische interessant machen. Zum Beispiel habe ich bemerkt, dass Webshops mit Millionenumsätzen, die ihr A/B-Testing-Skript nach dem Stylesheet einbinden, ihre First Contentful Paint verdoppelt haben. Nur wegen der Art, wie Browser funktionieren. Und die Vergrößerung Ihres Hero-Bilds verbessert tatsächlich Ihre Largest Contentful Paint, möglicherweise um 50 % basierend auf Labordaten.

Core Web Vitals im Detail

Ohne weitere Umschweife tauchen wir in jede der Web-Vitals-Metriken ein, beginnend mit den Core Web Vitals!

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) ist ein Core Web Vital, das die Zeit in Sekunden misst, vom Beginn des Seitenladens bis zur Darstellung des größten Text- oder Bildelements auf dem Bildschirm.

Ziel ist es, zu messen, wann der Hauptinhalt der Seite vollständig geladen ist. Je niedriger der LCP, desto besser. Ein schneller LCP vermittelt Nutzern das Gefühl, dass eine Seite nützlich ist, da diese Metrik die wahrgenommene Ladegeschwindigkeit misst. LCP ist sowohl in Felddaten als auch in Labordaten verfügbar.

Im Feld hört der Browser auf, neue LCP-Kandidaten zu melden, sobald der Nutzer mit der Seite interagiert (durch Tippen, Scrollen, einen Tastendruck, Tab-Wechsel oder Schließen des Tabs). Im Labor ist nicht ganz klar, wann der LCP abgeschlossen ist. Wir gehen davon aus, dass dieser Moment eintritt, wenn sich die Seite der Time to Interactive (TTI) nähert und klar ist, welches Element der endgültige LCP-Kandidat ist.

Wichtige Überlegungen

Während eine Seite lädt, kann sich das größte Text- oder Bildelement ändern, und bei der Messung des LCP wird der zuletzt erkannte Kandidat verwendet.

Stellen Sie sich zum Beispiel vor, dass zunächst eine H1-Überschrift das größte Textelement ist, später aber ein größeres Bild geladen wird. Das größere Bild ist dann der führende Kandidat bei der Messung des LCP.

Bitte beachten Sie, dass <svg>-Elemente derzeit nicht als Kandidaten für den Largest Contentful Paint berücksichtigt werden. Wenn Sie also ein großes Logo als <svg>-Element laden, wird es nicht als LCP-Kandidat gewertet. Dies wurde entschieden, um die Sache einfach zu halten, und kann sich in Zukunft ändern.

Es ist unklar, ob <video>-Elemente derzeit als LCP-Kandidaten betrachtet werden; wir haben Google um Klärung gebeten.

„Was sollte mein LCP-Element sein?“ sollte immer die erste Frage sein, die Sie sich bei der Optimierung Ihres LCP stellen.

Bei der Arbeit an der LCP-Optimierung stelle ich fest, dass das LCP-Element in den meisten Fällen nicht der wichtigste Inhalt der Seite ist. Stattdessen ist es das Cookie-Consent-Banner oder ein Werbebanner/-modal. Spiegeln diese Elemente den nützlichen Inhalt wider? Nein!

Der erste Schritt ist also, für jeden Seitentyp die geeignetsten LCP-Kandidaten aufzuschreiben. Für einen Blogbeitrag könnten das zum Beispiel die H1, das Titelbild und der erste Absatz des Artikels sein. Für eine Produktdetailseite könnten das das Produktbild, der Name und der Preis sein. Sie können eine Tabelle ausfüllen, in der die LCP-Kandidaten für alle Seitentypen aufgeführt sind, und diese mit dem Team besprechen.

Der zweite Schritt besteht dann darin, die Elemente unserer LCP-Kandidaten zu priorisieren. Das Ziel ist es, sie so schnell wie möglich anzuzeigen.

So interpretieren Sie Ihren LCP-Score

So interpretieren Sie Ihren LCP-Score:

• Gut: <= 2,5 s (2,5 Sekunden oder weniger)
• Muss verbessert werden: > 2,5 s <= 4 s (zwischen 2,5 und 4 Sekunden)
• Schlecht: > 4 s (mehr als 4 Sekunden)

Was könnte einen schlechten LCP-Score verursachen

Es kann unzählige Ursachen für einen schlechten LCP-Score geben, zum Beispiel langsame Serverantwortzeiten, rendering-blockierendes JavaScript und CSS sowie zu schwere größte Content-Ressourcen, die zu viel Zeit zum Laden benötigen.

Die Verbesserung der Largest-Contentful-Paint-Metrik gehört zu den schwierigeren Core Web Vitals bei der Fehlerbehebung, da es eine so große Bandbreite an Faktoren gibt, die sie beeinflussen können.

Die Untersuchung der anfänglichen Serverantwortzeiten ist eine gute Möglichkeit zu beurteilen, ob zugrunde liegende Infrastrukturprobleme vorliegen, die sich auf die TTFB und damit auf die LCP-Scores auswirken können.

Um Ihre anfängliche Baseline zu ermitteln, suchen Sie (oder erstellen Sie) eine leere/statische HTML-Seite, bei der typischerweise keine serverseitige Verarbeitung stattfinden muss, bevor die Seite angezeigt werden kann, und verwenden Sie diese URL, um sie mit Ihrem bevorzugten Messtool zu testen.

Wenn diese statische Seite immer noch eine hohe anfängliche Serverantwortzeit aufweist, bedeutet dies, dass Sie sich möglicherweise die Infrastruktur der Website ansehen müssen – ein Upgrade Ihrer Hosting-Plattform und die Nutzung eines CDN, um die Scores site-weit zu verbessern – oder es könnte an einer Firewall- oder DNS-Einstellung liegen.

Dieser Prozess liefert Ihnen außerdem einen Benchmark-Wert, der die niedrigste Zahl darstellt, die Sie erwarten können, wenn keine Serververbesserungen möglich sind.

Ihren LCP-Score verbessern

Es gibt viele Möglichkeiten, Ihren LCP-Score zu verbessern – zum Beispiel die Optimierung Ihres kritischen Rendering-Pfads, CSS und Ihrer Bilder. Alle davon zu beschreiben würde den Rahmen dieses Artikels bei weitem sprengen. Wir empfehlen daher, sich stattdessen die Ressourcen von web.dev zur Optimierung von LCP-Scores anzusehen.

Eine hohe TTFB kann LCP-Probleme erheblich verstärken, allerdings gibt es einen Punkt, auf den Sie achten sollten, wenn Sie TTFB-Probleme an Entwickler melden:

Der von PageSpeed Insights und GTmetrix verwendete Lighthouse-Audit (mit den Standard-Mobileinstellungen) fügt jeder Interaktion mit dem Server künstliche Latenz hinzu. Das bedeutet, dass etwas mit mehreren Handshakes wie die TTFB durch das Rate-Limiting drastisch schlechter aussehen kann.

Um die TTFB ohne ein Drittanbieter-Tool zu testen, können Sie das Kommandozeilen-Tool cURL mit dem Argument --write-out/-w verwenden, z. B.: curl -w "%{time_starttransfer}\n" https://www.example.com -o /dev/null

Interaction to Next Paint (INP)

Interaction to Next Paint (INP), früher FID (First Input Delay), ist ein Core Web Vital, das die Zeit in Millisekunden misst, von der ersten Interaktion eines Nutzers mit Ihrer Website (z. B. Klick auf einen Link, Tippen auf einen Button oder Drücken einer Taste) bis der Browser in der Lage ist, auf diese Interaktion zu reagieren

INP liegt dem ersten Eindruck eines Nutzers von der Interaktivität und Reaktionsfähigkeit Ihrer Website zugrunde. Sorgen Sie besser für einen guten Eindruck.

Wichtig zu wissen: Felddaten sind Ihre beste Option, um Ihren INP zu verstehen und zu optimieren, da sie zeigen, was auf der Seite aus Nutzerperspektive tatsächlich passiert.

Wenn Ihnen keine Felddaten zur Verfügung stehen, müssen Sie die Ärmel hochkrempeln und Labortests durchführen. Bedenken Sie jedoch, dass Labortests tückisch sein können, da sie das reale Nutzerverhalten nicht perfekt widerspiegeln können. Der beste Ansatz zur Nutzung von Labordaten wäre, Interaktionen während des Seitenladens zu testen, wenn am meisten los ist, und den üblichen Nutzerpfaden auf Ihrer Website zu folgen. Eine Alternative wäre, sich auf das Nicht-Core-Web-Vital Total Blocking Time (TBT) zu verlassen, aber wie Sie später sehen werden, liefern TBT und INP zwar ähnliche Erkenntnisse, sind aber nicht austauschbar.

Wichtige Überlegungen

INP misst die vollständige Interaktions-Journey – alles vom Moment, in dem ein Nutzer handelt, bis Ihre Website die Antwort vollständig dargestellt hat.

Aber nicht alle Nutzeraktionen werden bei INP berücksichtigt. Zum Beispiel zählen Interaktionen wie Scrollen und Zoomen nicht als Aktionen, da sie kontinuierlicher Natur sind und ganz andere Performance-Einschränkungen haben, weil die Scroll-Aktion von der GPU statt der CPU ausgeführt wird, oder vom Compositor-Thread der CPU statt vom Main-Thread.

So interpretieren Sie Ihren INP-Score

So interpretieren Sie Ihren INP-Score:

• Gut: <= 200 ms
• Muss verbessert werden: > 200 ms und <= 500 ms
• Schlecht: > 500 ms

Was sind die Unterschiede zwischen INP und First Input Delay (FID)?

Wie der Name schon vermuten lässt, betraf First Input Delay die erste Interaktion Ihrer Website mit Nutzern. INP hingegen ist eher wie eine langfristige Beziehung: Es verfolgt, wie Ihre Website auf jeden Klick, jedes Tippen und jeden Tastendruck während des gesamten Besuchs eines Nutzers reagiert. Während FID nur die unangenehme Pause maß, bevor Ihre Website auf die erste Interaktion reagierte, verfolgt INP die gesamte Journey – vom Moment, in dem ein Nutzer handelt, bis Ihre Website zeigt, dass sie bereit für mehr ist. Es ist eine bessere Möglichkeit zu erkennen, ob Ihre Website durchgängig reaktionsschnell ist, statt nur einen guten ersten Eindruck zu hinterlassen.

Was könnte einen schlechten INP-Score verursachen

Ein häufiger Grund für einen schlechten INP-Score ist, dass der Main-Thread eines Browsers damit beschäftigt ist, JavaScript-Code zu parsen und auszuführen. Wenn der Main-Thread ausgelastet ist, kann er noch nicht auf die Interaktion eines Nutzers reagieren. Das ist aber nicht die ganze Geschichte. Weitere Faktoren wie die Größe des Document Object Model (DOM), komplexe Stilberechnungen und Layout-Änderungen können die Fähigkeit Ihrer Website, zu reagieren und Updates darzustellen, ebenfalls verlangsamen.

Ihren INP-Score verbessern

Wenn Sie Ihren INP-Score verbessern möchten, müssen Sie genau untersuchen, was den Browser davon abhält, interaktiv zu werden. Beispiele für Maßnahmen zur Verbesserung Ihres INP-Scores sind:

• Reduzierung der JavaScript-Ausführungszeit.
• Minimierung der im Main-Thread ausgeführten Arbeit.
• Reduzierung des Einflusses von Drittanbieter-Code.
• Optimierung Ihrer DOM-Operationen und Stiländerungen.

Die genauen Details zur Verbesserung Ihres INP-Scores würden den Rahmen dieses Artikels sprengen. Wir empfehlen daher, sich die Ressourcen von web.dev zur Optimierung von INP-Scores anzusehen.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) ist ein Core Web Vital, das den größten Ausbruch von Layout-Shift-Scores für jede unerwartete Layoutverschiebung misst, die während des gesamten Lebenszyklus einer Seite auftritt.

Ziel ist es, die „visuelle Stabilität“ einer Seite zu messen, da diese die Nutzererfahrung stark beeinflusst. CLS ist sowohl in Felddaten als auch in Labordaten verfügbar. Je niedriger der CLS-Score, desto besser die visuelle Stabilität.

CLS wird nicht wie die meisten anderen Metriken in Sekunden gemessen. Es basiert auf der Viewport-Größe, bezieht sich auf Elemente, die sich zwischen zwei Frames bewegen – sogenannte instabile Elemente – und misst deren Bewegung im Viewport. Der Layout-Shift-Score ist ein Produkt aus zwei Komponenten: dem „Impact Fraction“ und dem „Distance Fraction“.

Der „Impact Fraction“ ist der Bereich des Viewports, den das instabile Element in beiden Frames einnimmt:

Der „Distance Fraction“ ist die größte Distanz, die sich das instabile Element zwischen beiden Frames bewegt, geteilt durch die größte Dimension des Viewports (Breite oder Höhe):

Weitere Beispiele, um noch besser zu verstehen, wie CLS berechnet wird, finden Sie hier .

Wichtige Überlegungen

„Der gesamte Lebenszyklus einer Seite“ bedeutet, dass die CLS die ganze Zeit gemessen wird, wenn die Seite tagelang oder sogar wochenlang geöffnet bleibt. Hier zeigen sich natürlich Unterschiede zwischen CLS-Felddaten und Labordaten, da Tools Labordaten nur über einen sehr kurzen Zeitraum erfassen.

Das korrekte Testen auf unerwartete Layoutverschiebungen in Testumgebungen kann sich als schwierig erweisen, da manche Funktionen dort deaktiviert sein oder anders funktionieren können. Einige Beispiele: Cookie-Hinweise werden möglicherweise nicht angezeigt, Live-Chat-Support kann deaktiviert sein, und personalisierter Content wird nicht geladen.

So interpretieren Sie Ihren CLS-Score

So interpretieren Sie Ihren CLS-Score:

• Gut: <= 0,1
• Muss verbessert werden: > 0,1 <= 0,25
• Schlecht: > 0,25

Was könnte einen schlechten CLS-Score verursachen

Unerwartete Layoutverschiebungen entstehen oft durch Bilder oder Anzeigen ohne definierte Abmessungen, asynchron geladene Ressourcen und Situationen, in denen neue DOM-Elemente dynamisch oberhalb von bereits geladenem Content zu einer Seite hinzugefügt werden. Dies führt dazu, dass bereits geladener Content verschoben wird.

Wenn wir die CLS für die Website eines Kunden auditieren, untersuchen wir immer die Performance-Aufzeichnung in den Chrome DevTools, um Layoutverschiebungen auf einer Seite zu erkennen. Im Tab „Performance“ stellen wir sicher, dass „Screenshots“ und „Web Vitals“ aktiviert sind, und starten das Profiling über den Preload-Button.

Danach zeigt der Bereich „Experience“ (nur sichtbar, wenn Layoutverschiebungen vorliegen) die genauen Vorkommnisse von Layoutverschiebungen in Form roter Blöcke. Wenn Sie diese Layout-Shift-Blöcke auswählen, erhalten Sie hilfreiche Informationen (im Tab „Summary“), einschließlich des betroffenen Knotens und seines Cumulative Score. Die am oberen Rand des Performance-Profils angezeigten Screenshots bieten zudem eine nützliche Visualisierung der von der Verschiebung betroffenen Elemente.

Ihren CLS-Score verbessern

Sie können unerwartete Layoutverschiebungen verhindern, indem Sie z. B. immer Größenattribute für Ihre Bilder und Videos angeben und keinen Content oberhalb von bereits geladenem Content einfügen. Wir empfehlen, sich den Artikel von web.dev zur Optimierung von CLS-Scores anzusehen, um die gesamte Bandbreite möglicher Verbesserungen zu erfahren.

Total Blocking Time (TBT)

Total Blocking Time (TBT) ist ein Nicht-Core-Web-Vital, das die Gesamtzeit in Millisekunden zwischen First Contentful Paint (FCP) und Time to Interactive (TTI) misst, in der der Main-Thread lange genug blockiert ist, um nicht auf Nutzereingaben zu reagieren.

TBT korreliert stark mit Interaction to Next Paint (INP) und gilt daher als beste Alternative beim Testen in einer Laborumgebung, in der echte Nutzerinteraktion nicht möglich ist. Obwohl TBT im Feld erfasst werden kann, wird sie leicht von Nutzerinteraktionen beeinflusst und ist daher keine verlässliche Metrik, um zu messen, wie lange es dauert, bis eine Seite auf Nutzereingaben reagiert. Deshalb wird TBT nur in Labordaten verwendet.

Jede Aufgabe, deren Ausführung mehr als 50 ms dauert, wird als „Long Task“ betrachtet, und die Zeit oberhalb der 50 ms gilt als „Blocking Time“. TBT wird berechnet, indem die Summe der blockierenden Anteile aller Long Tasks gebildet wird. Angenommen, es gibt drei Long Tasks:

1. Task A dauert 75 ms (25 ms länger als 50 ms)
2. Task B dauert 60 ms (10 ms länger als 50 ms)
3. Task C dauert 85 ms (35 ms länger als 50 ms)

Die TBT beträgt dann: 70 ms (25+10+35). Je niedriger die TBT, desto besser.

So interpretieren Sie Ihren TBT-Score

So interpretieren Sie Ihren TBT-Score:

• Gut: <= 200 ms
• Muss verbessert werden: > 200 ms <= 600 ms
• Schlecht: > 600 ms

Ursachen für einen schlechten TBT-Score und wie Sie ihn verbessern

Der Abschnitt Ihren INP-Score verbessern oben und So verbessern Sie Ihren TBT-Score erklären im Detail, was einen schlechten TBT-Score verursacht und wie Sie ihn verbessern können.

First Contentful Paint (FCP)

First Contentful Paint (FCP) ist ein Nicht-Core-Web-Vital, das die Zeit vom Beginn des Seitenladens bis zur Darstellung eines beliebigen Teils des Seiteninhalts auf dem Bildschirm misst. Ein schneller FCP vermittelt Nutzern das Gefühl, dass etwas passiert. In diesem Zusammenhang bedeutet Content: Text, Bilder (einschließlich Hintergrundbilder), <svg>-Elemente und nicht-weiße <canvas>-Elemente.

FCP ist sowohl in Felddaten als auch in Labordaten verfügbar, und je niedriger der FCP, desto besser.

So interpretieren Sie Ihren FCP-Score

So interpretieren Sie Ihren FCP-Score:

• Gut: <= 1,8 s
• Muss verbessert werden: > 1,8 s <= 3 s
• Schlecht: > 3 s

Was könnte einen schlechten FCP-Score verursachen

Häufige Ursachen für einen schlechten FCP-Score sind hohe Serverantwortzeiten und rendering-blockierende Ressourcen.

Ihren FCP-Score verbessern

Es gibt viele Möglichkeiten, Ihren FCP-Score zu verbessern, zum Beispiel das Entfernen rendering-blockierender Ressourcen, das Entfernen ungenutzten CSS, das Minifizieren von CSS und die Nutzung eines CDN.

Das Thema der Verbesserung Ihres FCP-Scores verdient wirklich einen eigenen Artikel. Bis wir einen verfasst haben, empfehlen wir Ihnen dringend, sich die Ressourcen von web.dev zur Optimierung von FCP-Scores anzusehen.

Speed Index (SI)

Speed IndexIndex
...indizieren, indexieren, noindex und mehr. Wenn in Bezug auf das Web vom „Index“ gesprochen wird, bezieht sich die Bezeichnung meist konkret auf den Index einer Suchmaschine und dabei meist auf den Index von Google.
Mehr erfahren (SI) ist ein Nicht-Core-Web-Vital, das misst, wie schnell der Inhalt einer Seite während des Seitenladens sichtbar befüllt wird. Er wird mittels Frame-für-Frame-Analyse des Ladeverhaltens Ihrer Seite berechnet, wobei der visuelle Fortschritt zwischen alle 100 ms erfassten Frames gezählt wird.

SI ist sowohl in Felddaten als auch in Labordaten verfügbar.

So interpretieren Sie Ihren SI-Score

So interpretieren Sie Ihren SI-Score:

• Gut: <= 3,4 s
• Muss verbessert werden: > 3,4 s <= 5,8 s
• Schlecht: > 5,8 s

Was könnte einen schlechten SI-Score verursachen

Alles, was die Seite daran hindert, schnell zu laden, schadet Ihrem SI-Score. Einige der bei den anderen Metriken genannten Ursachen, wie zum Beispiel ein blockierter Main-Thread, gelten auch hier.

Ihren SI-Score verbessern

Wenn Sie sich auf die Verbesserung der allgemeinen Ladeleistung Ihrer Seite konzentrieren, wird sich auch Ihr SI-Score verbessern. Wir empfehlen, die entsprechende Ressource von web.dev dazu hier anzusehen.

Time to Interactive (TTI)

Time to Interactive (TTI) ist ein Nicht-Core-Web-Vital, das die Zeit vom Beginn des Seitenladens bis zur vollständigen Interaktivität misst.

Damit sie vollständig interaktiv ist, muss sie:

1. Nützlichen Content anzeigen (gemessen durch First Contentful Paint).
2. Die meisten sichtbaren Seitenelemente gerendert haben.
3. Innerhalb von 50 ms auf Nutzerinteraktionen reagieren.

Obwohl es möglich ist, TTI im Feld zu messen, wird dies nicht empfohlen, da Nutzerinteraktionen die TTI Ihrer Seite stark beeinflussen können. Daher sollten Sie TTI nur aus einer Labordaten-Umgebung verwenden.

So interpretieren Sie Ihren TTI-Score

So interpretieren Sie Ihren TTI-Score:

• Gut: <= 3,8 s
• Muss verbessert werden: > 3,8 s <= 7,3 s
• Schlecht: > 7,3 s

Was könnte einen schlechten TTI-Score verursachen

Ähnlich wie bei der Speed-Index-Metrik oben gelten viele der Ursachen für schlechte Scores bei den anderen beschriebenen Metriken auch für TTI, da es sich um eine Metrik handelt, die diese anderen Metriken umfasst.

Ihren TTI-Score verbessern

Wir empfehlen, diesen Artikel von web.dev für die nächsten Schritte zur Verbesserung Ihres TTI zu lesen.

Äpfel mit Äpfeln vergleichen

Bei Core-Web-Vitals-Daten ist es unerlässlich, dass wir Äpfel mit Äpfeln vergleichen. Deshalb müssen wir die Unterschiede zwischen Felddaten und Labordaten sowie zwischen Mobil- und Desktop-Daten klar herausarbeiten.

Felddaten vs. Labordaten

Es gibt zwei Arten von Daten:

1. Felddaten werden von echten Nutzern erfasst. Jeweils mit ihrem eigenen Gerät und ihrer Netzwerkverbindung, über den Chrome User Experience Report (kurz „CrUX-Report“).
2. Labordaten werden nicht von echten Nutzern erfasst. Sie werden in einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkverbindungseinstellungen erfasst.

Es ist unerlässlich, dass Sie den Unterschied zwischen diesen beiden Datentypen verstehen. Nehmen Sie sich einen Moment Zeit, das zu verinnerlichen, da dies vielleicht der am häufigsten missverstandene Aspekt der Core-Web-Vitals-Metriken ist.

Möglicherweise erzielen Sie großartige Scores in Lighthouse (Labordaten) und klatschen sich selbst ab, während Ihre tatsächlichen Nutzer eine schlechte Nutzererfahrung haben (Felddaten). Umgekehrt kann es genauso sein – großartige Scores basierend auf Felddaten und schlechte Labordaten-Scores!

Dann gibt es noch die „Origin Summary“, die auf Felddaten basiert und die aggregierte Erfahrung aller von Ihrer Website ausgelieferten Seiten darstellt. Beachten Sie: Wenn Sie bestimmte Seitenvorlagen haben, die notorisch langsam laden, wirkt sich das negativ auf Ihren Origin-Summary-Score aus.

Verfügbarkeit der Web-Vitals-Metriken

Hier ist ein praktischer Überblick über die Verfügbarkeit der Web-Vitals-Metriken in Feld- und Labordaten:

Was Sie sonst noch über Felddaten wissen müssen

Felddaten:

• Stehen für Ihre Seiten möglicherweise nicht zur Verfügung, wenn diese nicht genug Besucher erhalten, sodass nicht genug CrUX-Daten vorliegen. Das gilt sowohl für einzelne URLs als auch für Ihre Origin Summary.
• Sind weniger nützlich für die Fehlerbehebung, da Sie nach Verbesserungen auf neue eintreffende CrUX-Daten warten müssen. Daher empfehlen wir, sich für Debugging-Zwecke auf Labordaten zu verlassen.
• Enthält auch Daten aus Märkten, die Sie nicht unbedingt bedienen. Wenn Sie beispielsweise primär die USA ansprechen, aber viel Traffic aus Schwellenländern erhalten, die keinen vergleichbaren Zugang zu schnellem Internet und Hardware haben, sehen Sie sehr durchmischte Felddaten – einfach, weil auch die Zielgruppe, aus der Ihre Felddaten erhoben werden, sehr durchmischt ist.
• Kann auch Daten von nicht indexierbaren Seiten wie PPC-Landingpages enthalten (Quelle) .

Was Sie sonst noch über Labordaten wissen müssen

Labordaten:

• Werden durch die Emulation eines Moto-G4-Smartphones mit schneller 3G-Verbindung erfasst.
• Enthalten keine Nutzerinteraktionsdaten, da Labordaten simuliert sind. Deshalb ist Interaction to Next Paint (INP) in Laborumgebungen nicht verfügbar.
• Liefern reproduzierbare Ergebnisse, da Sie die Hardware und Einstellungen (Internetverbindung und CPU-Leistung) kontrollieren.

Felddaten vs. Labordaten zusammengefasst

Ich würde Ihnen raten, sich für die erste Analyse so viele Felddaten wie möglich anzusehen, um die Probleme besser zu verstehen, die die Nutzererfahrung Ihrer Website beeinträchtigen. Nachdem Sie genug Erkenntnisse aus den Felddaten gewonnen haben, nutzen Sie die Labordaten für das eigentliche Testen und Debugging. Bedenken Sie, dass die Labordaten je nach Internetverbindung, Gerät, Standort usw. variieren, also machen Sie sich keine Sorgen, wenn Sie bei jedem Test Ihrer Website unterschiedliche Ergebnisse erhalten.

Es ist hier entscheidend, Ihre Erkenntnisse klar an andere Teams zu kommunizieren – von UX-Experten bis hin zu Entwicklern. Wenn es um Nutzererfahrung geht (besonders bei großen E-Commerce-Websites), können Sie nur erfolgreich sein, wenn das gesamte Team zusammenarbeitet.

Mobil- vs. Desktop-Daten

Bei der Recherche zu Ihren Core-Web-Vitals-Scores werden Sie auf Mobildaten, Desktop-Daten und eine Mischung aus beiden stoßen.

Sie können die Felddaten für Mobilgeräte und Desktop getrennt in PageSpeed Insights und der Google Search Console einsehen und die CrUX-Daten über BigQuery und das CrUX-Dashboard erkunden.

Es ist üblich, dass Ihre Desktop-Scores besser sind als Ihre Mobil-Scores. Das ist naheliegend, wenn man bedenkt, dass ein Desktop-Gerät oft über bessere Hardware und eine schnellere, zuverlässigere Internetverbindung verfügt.

Tools zur Messung Ihrer Core Web Vitals

Nachdem wir nun die Web-Vitals-Metriken und die Unterschiede zwischen Feld- und Labordaten sowie Desktop- und Mobildaten erklärt haben, gehen wir die beliebtesten Tools durch und sehen uns an, wie unsere Web Vitals darin aussehen:

1. Conductor Monitoring
2. PageSpeed Insights
3. web.dev Measure
4. Google Search Console

Conductor Monitoring

Conductor Monitoring überwacht Websites in Echtzeit, verfolgt Content-Änderungen und markiert SEO-Probleme, sobald sie auftreten. Im Falle von Problemen werden Sie benachrichtigt.

Bei Core Web Vitals überwacht die Conductor-Monitoring-Plattform die Origin Summary Ihrer Website (Felddaten) und die Lighthouse-Metriken (Labordaten) für alle Ihre Seiten.

Origin Summary

Die Origin Summary ist ein Aggregat über alle Seiten Ihrer Website und damit eine großartige Metrik, um schnell zu prüfen, wie die Core Web Vitals Ihrer Website insgesamt aussehen:

In diesem Beispiel wird die Core-Web-Vitals-Bewertung bestanden.

Von dort aus können Sie tiefer eintauchen, um zu sehen, welche Verbesserungen Sie noch vornehmen können:

Obwohl First Contentful Paint derzeit keine Core-Web-Vitals-Metrik ist, ist es ein wichtiger Indikator für die wahrgenommene Ladezeit.

Darüber hinaus glauben wir, dass Google First Contentful Paint in Zukunft zu einem Core Web Vital machen wird, oder zumindest dessen Bedeutung weiter erhöhen wird.

Lighthouse-Monitoring

Lighthouse ist eine Open-Source-Initiative, die Seiten diagnostiziert und Ihnen hilft, deren Performance basierend auf Labordaten zu verbessern. Lighthouse wird von verschiedenen Web-Performance-Tools genutzt (wie PageSpeed Insights, Web.dev Measure und Conductor Monitoring).

Conductor Monitoring überwacht Ihre Lighthouse-Scores für alle Ihre Seiten vollautomatisch.

Über die Graph-Ansicht der Pages können Sie Ihre Gesamtperformance einfach einsehen:

Sie können die Lighthouse-Daten in der Table-Ansicht der Pages filtern und sortieren:

Und natürlich können Sie sich ansehen, wie einzelne Seiten performen:

…was Sie verbessern müssen:

…wie sich die Lighthouse-Metriken verändern:

Und nicht zuletzt benachrichtigt Sie Conductor Monitoring auch, falls Ihre Lighthouse-Web-Vitals plötzlich abfallen!

Für einmalige Checks und alle, die mit den Chrome DevTools genauer einsteigen möchten, gibt es den Tab „Performance“, mit dem Sie die Web-Vitals-Metriken testen und debuggen können, wie zum Beispiel Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), First Paint (FP), First Contentful Paint (FCP) und/oder First Meaningful Paint (FMP).

Wenn Sie „Screenshots“ und „Web Vitals“ aktivieren, sehen Sie die verschiedenen Phasen, in denen sich Ihre Website während des Renderings auf einem Ticker entwickelt.

PageSpeedInsights.web.dev

Googles PageSpeed-Insights-Tool (kurz „PSI“) ermöglicht es Ihnen, eine URLURL
Der Begriff URL ist ein Akronym der Bezeichnung "Uniform Resource Locator".
Mehr erfahren einzureichen, worauf es drei Dinge tut:

1. Felddaten abrufen
2. Sammelt Labordaten durch Ausführen von Lighthouse .
3. Schlägt Verbesserungen unter „Opportunities“ und „Diagnostics“ vor.

Wir reichen erneut unsere HomepageHomepage
Eine Homepage bezeichnet zum einen die erste Seite im Root-Verzeichnis einer Website und zum anderen werden auch Domains oder Internet-Präsenzen „Homepage“ genannt.
Mehr erfahren ein, und das sind die Felddaten, die wir erhalten:

PageSpeed Insights zeigt Ihnen, welche Daten für Ihre URL vorliegen. Möglicherweise sehen Sie, dass einige Metriken nicht verfügbar sind – diese werden ausgegraut. Das ist eine Verbesserung, denn in den Anfangstagen blendete das Tool alle Metriken aus, wenn mindestens eine davon nicht verfügbar war.

Unterhalb der URL-spezifischen Felddaten können wir wählen, ob die „Origin Summary“ angezeigt werden soll (die aggregierte Nutzererfahrung aller von unserer Website ausgelieferten Seiten):

Beachten Sie, dass die Origin Summary ein anderes Bild unserer Performance zeichnet. Unsere website-weite Performance ist niedriger als die Performance der HomepageHomepage
Eine Homepage bezeichnet zum einen die erste Seite im Root-Verzeichnis einer Website und zum anderen werden auch Domains oder Internet-Präsenzen „Homepage“ genannt.
Mehr erfahren, was bedeutet, dass andere Seiten als die Homepage unsere Gesamtperformance nach unten ziehen.

Wenn Sie etwas weiter nach unten scrollen, sehen Sie die Labordaten:

Wenn Sie unsere Labordaten-Ergebnisse aus PageSpeed Insights mit Lighthouse vergleichen, werden Sie feststellen, dass sie unterschiedlich sind. Auch wenn wir mit denselben Einstellungen testen, testen wir nicht:

1. Am selben Standort (unser physischer Standort im Vergleich zum von PSI verwendeten Standort).
2. Mit derselben Hardware (ein MacBook aus 2018 im Vergleich zu PSIs Setup ).
3. Mit derselben Netzwerkverbindung (WLAN vs. PSIs Setup ).

Google Search Console

Die Google Search ConsoleGoogle Search Console
Bei der Google Search Console handelt es sich um ein kostenloses Web-Analyse-Tool, das von Google angeboten wird.
Mehr erfahren liefert Felddaten für Desktop- und Mobilgeräte für alle Ihre verifizierten Properties. Wenn Sie zu „Verbesserungen“ > „Core Web Vitals“ navigieren, finden Sie den folgenden Bildschirm:

Wenn Sie bei Mobil oder Desktop auf „Bericht öffnen“ klicken, wird eine detailliertere Ansicht Ihrer Core-Web-Vitals-Performance für diesen Gerätetyp angezeigt. Wenn wir auf „Mobil“ klicken, sehen wir Folgendes:

Sieht so aus, als würden wir ziemlich gut abschneiden!

Klicken Sie auf eine beliebige Zeile in der Detailtabelle, um zu einer Übersicht mit Beispiel-URLs zu gelangen. URLs, die Google als ähnlich einstuft, werden gruppiert. Bei unserer Website werden zum Beispiel einige der verschiedenen Templates gruppiert. Es ist sinnvoll, dass Google diese URLs gruppiert, da sie oft unter denselben Problemen leiden, die die Ladeperformance beeinträchtigen.

Zusammenfassung: Welche Daten bieten welche Tools

Wenn man weiß, dass Google die Performance aller Seiten einer Website bewertet (sogar nicht indexierbare Seiten), kann das überwältigend wirken. Deshalb erfordert die Optimierung der Core Web Vitals Ihrer Website einen klugen Ansatz.

Beginnen Sie mit website-weiten Elementen, die Probleme verursachen (z. B. Icons in der Navigation, die Layoutverschiebungen auslösen). Denken Sie dann an Templates: Homepage, Kategorieseiten, Serviceseiten, Produktseiten, Blogs usw. Sie alle haben gemeinsame Probleme. Wenn Sie also ein Template korrigieren, verbessern Sie alle Seiten, die dieses Template verwenden.

Außerdem ist es nach Abschluss der Optimierung sinnvoll, einen Prozess für das Hinzufügen neuer Elemente/Content-Blöcke auf der Website zu etablieren, damit diese die Performance nicht beeinträchtigen. Ein gutes Beispiel ist das Einbinden von Tweets per Screenshot statt per Embed: Eines meiner Experimente zeigte einen Unterschied von 11,5 Sekunden zu 1,9 Sekunden bei ungenutztem JavaScript durch nur einen eingebetteten Tweet, den ich durch einen Screenshot ersetzt habe. Solche Prozesse tragen dazu bei, die Core-Web-Vitals-Optimierung zukunftssicher zu machen.

Wie wird Ihr Lighthouse-Performance-Score berechnet?

Wir haben die Web-Vitals-Scores bereits ausführlich behandelt, aber wir haben noch nicht darauf eingegangen, wie der gesamte Lighthouse-Performance-Score berechnet wird. Zunächst einmal basiert der Lighthouse-Performance-Score auf Labordaten. Es handelt sich um einen Wert auf einer Skala von 4 (sehr schlecht) bis 100 (großartig). Es ist ein gewichteter Durchschnitt der Metrik-Scores der Web Vitals, wobei die Scores nicht alle gleich gewichtet werden.

Die Gewichtungen für die aktuelle Version – Version 8 – und die vorherige Version 6/7 sind wie folgt:

Hinweis: Vitals mit einem * sind Core Web Vitals

Wichtige Hinweise:

1. Der Performance-Score, den Sie in Lighthouse und anderen Tools finden, die auf Lighthouse-Daten basieren, basiert immer auf Labordaten.
2. In der obigen Tabelle werden nur zwei Core-Web-Vitals-Metriken angezeigt. Das liegt daran, dass die dritte, First Input Delay, in einer Laborumgebung nicht messbar ist.

Die Scores der Web-Vitals-Metriken werden basierend auf ihrer Performance relativ zu echten Website-Performance-Daten aus dem HTTP Archive berechnet.

Zum Beispiel wird ein Largest-Contentful-Paint-(LCP)-Metrikwert von 1.220 ms basierend auf HTTP-Archive-Daten einem Metrik-Score von 99 zugeordnet.

Lighthouse verwendet dann die folgenden farbcodierten Bereiche, um Ihren Score zu „bewerten“:

• Rot (schlecht): 0 bis 49
• Orange (muss verbessert werden): 50 bis 89
• Grün (gut): 90 bis 100

Wir empfehlen dringend, mit dem Lighthouse Scoring Calculator zu experimentieren, der den Score sofort aktualisiert, wenn Sie die Metriken ändern. Um Zeit beim Konfigurieren des Rechners zu sparen, geben Sie eine URL in PageSpeed Insights ein und klicken Sie auf den Link See calculator unterhalb der Tabelle mit den Labordaten:

Denken Sie daran, dass Ihre Seite bei allen drei Core Web Vitals im grünen Bereich liegen muss, um die Core-Web-Vitals-Bewertung zu bestehen:

1. Largest Contentful Paint (LCP)
2. Interaction to Next Paint (INP)
3. Cumulative Layout Shift (CLS)

Die Zukunft von Core Web Vitals

Wir haben behandelt, was die Core Web Vitals derzeit sind, aber was hält die Zukunft für uns bereit? Wir werden in den nächsten Jahren wahrscheinlich viele Änderungen sehen, da Google sie weiterhin anpassen wird.

CWV werden weiterhin eine richtungsweisende Möglichkeit sein, zu verstehen, wie Google Ihre Website erlebt, ähnlich wie heute. Sie werden aller Wahrscheinlichkeit nach kein größerer Faktor für die Sichtbarkeit werden, als sie es derzeit sind. Sie sollten ihnen also weiterhin Aufmerksamkeit schenken, sich aber nicht zu sehr auf das „Reparieren“ fixieren, es sei denn, die Werte sind sehr alarmierend.

In 99 von 100 Fällen gibt es wirkungsvollere Maßnahmen, die Sie auf Ihrer Website umsetzen können, aber sie bleiben weiterhin etwas, dem Sie Aufmerksamkeit schenken sollten.