Die Core Web Vitals sind seit Juni 2021 offizieller ein Ranking-Faktor in der Google-Suche.
Sie sollen dazu dienen, die Nutzererfahrung einer Webseite besser zu bewerten.
Das Problem dabei ist:
Die Core Web Vitals sind ein techniklastiges Thema. Und Google selbst bietet bislang wenig Hilfestellung dazu auf Deutsch an.
Deshalb habe ich diese umfassende Anleitung zu den Core Web Vitals erstellt.
Hier erfährst du unter anderem:
- Was die Core Web Vitals sind
- Wie wichtig sie als Ranking-Faktor sind (und ob es sich lohnt, darauf zu optimieren)
- Was zur Hölle all die Akronyme eigentlich bedeuten (FID, CLS, LCP, FCP, TTFB etc.)
1. Was sind die Core Web Vitals?
Die Core Web Vitals bestehen aus folgenden drei Unterpunkten:
- Largest Contentful Paint (LCP): Der LCP misst, wie lange das größte Elemente einer Webseite (im zuerst sichtbaren Darstellungsberich) zum Laden braucht, wodurch die “wahrgenommene Ladezeit” einer Webseite bewertet wird.
- First Input Delay (FID): Der FID misst, wie lange eine Webseite braucht, um auf die erste Interaktion eines Nutzers (Mausklick, Scrollen etc.) zu reagieren. Dadurch wird die “Interaktivität” einer Webseite bewertet.
- Cumulative Layout Shift (CLS): Der CLS misst, wie sehr sich das Seitenlayout während des Ladens verschiebt und soll die visuelle Stabilität einer Webseite bewerten.
Als Ranking-Faktor reihen sie sich in diverse bereits bestehende Faktoren zur Bewertung der Seitenerfahrung (Page Experience) ein, wie z. B. die Nutzerfreundlichkeit auf Mobilgeräten oder HTTPS:
Wann wurden die Core Web Vitals eingeführt?
Die Core Web Vitals sollten ursprünglich ab Mai 2021 im Rahmen des Page Experience Updates ein Ranking-Faktor für die Google-Suche werden.
Im April 2021 kündigte Google jedoch an, Publishern mehr Zeit für die Anpassung zu lassen und das Update erst Mitte Juni einzuspielen. Der Roll-out wurde am 2. September 2021 abgeschlossen.
2. Die Core Web Vitals als Ranking-Faktor
Die Core Web Vitals sind ein von Google bestätigter Ranking-Faktor (und davon gibt es nicht allzu viele, oder zumindest nicht so viele, die so gut messbar sind).
Aber bitte mache nicht den Fehler, sie überzubewerten.
Bevor du mit der Optimierung anfängst, solltest du folgendes über sie wissen:
1. Die Core Web Vitals werden (erst einmal) kein großes Ding
Es deutet aktuell wenig darauf hin, dass die Core Web Vitals große direkte Auswirkungen auf das Ranking haben.
Gary Illyes von Google betonte z. B. im September 2020 auf Reddit, dass die Core Web Vitals nichts mit der Qualität und Relevanz von Suchergebnisse zu tun haben und deswegen höchstwahrscheinlich nie zum wichtigsten Ranking-Faktor werden würden:
Like any other search engine, Google works hard to surface the highest quality and most relevant results for users’ queries. CWV has nothing to do with either of those, not even remotely, so it’s extremely unlikely that CWV would ever become “the primary factor for Organic Traffic”. That’s not to say you can ignore CWV, though.
Ein Hilfedokument zu den Core Web Vitals in der Google Search Central bestärkt die Aussage von Illyes. Die Core Web Vitals sind demnach eher ein Zünglein an der Waage:
Die Nutzerfreundlichkeit ist zwar wichtig, dennoch berücksichtigt Google beim Ranking weiterhin vor allem die angebotenen Informationen, auch wenn die Nutzererfahrung in mancher Hinsicht unterdurchschnittlich ausfällt. Eine gute Nutzerfreundlichkeit bedeutet nicht, dass relevante Inhalte unwichtiger werden. Wenn allerdings viele Seiten ähnlich relevante Inhalte haben, kann die Nutzerfreundlichkeit einen wesentlich größeren Einfluss auf die Sichtbarkeit in der Google Suche haben.
Ähnliche Aussagen findet man auch von anderen Google-Mitarbeitern, wie z. B. Danny Sullivan, Martin Splitt oder John Mueller.
Und nein, falls du dich wunderst:
Viele von Googles eigenen Webseiten bestehen den Test selbst nicht. Darunter auch die offizielle Seite zu den Core Web Vitals, die einen viel zu hohen CLS-Wert hat:
2. Sie sind erst einmal nur Ranking-Faktor für die mobile Suche
Die Core Web Vitals sind erst einmal nur ein Ranking-Faktor für die mobile Suche.
Das lässt dich diesem FAQ in der Search Console-Hilfe entnehmen:
Q: Is there a difference between desktop and mobile ranking?
A: At this time, using page experience as a signal for ranking will apply only to mobile Search.
Achte beim Testen also vornehmlich darauf, dass deine Seiten den Core-Web-Vitals-Test mobil bestehen:
Allerdings:
Google hat kürzlich in einem Video zur Google I/O angekündigt, dass die Core Web Vitals auch ein Ranking-Faktor für die Desktop-Suche werden.
3. Alle drei Tests zu bestehen, gibt den größten Ranking-Boost
Der Ranking-Boost durch die Core Web Vitals ist für eine Seite am größten, wenn sie die Schwellenwerte aller drei Core Web Vitals (in PageSpeed Insights markiert durch ).
Eine Seite kann laut John Mueller jedoch auch einen Ranking-Boost bekommen, wenn deren Core Web Vitals als gelb/zu optimieren eingestuft sind.
Hier findest du einen Überbick über die Schwellenwerte:
| Gut | Schlecht | Perzentil | |
|---|---|---|---|
| LCP | ≤ 2,5 s | > 4 s | 75 |
| FID | ≤ 100 ms | > 300 ms | 75 |
| CLS | ≤ 0,1 | > 0,25 | 75 |
Ein Perzentil von 75 bedeutet, dass 3 von 4 Nutzermessungen (also 75 %) im guten Bereich liegen müssen, damit deine Seite insgesamt als “gut” für einen der drei Core Web Vitals eingestuft wird.
Der PageSpeed-Score (im grünen, gelben oder roten Kreis) ist für die Core Web Vitals übrigens irrelevant, obwohl er natürlich ein guter Indikator ist.
Du kannst Werte von 95, 97 oder sogar 100 haben und den Core-Web-Vitals-Test trotzdem nicht bestehen:
Das hat zwei Gründe:
Erstens errechnet sich der PageSpeed-Score nicht nur aus den Core Web Vitals (LCP, FID und CLS), sondern auch aus TTI, TTB, SI und FCP. Die genaue Zusammensetzung des Scores findest du hier.
Zweitens errechnet er sich ausschließlich aus Labdaten. Die sind jedoch für die Core Web Vitals nicht entscheidend:
4. Die Felddaten zählen, nicht die Labdaten!
Zum Bestehen des Core Web Vitals-Tests zählen ausschließlich Felddaten, wie man auf der offizielle Seite bei web.dev nachlesen kann:
While all of the Core Web Vitals are, first and foremost, field metrics, many of them are also measurable in the lab.
Bei Felddaten handelt es sich um Messungen von echten Chrome-Nutzern, die im sogenannten Chrome User Experience Report (CrUX) gesammelt werden.
Die Labdaten, die dir in PageSpeed Insights oder einem Lighthouse-Test mit den Chrome DevTools angezeigt werden, sind hingegen “unter Laborbedingungen” gemessen und stellen als solche nur eine eingeschränkte Momentaufnahme dar, weshalb sie auch nur bedingt als Ranking-Faktor taugen.
Die Felddaten aus dem CrUX der letzten 28 Tage kannst du in PageSpeed Insights sehen:
Wenn du Daten aus dem CrUX einsehen möchtest, die länger zurückliegen, kannst du das mit dem CrUX Dashboard in Google Data Studio machen.
Damit kann ich mir für Gradually AI (hier noch blogmojo.de) z. B. die aggregierten Daten für den aggregierten FID von Mai 2020 bis Feburar 2021 anzeigen lassen:
Auch die Daten aus dem Core Web Vitals-Bericht in der Google Search Console zeigen Felddaten an:
5. Aggregierte vs. URL-spezifische Felddaten
Vielleicht ist dir bei PageSpeed Insights schon einmal aufgefallen, dass nicht bei allen URLs Felddaten angezeigt werden, sondern nur die sogenannte Origin Summary:
Dabei handelt es sich um einen domainweit berechneten Mittelwert, der immer dann angezeigt wird, wenn nicht genügend Felddaten zur Verfügung stehen, also eine Seite nicht von ausreichend vielen Chrome-Nutzern besucht wurde.
Im Core Web Vitals-Bericht in der Google Search Console werden LCP, FID und CLS übrigens auch aggregiert angezeigt (aufgeteilt nach verschiedenen URL-Gruppen):
Dabei gilt:
Wenn in den letzten 28 Tagen genügend Felddaten für eine URL gesammelt werden konnten, dann wird diese auch nach diesen URL-spezifischen Felddaten bewertet.
Denn die Core Web Vitals sind laut Core Web Vitals FAQ von Dezember 2020 sind prinzipiell ein seitenbezogener Ranking-Faktor:
Q: Is Google recommending that all my pages hit these thresholds? What’s the benefit?
A: We recommend that websites use these three thresholds as a guidepost for optimal user experience across all pages. Core Web Vitals thresholds are assessed at the per-page level […]
Wenn allerdings nicht genügend Felddaten zur Verfügung stellen, z. B. bei neu veröffentlichten oder wenig besuchten Seiten, wird eine Seite laut Core Web Vitals FAQ von März 2021 nach aggregierten Daten der dazugehörigen Domain/Website bewertet, also den Daten, die du in der Origin Summary sehen kannst:
Q: How is a score calculated for a URL that was recently published, and hasn’t yet generated 28 days of data?
A: Similar to how Search Console reports page experience data, we can employ techniques like grouping pages that are similar and compute scores based on that aggregation. This is applicable to pages that receive little to no traffic, so small sites without field data don’t need to be worried.
Und das heißt:
Du solltest alle Seiten auf deiner Website optimieren, denn schlecht optimierte Seiten können die gut optimierten herunterziehen.
3. Lohnt sich die Optimierung?
Es kommt darauf an:
Wenn du bislang keine oder nur wenige Rankings in den Top 10 hast, dann solltest du dich eher auf andere Dinge konzentrieren, wie z. B. Link-Building, Keyword-Recherche und -Optimierung und die Qualität deines Contents.
Wenn du allerdings viele Rankings in den Top 10 hast und du vielleicht sogar in einer Nische mit starker Konkurrenz unterwegs bist (Finanzen, Webhosting, Fitness, Online-Marketing, Ernährung etc.), kann es sich durchaus lohnen, deine Core Web Vitals zu optimieren.
Sagen wir z. B. deine Seite ist auf Platz 4 für ein Keyword mit hohem Suchvolumen und hoher Kaufbereitschaft und in puncto E-A-T und Relevanz für Google fast genauso stark wie die Seite auf Platz 3.
Dann kann ein kleiner Boost durch die Core Web Vitals möglicherweise dafür sorgen, dass sich die Waage zu deiner Seite neigt und du auf Platz 3 landest. Und, je nach Keyword, kann das einige hundert oder sogar einige tausend Euro mehr Umsatz im Monat bedeuten.
Du hast dich, dazu entschieden, deine Core Web Vitals zu optimieren?
Dann lies weiter und hake einfach jeden der folgenden Punkte ab!
Damit du deine Seiten gezielter optimieren kannst, habe ich meine Checkliste nach LCP, FID und CLS sortiert und dafür eigene Unterseiten erstellt (bitte beachte dabei, dass sich manche Punkte bei LCP und FID überschneiden).
4. Empfohlene WordPress-Plugins
Ich habe viele verschiedene Caching- und Performance-Plugins getestet, darunter auch z. B. Nitropack, Flying Press oder Autoptimize. WP Rocket bietet jedoch das beste Gesamtpaket. Mit dem Plugin alleine lassen sich ca. 80 % aller Punkte auf der Checkliste abhaken.
Mit perfmatters kannst du nicht benötigte CSS- und JS-Dateien global oder auf Seitenbasis ausschalten. Das hilft enorm dabei, überladene WordPress-Installationen zu entschlacken.
Mit dem EWWW Image Optimizer kannst du Bilder komprimieren und in WebP umwandeln, was sie deutlich verkleinert und deinen LCP verbessern kann. Wahlweise kannst du auch Imagify oder ShortPixel nehmen.
5. Die 30-Punkte-Checkliste
Hier findest du eine Checkliste mit allen Optimierungsmaßnhamen.
Bitte beachte, dass manche Maßnahmen zwei Core Web Vitals gleichzeitig verbessern können.
Viele Maßnahmen, um den FID zu verbessern, wirken sich z. B. auch positiv auf den LCP aus. Punkte, die schon bei anderen Web Vitals genannt wurden, habe ich mit Stern (✪) markiert.
Cumulative Layout Shift (CLS) optimieren
| 1 | Breite und Höhe von Bildern ergänzen |
| 2 | Vermeide Flash of Invisible Text (FOIT) |
| 3 | Vermeide Flash of Unstyled Text (FOUT) |
| 4 | Embeds und iframes nachladen oder löschen |
| 5 | Anzeigen optimieren |
| 6 | Nicht zusammengesetzte Animationen vermeiden |
| 7 | Pop-ups, Banner und anderer dynamischer Content vermeiden oder optimieren |
| 8 | Kritisches CSS vorab laden (auch LCP) |
Largest Contentful Paint (LCP) optimieren
| 9 | Page-Caching verwenden |
| 10 | Cache Preloading verwenden |
| 11 | Lazy-Loading bei Bildern above the fold ausstellen |
| 12 | Textkomprimierung aktivieren (auch FID) |
| 13 | Drittanbieter-Code reduzieren (auch FID) |
| 14 | JavaScript verzögert laden (auch FID) |
| 15 | Verbindungen zu Drittservern vorab aufbauen (auch FID) |
| ✪ | Kritisches CSS vorab laden (auch CLS) |
| 16 | HTTP/2 verwenden |
| 17 | Bilder komprimieren |
| 18 | Bildqualität verringern |
| 19 | Moderne Bildformate verwenden |
| 20 | Bild-Abmessungen auf verfügbaren Platz anpassen |
| 21 | Bildgrößen regenerieren |
| 22 | Videoformate für animierte Bilder verwenden |
| 24 | Deinen Server optimieren |
| 25 | Unnötiges CSS und JavaScript entfernen (auch FID) |
| 26 | CSS- und JS-Dateien komprimieren (auch FID) |
| 27 | Unnötige Plugins deaktivieren (auch FID) |
| 28 | Ein schlankes WordPress-Theme verwenden (auch FID) |
First Input Delay (FID) optimieren
| 29 | Übermäßige DOM-Größe vermeiden |
| 30 | Long Tasks aufteilen |
| ✪ | Unnötiges JavaScript entfernen (auch LCP) |
| ✪ | Ein schlankes WordPress-Theme verwenden (auch LCP) |
| ✪ | JS-Dateien komprimieren (auch LCP) |
| ✪ | Textkomprimierung aktivieren (auch LCP) |
| ✪ | Unnötige Plugins deaktivieren (auch LCP) |
| ✪ | Drittserver-Code reduzieren (auch LCP) |
| ✪ | JavaScript verzögert laden (auch LCP) |
| ✪ | Drittservern-Verbindungen vorab aufbauen (auch LCP) |
6. News
Hier findest du die neuesten Entwicklungen rund um die Core Web Vitals:
- 2. September 2021: Google bestätigt auf Twitter, dass der Roll-out des Page Experience Updates abgeschlossen ist (einschließlich der Updates zu Schlagzeilen-Karussells).
- 6. August 2021: Laut John Mueller sind die Core Web Vitals als Ranking-Faktor nicht nur ein „Tie-Breaker“ (Zünglein an der Waage)
- 15. Juni 2021: Google bestätigt auf Twitter, dass der Rollout des Page Experience Updates angefangen hat und Ende August abgeschlossen sein wird
- 10. Juni 2021: PageSpeed Insights zeigt laut den Release Notes nun auch Felddaten für LCP, CLS oder FID an, selbst wenn es für ein oder zwei andere Web Vitals noch keine Daten gibt
- 19. Mai 2021: URLs können laut John Mueller auch einen Ranking-Boost bekommen, wenn deren Core Web Vitals gelb/zu optimieren sind
- 19. Mai 2021: Die von Google angekündigte Neuberechnung des CLS-Scores ist laut John Mueller noch nicht live
- 18. Mai 2021: Die Core Web Vitals werden laut Google auch ein Ranking-Faktor für die Desktop-Suche
- 19. April 2021: Google führt Bericht zum Verhalten von Seiten in der Google Search Console ein
- 19. April 2021: Google kündigt an, dass die Core Web Vitals nicht ab Mai, sondern erst ab Mitte Juni in den Algorithmus integriert werden
7. Glossar (die Akronyme aus der Hölle)
FID, CLS, LCP, FCP, TTFB, LMAA, Tatütata?
Wie du vielleicht schon mitbekommen hast, bringen die Core Web Vitals (und der generelle Bereich der Speed-Optimierung) dutzende Fachbegriffe mit sich, davon sehr viele Akronyme.
Damit du nicht beim Lesen dieses Guides verzweifelst, habe ich dir eine Liste mit den wichtigsten Begriffen und Akronymen zusammengestellt:
above the fold
Wenn etwas above the fold einer Webseite ist, dann ist es in dem Darstellungbereich, den ein Nutzer direkt beim Öffnen der Webseite sieht (ohne zu scrollen). Je nach Endgerät kann dieser Bereich unterschiedlich groß sein.
CLS (Cumulative Layout Shift)
Der CLS misst, wie sehr sich das Seitenlayout während des Ladens verschiebt und soll die visuelle Stabilität einer Webseite bewerten.
CPCSS (Critical Path CSS)
Als CPCSS bezeichnet man das CSS, das zur Darstellung des Contents above the fold einer Webseite benötigt wird.
CruX (Chrome User Experience Report)
Im CruX werden Daten zur Nutzererfahrung von Webseiten gesammelt. Dazu zählen neben LCP, FID und CLS auch weitere Performance-Daten die TTFB und den FCP. Die Daten stammen von echten Nutzern von Google Chrome, die ihren Browser-Verlauf mit ihrem Google-Account synchronisieren.
DOM (Document Object Model)
Als DOM bezeichnet man die verzweigte Baumstruktur eines HTML-Dokuments. Jedes HTML-Element (z. B. <p> oder <h1>) stellt ein DOM-Element (also einen Zweig des Baumes) dar und kann anderen Elementen über- oder untergeordnet sein. Eine übermäßige DOM-Größe kann den FID erhöhen.
FCP (First Contentful Paint)
Als FCP bezeichnet man die Zeit, die ein Browser benötigt, um das erste sichtbare Element einer Webseite (z. B. Text oder ein Bild) darstellt.
FID (First Input Delay)
Der FID misst, wie lange eine Webseite braucht, um auf die erste Interaktion eines Nutzers (Mausklick, Scrollen etc.) zu reagieren. Dadurch wird die “Interaktivität” einer Webseite bewertet.
FOIT (Flash of Invisible Test)
Als FOIT bezeichnet man das Phänomen, dass Text vor dem Laden eines Webfonts (wie z. B. Google Fonts) kurze oder längere Zeit gar nicht sichtbar ist.
FOUC (Flash of Unstyled Content)
Als FOUC bezeichnet man das Phänomen, das HTML-Elemente zunächst ohne CSS-Stile (also mit dem Default-Stylesheet des Browsers) „aufblitzen“, bevor die eigentlichen Stile geladen werden. FOUC kann entsprechend den CLS-Score verschlechtern.
FOUT (Flash of Unstyled Text)
Als FOUT bezeichnet man das Phänomen, dass Text, der in einem Webfont (z. B. Google Font) dargestellt werden soll, zunächst in einer lokal vorhandenen Standard-Schriftart (z. B. Arial oder Times New Roman) “aufblitzt”.
Haupt-Thread
Im Haupt-Thread (engl. main thread) eines Browsers werden die meisten wichtigen Rechenprozesse ausgeführt, die für das Anzeigen einer Webseite wichtig sind. Dazu zählen z. B. Layout (die Berechnung, wie groß jedes HTML-Element ist und wo es auf der Seite platziert ist), Paint (das Setzen der einzelnen Pixel) und die Ausführung von JavaScript.
LCP (Largest Contentful Paint)
Der LCP misst, wie lange das größte Elemente einer Webseite (im zuerst sichtbaren Darstellungsberich) zum Laden braucht, wodurch die “wahrgenommene Ladezeit” einer Webseite bewertet wird.
Long Task
Als Long Task bezeichnet man eine JavaScript-Aufgabe mit einer langen Ausführungszeit (über 50 ms). Solange ein Long Task aktiv ist, ist der Haupt-Thread des Browsers blockiert und Nutzer können nicht mit einer Webseite interagieren (scrollen, Text eingeben etc.). Viele Long Tasks auf eine Seite können zu einem hohen FID führen.
SI (Speed Index)
Der SI ist eine von Google verwendete Metrik, um die Geschwindigkeit einer Website zu messen. Die Kennzahl berücksichtigt nicht nur die Ladezeit einer Webseite, sondern auch den Verlauf des Seitenaufbaus.
TBT (Total Blocking Time)
Als TBT bezeichnet man die Gesamtzeit, in der der Haupt-Thread des Browsers durch das JavaScript einer Webseite blockiert ist. Je höher die TBT ist, desto mehr müssen Nutzer mit Verzögerungen bei der Interaktion mit einer Webseite rechnen. Eine hohe TBT geht oft mit einem hohen FID einher.
TTFB (Time to First Byte)
Als Time To First Byte (TTFB) bezeichnet man die Zeit, die ein Browser benötigt um das erste geladenen Byte einer Webseite zu laden.
TTI (Time to Interactive)
TTI misst, wie lange es dauert, bis eine Webseite komplett interaktiv ist (also keine Eingabeverzögerungen durch JavaScript mehr zu erwarten sind).
WebP
WebP ist ein modernes Bildformat, das von Google entwickelt wurde und eine bessere verlustbehaftete oder verlustfreie Kompression bietet als JPEG oder PNG, was für 24 bis 34 % kleinere Bilddateien sorgt.
8. FAQ
Hier findest du Antworten auf häufige Fragen rund um die Core Web Vitals:
Ich finde das Konzept der cloudbasieren Performance-Optimierung durchaus spannend und innovativ. Die Resultate sind für die wenige Arbeit, die man bei der Konfiguration aufwenden muss, ebenfalls beeindruckend.
Allerdings hat NitroPack viele Probleme mit CLS, insbesondere durch Flash of Unstyled Content (FOUT). Zudem sind die Bewertungen des Supports eher durchwachsen.
Ja, sind auch in anderen Browsern auf Mobilgeräten ein Ranking-Faktor. Sie werden lediglich durch Chrome-Nutzer gemessen.
Nein, ob dein LCP bei 1.000 ms (also deutlich besser als gefordert) oder bei 2.500 ms (genau auf der Grenze zwischen gut und verbesserungswürdig) liegt, ist egal. Es zählt, dass die Core Web Vitals im grünen Bereich liegen.
Ja, soweit ich John Mueller und das Core Web Vitals FAQ das verstanden habe, ist das möglich. Das heißt, dass du auch nicht indexierte oder vom Crawling ausgeschlossene Seiten auf die Core Web Vitals optimieren solltest.
Allerdings werden nicht indexierte Seiten natürlich nur in den CrUX Report aufgenommen, wenn sie von Chrome-Nutzern besucht wurden und auch dann nur, wenn sie die Synchronisierung ihres Browser-Verlaufs in Chrome aktiviert haben.
Dazu kommt, dass die Origin Summary auch nur dann relevant ist, wenn keine Felddaten zu einer Seite vorliegen.
Nein, nicht unbedingt, auch wenn die Nutzung von AMP sicherlich beim Bestehen des Tests helfen kann.
Tatsächlich werden laut Google sogar sämtliche Sichtbarkeits-Vorteile mit dem Page Experience Update aufgehoben, was sehr begrüßenswert ist. So werden AMP-Seiten nicht mehr durch das Blitz-Icon hervorgehoben und AMP ist auch nicht mehr erforderlich, um in das Schlagzeilen-Karussel (Top Stories) zu kommen.
Google hat auf jeden Fall schon eine Markierung mit einem Badge getestet. Ob es tatsächlich kommen wird, ist noch nicht zu 100 % klar.
Das ist noch nicht klar und wird laut diesem Video von Google noch angekündigt.
Das liegt daran, dass Google die Schwellenwerte oder die Berechnungsweise von LCP, FID und CLS immer mal wieder justiert.
Um den Core Web Vitals-Test zu bestehen, müssen nicht alle Felddaten für LCP, FID und CLS unter dem festgelegten Schwellenwert liegen, sondern lediglich 75 %.
Um einen guten LCP zu haben, reicht es also, dass das LCP-Element bei 3 von 4 Nutzern in unter 2,5 Sekunden geladen wurde.
Bestimmte Probleme mit den Core Web Vitals sind oft nicht nur auf eine einzelne URL einer Website beschränkt, sondern betreffen größere Bereiche einer Website oder sogar die gesamte Website. Deshalb führt die Search Console für jeden Problemtyp nur eine Teilmenge an URLs auf.
Nein, die Core Web Vitals sind nicht ein Ranking-Faktor für die Google-Suche in Chrome oder Chromium-basierten Browsern, sondern auch in anderen Browsern (Firefox, Safari etc.).
Ja, Webseiten können unabhängig von ihrem Abschneiden in der Page Experience oder ihren Core Web Vitals-Werten in das Schlagzeilenkarussell aufgenommen werden.
Werbehinweis für Links mit Sternchen (*)
Es handelt sich um einen Affiliate-Link, das heißt, wenn du auf der verlinkten Website etwas kaufst, erhalten wir eine Provision. Dies hat keinerlei Einfluss darauf, wie wir ein Tool oder einen Anbieter bewerten.
Wir empfehlen nur Tools bzw. Anbieter, hinter denen wir auch wirklich stehen. Für dich entstehen dadurch natürlich keine zusätzlichen Kosten! Du hilfst jedoch uns und diesem Projekt. Danke! ❤️
