Google Core Web Vitals

Seit Mai 2021 zieht Google die Core Web Vitals als Ranking-Faktoren heran. Bei den Core Web Vitals handelt es sich um Kennzahlen, die die Nutzererfahrung einer Website bewerten sollen. Google möchte dadurch das Nutzererlebnis einer Webseite nachverfolgen und legt dabei den Fokus auf technische Themen. Es werden dabei alle Seiten einer Website analysiert – auch noindex-Seiten können, laut John Mueller, in die Core Web Vitals einkalkuliert werden.

Die Core Web Vitals zählen zu den Page Experience Faktoren. Dazu zählt auch das Sicherheitsprotokoll HTTPS, welches Google seit 2014 in die Rankingfaktoren mit einbezieht. Wer seine Seite noch nicht umgestellt hat, sollte das möglichst zügig in die Hand nehmen. Des Weiteren werden in Zukunft Webseiten mit den beliebten PopUp Erscheinungen abgestraft. Dadurch sinkt die Interaktion des Nutzers mit der Website, da nun ein Klick weniger notwendig ist, um sich mit der Seite zu beschäftigen. Das heißt aber nicht, dass dadurch auch zugleich die Nutzererfahrung schlechter wird. Mithilfe von gutem Content, Call-to-Actions, Chatbots, Sidebars, etc. sollte die Seite so attraktiv und spannend wie möglich gestaltet werden, um den Nutzer eine gute User Experience sowie Interaktion zu ermöglichen.

Die Web Vitals wurden nicht vor 2021 als Ranking-Faktor verwendet. Empfohlen ist weiterhin, das Thema Core Web Vitals sobald wie möglich anzugehen, denn die Optimierungen sind komplexer und benötigen daher eine gewisse Zeit. Darüber hinaus ist eine frühzeitige Optimierung auch für die Kundenzufriedenheit besser. Websites, die eine kurze Ladezeit besitzen und die dazu nutzerfreundlich sind, beeinflussen nicht nur den Google-Algorithmus positiv, sondern steigern zudem auch die Zufriedenheit der eigenen Anwender.

Inhalte des Artikels:

Beeinflussung der Positionen durch die Core Web Vitals
Die Messwerte LCP, FID und CLS
Wie misst man die Core Web Vitals
Wie optimiert man die Core Web Vitals
Welches CMS erzielt die besten Ergebnisse
WordPress Plugins zur Verbesserung der Core Web Vitals
Tipps zur Verbesserung der WordPress Performance
Fazit

 

 

Beeinflussung der Positionen durch Core Web Vitals

Eine Studie von Screaming Frog zeigt, dass Websites zu weniger als 15% die Kriterien von Google erfüllen.
Beim Messwert Larest Contentful Paint erreichen 43% der mobilen URLs sowie 44% der Desktop-URLs die Kriterien. Bei der Kennzahl Cumulative Layout Shift sind es 46% der mobilen URLs sowie 47% der Desktop-URLs die Kriterien erfüllen. Diese Erkenntnisse zeigen, dass die Mehrheit der Nutzer, die auf Websites Inhalte abrufen, mit einer Ladezeit von mehr als 2,5 Sekunden rechnen müssen und sogar vor ihren Augen springenden Content sehen.

Ergebnisse der aktuellen Studie von Screaming Frog

In der nachfolgenden Abbildung sind die Prozentzahlen von mobilen Geräten sowie Desktop Geräten in Hinsicht auf die Erfolgsquoten der jeweiligen Positionen in Google dargestellt. Die Abbildung zeigt deutlich, dass URLs auf der ersten Position in Google eine Erfolgsquote von 19% auf mobilen Geräten sowie 20% auf Desktop Geräten aufweisen.
Für die Positionen zwei bis fünf sinkt die Erfolgsquote konstant. Das bedeutet, dass bei jeder schlechteren Position die Erfolgsquote um je 2% abfällt.
Die Erfolgsquoten in den Tests von mobilen Geräten bei den Positionen fünf bis neun liegen überwiegend bei 10% und bei den Desktop Geräten bei 11%.
URLs die auf dem ersten Rang in Google stehen erreichen demnach eine 10 % höhere Wahrscheinlichkeit die Core Web Vitals-Kriterien zu erfüllen als Position neun.

Quelle: Screaming Frog

Aufgrund der Ergebnisse der Studie ist es sehr wahrscheinlich, dass sich Core Web Vitals auf die Positionen in Google auswirken, obwohl sie offiziell noch keine Ranking-Faktoren sind. Screaming Frog hält die Wahrscheinlichkeit für sehr gering, möchte aber diese Annahme nicht vollständig ausschließen.

Bei den Web Vitals spielt die Ladegeschwindigkeit eine wichtige Rolle. Dieses Kriterium wird im Google-Ranking bereits miteinbezogen. Schnellere Websites haben auch ein besseres Ranking. Je schlechter heute die Position desto geringer ist auch die Wahrscheinlichkeit, die Core Web Vitals-Kriterien zu erfüllen. Da die Ladegeschwindigkeit kein primärer Faktor für das Ranking ist, spielt auch die bessere Qualität der Inhalte eine wichtige Rolle.

Google legt die nachfolgenden drei Kennzahlen zur Messung von Core Web Vitals fest.

 

 

Die Messwerte LCP, INP und CLS

 

Largest Contentful Paint (LCP)

Mit diesem Messwert wird die Zeit festgelegt, bis der primäre Inhalt der Website für den Anwender im Browser erscheint. Dabei war es in der Vergangenheit der Fall, dass Google den Inhalt zur Bewertung erfasst hat, der zuerst sichtbar war. Nun wird aber der Moment als Bewertung herangezogen, in dem der primäre Content sichtbar wird. Die Berechnung dieser Zeitspanne erfolgt in Sekunden. Google definiert kleiner-gleich (≤) 2,5 Sekunden als gut. Verbesserungswürdig sind bis zu 4 Sekunden und als schlecht bezeichnet Google mehr als 4 Sekunden.

Neuerung der Berechnung des LCPs ab Chrome 112

First Input Delay (FID)

Der FID misst die Interaktionszeit zwischen Nutzer und Seite. Wenn der Content einer Website vollständig sichtbar ist, möchte ein Besucher schnellstmöglich mit dieser Seite arbeiten. Wie schnell diese Interaktion gelingt, wird vom First Input Delay festgelegt. Der FID berechnet demnach die Zeit, wie lange es dauert, bis der Browser auf eine Anforderung vom Nutzer anspringt. Für Google sind bei dieser Kennzahl kleiner-gleich (≤) 0,1 Sekunden gut, verbesserungswürdig bis zu 0,3 Sekunden und als schlecht werden Interaktionszeiten mit mehr als 0,3 Sekunden festgelegt.

HINWEIS: Der Messwert FID wird ab März 2024 von dem neuen Messwert Interaction to Next Paint abgelöst.

Interaction to Next Paint (INP)

Bei der Interaction to Next Paint handelt es sich um einen Messwert, welcher die Reaktionsfähigkeit einer Website bewertet. Wenn eine Interaktion dazu führt, dass die Seite oder bestimmte Funktionen nicht mehr richtig funktionieren, führt dies automatisch zu einer schlechten Nutzererfahrung. 

Wenn also ein Akkordeon beispielsweise bei einem Klick (Interaktion) nicht richtig aufklappt, sondern zurückklappt, wird das mit dem INP gemessen.

Der neue Messwert wird im März 2024 eingesetzt. Ab diesem Zeitpunkt wird auch die FID-Metrik in der Google Search Console nicht mehr verfügbar sein bzw. angezeigt.

Weitere Informationen zu dem neuen Messwert Interaction to Next Paint (INP).

Cumulative Layout Shift (CLS)

Bei dieser Kennzahl liegt der Fokus auf der visuellen Stabilität hinsichtlich einer Website. Teilweise gibt es sehr komplizierte Websites, die Anteile vom Content asynchron laden. Dadurch kann dem Nutzer eine kürzere Ladezeit gewährleistet werden. Liegt keine Abstimmung zwischen diesen Ladevorgängen vor, so kann dies zur Folge haben, dass der angezeigte Inhalt der Seite vor den Augen der Nutzer beginnt auf- und abzuspringen, obwohl der User ihn aber zu diesem Zeitpunkt längst lesen möchte. Beim CLS legt Google den Wert kleiner-gleich (≤) 0,1 als gut fest, bis zu 0,25 als verbesserungswürdig und als schlecht mehr als 0,25.

  

 

Die nachfolgende Abbildung zeigt die Core Web Vitals an einem Beispiel. Dabei sind die schlechten URLs, die optimierungsbedürftigen sowie die guten URLs ersichtlich und werden in den Details näher erläutert.

 

Das nachfolgende Beispiel zeigt eine gezielt ausgewählte URL. Dabei sind die Kennzahlen CLS, FID und LCP ersichtlich.

 

 

Google zieht bezüglich der Core Web Vitals jedoch noch Veränderungen in Betracht und möchte sich nicht ausschließlich auf diese drei Kennzahlen zur Bewertung festlegen. Werden Kennzahlen verändert oder erweitert, wird diese Entscheidung rechtzeitig angekündigt.

 

 

Wie misst man die Core Web Vitals?

Google nimmt zwei Ansätze zur Messung der Core Web Vitals heran. Zum einen sogenannte Labor-Daten und zum anderen Feld-Daten. Empfohlen wird eine Kombination beider Ansätze, um das bestmögliche Ergebnis für die Messung der Core Web Vitals zu erhalten.

Labor-Daten

Wie der Name bereits verrät, werden bei dieser Datengewinnung Messungen im eigenen Labor und unter selbst kontrollierten Gegebenheiten ausgeführt. Labor-Daten sind also geschätzte Daten, die in einer simulierten Umgebung erzeugt werden.
Ein Vorteil dieser Labor-Daten ist es, dass diese Art von Daten immer die gleichen Ergebnisse generieren, außer es werden Veränderungen an den Größen oder Gegebenheiten getätigt. Die Qualität dieser Daten ist also von den festgelegten Mess-Gegebenheiten abhängig. Labor-Daten beinhalten jedoch kein reales Verhalten der Nutzer, was als negativer Aspekt betrachtet werden kann.

Feld-Daten

Bei den Feld-Daten werden die Werte der Core Web Vitals von realen Usern der eigenen Website herangezogen und aufbereitet. Dies wird möglicherweise über individuelle JavaScript-Einbindungen vollzogen oder über Messungen, die automatisch verlaufen. Google selbst nimmt Felddaten im Core Web Vitals-Bericht aus der Google Search Console.

 

 

Wie optimiert man die Core Web Vitals?

Es gibt keine unmittelbare einfache Lösung, um die Core Web Vitals (Page Experience Faktor) zu verbessern, denn jede Website ist individuell. Jeder muss seinen eigenen Core Web Vitals verstehen und anschließend individuell optimieren, um das gewünschte Ziel zu erreichen. Um das benötigte Verständnis bezüglich diesen Core Web Vitals aufzubringen, wird teilweise ein fundiertes Fachwissen benötigt, da die Core Web Vitals technisch gesehen sehr komplex sein können.

Google selbst hat einige Optimierungsmöglichkeiten festgehalten, die Sie hier einsehen können.

 

Lighthouse-Test über Developer Tools in Chrome starten

Um die LCP- und CLS-Werte auswerten zu können, sollte zunächst ein Lighthouse-Test über die Developer Tools (Rechtsklick + Untersuchen) erstellt werden. Danach erfolgt die direkte Analyse. Wichtig: Hier sollten sowohl Desktop als auch Mobil analysiert werden.

Hinweis: Bei Klick auf „Generate report“ wird die Seite neu geladen. Das dauert i.d.R. zwischen 15 und 90 Sekunden.

 

Performance der Website prüfen

Für die genaue Analyse der einzelnen Messwerte gehen wir in den Reiter „Performance“:

 

Und klicken anschließen auf „View Original Trace“:

 

Nun erhalten wir folgende Ansicht:

 

CLS-Optimierung: Vorgehen bei einem schlechten CLS-Wert:

 

Für die Analyse des CLS-Wertes prüfen wir folgende verschiedene Elemente:

• Timing: LCP, FP, FCP, DCL und L
• Experience: sämtliche Layout Shifts (Clear-Reload Aufzeichnung)
• Performance: Rendering-Frames

Dabei ergeben sich die zwei häufigsten CLS-Fehler:

1. Bilder laden erst nach dem Laden der Seite die korrekte Größe
   Problem: Das Layout verschiebt sich, da kein Platz für das Bild “reserviert” wurde.
   Lösung: Definition der korrekten Größe und Position. Liegt das Bild in einem Container, kann auch dieses Element festgelegt werden, um das Verschieben des Layouts zu vermeiden.

    

2. Child-Themes, die den Style des Parent-Themes überschreiben
   Problem: Es werden zuerst die Daten des Parent-Themes geladen und anschließend werden diese mit den Daten des Child-Themes überschrieben. Dieses Custom CSS verursacht nicht nur Verschiebungen im Layout, sondern auch eine längere Ladezeit.
   Lösung: Einfügen von Critical CSS in der Kopfzeile (head-Bereich) der Seite. Idealerweise sollten allgemein sämtliche Regeln im head-Bereich der Seite definiert werden, damit sie nicht über ein zusätzliches CSS geladen werden müssen. Dadurch liegen sie nämlich direkt beim Rendern der Seite vor.
   

Allgemein sollte beim CLS darauf geachtet werden, die Bestandteile nicht hinsichtlich der Größe zu ändern. Außerdem spielen hier die Größenangaben von Videoteilen oder Bildern eine wichtige Rolle. Zudem sollte kein Content zu Beginn der Seite automatisiert eingesetzt werden.

 

LCP-Optimierung: Vorgehen bei einem schlechte LCP-Wert:

 

Auch beim LCP-Wert prüfen wir die HTML-Elemente “Timings” und “Related Load”.

Oftmals liegt es nicht zwingend an den HTML-Elementen. Dann kommen weitere mögliche Ursachen in Frage:

• Die Bilddatei ist zu groß
  Lösung: Auflösung reduzieren und Kompression verbessern
• Die Schriftart wurde nicht richtig implementiert
  Lösung: CSS-Eigenschaft font-display:swap; hinterlegen
• Generelle Probleme mit Antwortzeiten vom Server oder Ladezeiten des HTML
  Lösung: Caching Plugins oder ähnliche serverseitige Optimierungen nutzen

Relevant für den LCP sind also die Antwortzeiten des Servers, Rendering-Blocking, Ressourcen-Ladezeiten sowie Client Side Rendering.

 

FID-Optimierung: Vorgehen bei einem schlechten FID-Wert:

 

Für die Analyse des FID-Wert gibt es kein genaues Vorgehen, da hierzu ein “echter Nutzer” benötigt wird. Man kann sich allerdings am TBT-Wert (Total Blocking Time) orientieren. Denn Optimierungen an dem TBT-Wert wirken sich i.d.R. auf den FID-Wert positiv aus.

Auch diesen Wert finden wir in den Developer Tools:

Der TBT-Wert gibt an, wie lange eine Seite für den Aufbau benötigt bis ein User das erste Mal mit ihr interagieren an, zum Beispiel ein Mausklick, Scrollen der Seite,usw. Dieser Wert setzt sich aus FCP (First Contentful Paint) und TTI (Time to Interactive) zusammen.

Der Messwert liegt hier bei 50ms. Jede “Task”, die länger als 50ms benötigt sich aufzubauen, enthält eine Total Blocking Time. Wird beispielsweise etwas 350ms geladen, ist die geblockte Zeit 300ms. Und das wiederum nimmt der Nutzer als Verzögerung wahr.

Meistens sind hierfür komplexe Javascript-Codes verantwortlich.
Die Lösung hier: Reduktion sämtlicher Skripte, die nicht für den visuellen Aufbau benötigt werden. Das geschieht mithilfe des Attributs “defer”.

Wichtig für den FID sind also folgende Aspekte: Beschleunigung der JavaScript-Ausführung, Entlastung Main-Thread und das Reduzieren von Requests und Dateigröße.

 

Hilfreiche Tools zur Optimierung der Core Web Vitals:

 

• Nutzerfreundlichkeit auf Mobilgeräten via Search Console
• Mobile Friendly Test via Google
• Core Web Vitals Bericht via Search Console
• Performance via PageSpeed Insights
• Performance, Progressive Web App (PWA), Best Practises, Accessibility & SEO via Lighthouse Report
• Nutzererfahrung via Chrome User Experience Report (CrUX)
• AMP (Accelerate Mobile Pages) erstellen via amp.dev

Hilfreiches Plugin für WordPress:

https://wordpress.org/plugins/accelerated-mobile-pages/

 

 

Welches CMS erzielt die besten Ergebnisse

 

Häufig fällt es CMS-Nutzern schwer, ihre Seite für die Core Web Vitals zu optimieren. Abhängig für eine gute Performance ist nämlich die Codierung der Webmaster Anbieter. Das bedeutet, dass der Nutzer nur bedingt die Ergebnisse seiner Web Vitals beeinflussen kann.

HTTP Archive hat die Top 5 CMS analysiert:

Largest Contentful Paint
Ab wann die Seite und deren Inhalte sichtbar sind

Gewinner: Drupal | Verlierer: Wix

Die Ergebnisse:

• Drupal – 47%
• Joomla – 38%
• WordPress – 25%
• Squarespace – 12%
• Wix – 9%

First Input Delay
Der erste Zeitpunkt einer möglichen Interaktion

Gewinner: Squarespace | Verlierer: Wix

Die Ergebnisse:

• Drupal – 91%
• Joomla – 88%
• WordPress – 76%
• Squarespace – 71%
• Wix – 46%

Cumulative Layout Shift
Die visuelle Stabilität der Website

Gewinner: Drupal | Verlierer: Squarespace

Die Ergebnisse:

• Drupal – 70%
• Joomla – 63%
• WordPress – 59%
• Squarespace – 57%
• Wix – 44%

Im Großen und Ganzen haben alle Systeme verbesserungsbedarf, denn es schneiden alle für den FID-Wert in Ordnung ab. Hingegen fallen die CLS- und LCP-Werte nicht so toll aus.

Seit diesem Quartal arbeiten jedoch die Webmaster an die Effizienz ihrer Content Management Systeme, wie zum Beispiel WordPress, dass erst kürzlich das Update und die Version 5.7 – Esperanza veröffentlicht hat.

 

 

WordPress Plugins zur Verbesserung der Core Web Vitals

 

Zusätzlich unterstützen einige Plugins die Verbesserung der Web Vitals in Ladegeschwindigkeit, Komprimierung von beispielsweise Bildern und vielem mehr. Zwar wird ein Plugin nicht alles optimieren können, jedoch trägt es schon immens zur Verbesserung bei.

Folgende WordPress Plugins unterstützen die Website in Bezug auf den neuen Rankingfaktor 2021:

Autoptimize

• Minifizierung von Bildern, HTML und CSS
• Optimierung und Lazy loading (Verzögerung) von Bildern
• Optimierung von Google Fonts
• …

Mehr zu Autoptimize

 

WordPress FEO

• Optimierung von HTML, CSS und JavaScript
• Komprimierung von Bildern (unterstützt Google Guetzli und WebP)
• Lazy loading von Bildern
• erweitertes Caching mit PHP Opcache möglich
• und vieles mehr…

Humming Bird

• Textkomprimierung
• Effizientes Caching
• Optimierung der JavaScript Ausführungen
• Verschiebung von kritischem JavaScript und ungenutztem CSS
• Minifizierung von CSS und JavaScript
• viele weitere Features

Smush

• Optimierung und Komprimierung von Bildern
• Lazy loading
• und vieles mehr

 

Tipps für WordPress Nutzer zur Verbesserung der Performance

 

Für einen Test der WordPress Performance können folgende Tools genutzt werden:

• PageSpeed Insights (von Google)
• Pingdom Website Speed Test
• GTmetrix

Optimierung der allgemeinen WordPress Performance mithilfe von:

• Theme und Einstellungen überprüfen (z.B. Slider, Kommentarfunktion, etc.)
• Standard-Loop verwenden:
• style.css bereinigen (Addon für Firefox: CSS-Usage)
• style.css optimieren (mit bspw. einem Plugin wie CSS Minify)
• Inline CSS statt CSS-Datei – vorher prüfen!
• unnötiges JavaScript entfernen (meist im Head-Bereich)
• CDN-Dienst nutzen
• überflüssige Plugins löschen

Snippets für eine bessere WP Performance:

• unnötige Links im Head entfernen
• Kommentare abschalten
• Thumbnail-Qualität regulieren
• RSS Feeds abschalten
• HTML minifizieren
• HTTP Verbindungen blocken: define(‚WP_HTTP_BLOCK_EXTERNAL‘, true);
• WordPress Heartbeat API deaktivieren
• Emoji-Support deaktivieren
• Embeds und Responsive Images deaktivieren (mehr dazu)
• XML-RPC deaktivieren

Quelle: fastWP Magazin

 

 

Fazit

Es ist sehr sinnvoll bereits jetzt an den neuen Stellschrauben zu drehen. Eine Optimierung hilft den Besuchern und steigert die User-Experience. Und die bessere Nutzbarkeit hilft heut schon zu besseren Rankings und verbessert morgen den Rang in Google vermutlich erheblich.

 

Häufige Fragen zu Core Web Vitals

 

Was sind die Core Web Vitals Metriken und warum sind diese für den Benutzer wichtig?

 

Die Metriken der Core Web Vitals stellen ein relevantes Hilfsmittel dar, damit die Nutzererfahrung der eigenen Webseite besser verstanden und dadurch optimiert werden kann. Die Metriken für Core Web Vitals sind Largest Contentful Paint, First Input Delay und Cumulative Layout Shift.

Wird von Google empfohlen, dass all meine Seiten diese Schwellenwerte erreichen? Welchen Vorteil erhalte ich dadurch?

 

Es ist empfohlen, alle drei Schwellenwerte für eine Website als Leitlinie zu verwenden, um eine bestmögliche Nutzererfahrung zu erzielen. Diese Werte werden auf Seitenebene betrachtet. Es gibt viele Webseiten, die unter oder über diesen Werten liegen. Das bemerkt der Nutzer und wird dadurch ein Fazit bezüglich der Nutzererfahrung ziehen. Es ist wichtig, ein gemeinsames Ziel für diese Metriken und dazugehörigen Schwellenwerte zu verfolgen, damit ein gesundes Web-Ökosystem beibehalten werden kann. Der Vorteil der Erreichung der Schwellenwerte ist ganz eindeutig: Es wird eine bessere Nutzererfahrung gewährleistet.

Erfüllt eine AMP Seite (Accelerated Mobile Page) die empfohlenen Werte?

 

Da AMP-Seiten die Geschwindigkeit von mobilen Geräten verbessern soll, ist es sehr wahrscheinlich, dass diese AMP-Seiten die Schwellenwerte der Metriken erzielen. AMP-Seiten haben einen zeitlosen Charakter und liefern dem Nutzern eine lange Zeit den Mehrwert von schnelleren Ladezeiten bei mobilen Seiten. Daher ist ein Vorteil dieser Seiten, dass man Leistungsverbesserungen erreichen kann, ohne, dass grundlegend die Basis verändert werden muss. Allerdings gibt es Punkte, die AMP-Seiten bezüglich den Schwellenwerten nicht decken, weshalb es eventuell sein kann, dass Seiten diese Schwellenwerte nicht erreichen.

Kann eine Seite auch ohne AMP die Schwellenwerte erreichen?

 

Eine Seite kann die empfohlenen Schwellenwerte auch ohne AMP erreichen. Durch die Verwendung von AMP besteht die Möglichkeit, dass man die Best Practices für die Webentwicklung ohne zusätzlichen Aufwand in das Framework mitaufnehmen kann.

Erfüllt meine Website die empfohlenen Schwellenwerte, wenn sie eine progressive Web App ist?

 

Das muss nicht zwingend sein. Das ist von der Implementierung der App sowie der echten Benutzererfahrung abhängig. Daher ist es sinnvoll, dass sich alle Websites, egal ob eine progressive Web App oder nicht, auf Ladegeschwindigkeit, Interaktivität und Layout Stabilität fokussieren. Alle progressive Web Apps sollten daher die Richtlinien der Core Web Vitals befolgen.

Empfohlenen Schwellenwerte erfüllen, wenn es sich um eine Einzelseiten-Webanwendung handelt?

 

Bei den Core Web Vitals werden die Erfahrungen der Nutzer gemessen. Es werden nicht die Technologien zur Bereitstellung dieser Nutzererfahrung herangezogen. Die Metriken für die Core Web Vitals sind für Einzelseiten-Webanwendung genauso relevant als für andere Technologien. Daher ist es nicht relevant, welche Technologie oder Architektur gewählt wird, sondern entscheidend ist die beobachtete Benutzererfahrung.

Meine Website eignet sich auch für mobile Endgeräte. Allerdings ist mein Core Web Vitals-Score für das mobile Gerät niedrig. Warum ist da so?

 

Core Web Vitals und die Mobile Freundlichkeit sollten sich nicht überschneiden, sondern sie sollten sich ergänzen. Dadurch ist eine ganzheitliche Optimierung der Benutzererfahrung gewährleistet.

Wie kann ich meinen LCP/ CLS / FID-Score verbessern?

 

Die Optimierungsmöglichkeiten der Core Web Vitals wurden bereits im Artikel erwähnt. Gerne können Sie zusätzlich unter web.dev/fast die Optimierungsmöglichkeiten nachlesen. Kenntnisse in der Web-Entwicklung sind für die Optimierung der Core Web Vitals essenziell. Daher ist es empfohlen, einen Fachmann hinzuzuziehen.

Warum unterscheiden sich die Punktzahlen zwischen Handy und Desktop?

 

Momentan ist die Seitenerfahrung nur für die mobile Suche ausschlaggebend. Daher hat die Benutzererfahrung nur Einfluss auf das Ranking in der mobilen Suche. Außerdem sind die Benutzer von Desktop sowie Mobilen Geräten eventuell in sämtlichen Bereichen wie Gerät, Größe des Ansichtsfensters oder die Konnektivität des Netzwerks eingeschränkt.

Können Sitzungen, die keinen FID melden, als „Bounce“ -Sitzungen betrachtet werden?

 

Nein können sie nicht. Absprungrate und Abbruchrate werden bei der Gestaltung der Core Web Vitals Metriken nicht berücksichtigt.

Wie werden Webseiten von den Core Web Vitals berücksichtigt, bei denen Nutzer ältere Geräte oder langsamere Netzwerke haben?

 

Hier ist es vor allem sinnvoll, den Inhalt dieser Webseiten anzupassen, um den Benutzern zu gewährleisten, dass diese immer noch eine optimale Benutzererfahrung erhalten und dadurch die empfohlenen Core Web Vitals-Grenzwerte erfüllen.

Wird das Ranking durch Core Web Vitals beeinflusst?

 

Die Core Web Vitals werden ab Mai 2021 in die Seitenerfahrungssignale gemeinsam mit bestehenden Signalen wie Mobile Friendly, Safe-Browsing, HTTPS-Security und Intrusive Interstitielle Richtlinien aufgenommen.

Wie legt Google fest, welche Seiten von der Bewertung der Benutzererfahrung und der Anwendung als Ranking-Signal betroffen sind?

 

Die Erfahrung der Benutzer ist ein großer Aspekt in Hinblick auf die Seiteneinordnung. Die Intention der Suchanfrage hat aber nach wie vor einen sehr großen Einfluss auf das Ranking. Dadurch ist es möglich, dass eine Website immer noch einen guten Rang in Google hat (durch relevanten und thematisch passender Content), obwohl die Seitenerfahrung eher unterdurchschnittlich ist.

Was ist wenn Websites die Werte der Core Web Vitals nicht erreichen?

 

Eine Vorhersage diesbezüglich ist eher schwierig. Wichtig zu bedenken ist aber, dass der Content der Seite nach wie vor ein wichtiges Signal ist.

Was kann man aus der Search Console zum Thema Core Web Vitals entnehmen?

 

Die Google Search Console stellt den Core Web Vitals Report zur Verfügung. Dieser Report basiert auf Chrome UX Report-Daten. Der Bericht dient dazu, dass Probleme bei der Benutzererfahrung aufgedeckt werden können. Dadurch soll gewährleistet werden, dass der Core Web Vitals Report der Google Search Console mit dem Status der einzelnen Core Web Vitals auf der Website zusammenpasst.

Die Website ist schnell aber es werden im Core Web Vitals Bericht in der Search Console Warnungen angezeigt, warum?

 

Es sollte unbedingt bedacht werden, dass sich die Core Web Vitals nicht nur auf die Geschwindigkeit fokussieren, sondern zum Beispiel auch auf die visuelle Stabilität der Website. Außerdem können verschiedene Geräte, Netzwerkverbindungen und andere Faktoren bestimmen, wie eine Website geladen und dadurch vom Benutzer wahrgenommen wird.

Bei Lighthouse sehe ich keine Fehler, im Search Console-Bericht allerdings schon, warum?

 

Der Core Web Vitals Bericht zeigt die Daten der Nutzer auf realer Basis. Die Daten von Lighthouse hingegen werden mittels Labordaten erfasst, wodurch es möglich ist, dass keine Engpässe dokumentiert werden. Die Informationen in jedem Bericht weichen daher voneinander ab. Es können aber beide Berichte verwendet werden.

 

Quellen:

Search Console Help

https://web.dev/vitals/

https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html

https://www.screamingfrog.co.uk/passing-the-cwv-assessment/

https://www.seo-suedwest.de/8672-google-aendert-berechnung-des-largest-contentful-paint-lcp.html