Die neuen Kennzahlen der Ladezeit, die Core Web Vitals, sollen jetzt also ab Juni 2021 ein Rankingfaktor werden. Die Herausforderungen sind erheblich und das Messen, Bewerten und Optimieren der Kennzahlen bereitet vielen Kopfschmerzen. Die Orientierung der Ladezeit an nutzerorientierten Zahlen ist eigentlich absolut sinnvoll und ein echtes Novum. Wie man Websites vorbereiten sollte und warum man die „CrUX“-Zahlen dafür benötigt, zeigt dieser Artikel anhand zahlreicher Beispiele.
In der letzten Ausgabe 67 waren die Core Web Vitals nicht zum ersten Mal Thema in der Website Boosting. Die drei wichtigsten Kennzahlen Largest Contentful Paint (LCP), First Input Delay (FID) und Cumulative Layout Shift (CLS) wurden auch schon beschrieben und deren Kenntnis wird vorausgesetzt. Sie werden detailliert in der Google-Hilfe zur Search Console unter einfach.st/gwma3 erklärt.
Um zu verstehen, wie Google intern diese Daten erhebt und für das Ranking berücksichtigt, muss man sich mit den Chrome-User-Experience-Daten, kurz CrUX, intensiver beschäftigen, denn diese sind laut Google maßgeblich für die Bewertung. Die folgenden Ergebnisse aus einer aktuellen Core-Web-Vitals-Studie sind jedenfalls erkenntnisreich.
Google misst die Core-Web-Vitals-Daten mit den echten Nutzern von Chrome. Es gibt keine Vorgabe wie beim Speed-Index, dass eine 3G-Datenverbindung simuliert wird. Websites, die mehr Desktop-Besucher haben, haben auch mehr Nutzer, bei denen diese Kennzahlen vergleichsweise gut sind. Websites, die überwiegend mobile Nutzer haben, werden es schwerer haben, die Kennzahlen einzuhalten. Websites, die Nutzer aus Ländern mit langsamem Internet haben, werden ebenfalls schlechtere Werte erzielen.
Fragen, wie sich Änderungen an der Website oder bestimmte Optimierungsmaßnahmen auswirken, lassen sich stets damit beantworten: Es kommt allein darauf an, wie sich die Nutzererfahrung in Chrome dadurch ändert. Das Problem: Diese CrUX-Daten kann man nicht zu einem beliebigen Zeitpunkt selber messen.
Die CrUX-Daten werden aus den letzten 28 Tagen gemittelt. Der Test gilt als bestanden, wenn 75 % der Nutzer den entsprechenden Grenzwert einhalten. Google stellt die Daten von Websites, zu denen ausreichend CrUX-Daten vorliegen, in einer großen Big-Query-Datenbank im Netz unter developers.google.com/web/tools/chrome-user-experience-report/bigquery/getting-started bereit. Grundsätzlich kann man grob sagen: Hat eine Website weniger als 1.000 Besucher pro Monat, liegen keine Daten vor. Dies sind aber Erfahrungswerte aus vielen erstellten Berichten.
Aktuell sind etwa 8 Millionen „Origins“ in der Datenbank. Unter Origins versteht Google Domains, die Nutzer im Browser in der Adresszeile sehen, wenn sie eine Website aufrufen. In dieser Datenbank liegen nur aggregierte Werte pro Monat und gemittelt für alle aufgerufenen Seiten. Werte zu einzelnen Seiten kann man daraus nicht auslesen. Google bezeichnet diese Daten als „Felddaten“, während Daten aus Analysetools als „Labordaten“ benannt werden. Abbildung 1 zeigt die Kennzahlen für die Origin developer.google.com. Man sieht hier schon, dass selbst Google Probleme hat, die Kennzahlen zu erfüllen.
Die Informationen rund um Core Web Vitals sind teilweise verwirrend und widersprüchlich. Google rückt immer wieder mit neuen Details heraus und die Art und Weise, wie die Kennzahlen ermittelt werden, kann sich ändern. Helfen können hier nur konkrete Hilfestellungen, wie man die Daten ermittelt und bewertet.
Es ist weithin bekannt, dass Google diese Daten auch in der Search Console anzeigt. Diese sind „aktuell“ und keine über 28 Tage aggregierte Daten. Zudem fasst Google Seiten, die sich ähneln, in Gruppen zusammen, was in der Google-PageSpeed-API-Dokumentation unter einfach.st/speed7 beschrieben ist. Was unter „aktuell“ zu verstehen ist, wird von Google aber nicht genauer spezifiziert.
Folgendes Beispiel zeigt eine typische Änderung der Werte in der Search Console. Dies bedeutet aber nicht, dass exakt an dem Tag eine Änderung an der Website diese neuen Werte verursacht hat. Zudem darf man die dort angegebenen Seiten (URLs) nicht so verstehen, dass das Problem nur bei diesen Seiten besteht! Man muss sich also die URLs genauer ansehen und verallgemeinern.
Tatsächlich werden über die PageSpeed-API bei unterschiedlichen URLs exakt die gleichen Werte ausgegeben, so wie es in der Ausgabe 67 beschrieben wurde. Denn Google sieht diese Seiten als „ähnlich“ an und gruppiert sie. Das bedeutet nicht, dass alle URLs mit Problemen in der Search Console gelistet werden. Daher muss Google diese Zahlen für viele Seiten schätzen und Seiten zusammenfassen und gruppieren. Wie das genau geht, wird aber von Google nicht beschrieben. Damit muss man leider irgendwie umgehen.
Die PageSpeed-Insights-API liefert auch Werte für die CrUX-Zahlen aus, also Felddaten, denen „origin“ vorangestellt wird. Es ist aber nachvollziehbar, dass Google gar nicht für alle Seiten im Web brauchbare Felddaten hat, erst recht nicht als tägliche Zahlen. Die Ergebnisse in der Search Console darf man daher nur als Anhaltspunkte für weitere Analysen heranziehen wie auch die CrUX-Daten.
Google crawlt alle Seiten mobil, erfasst beim Crawlen aber keine CWV-Daten. Das macht nur Chrome. Deswegen hat Google auch CWV-Daten für Mobile, Tablet und Desktop getrennt. Aus diesen Daten werden die CWV-Daten dann auch für einzelne bzw. Gruppen von Seiten generiert. Aus den laufenden CrUX-Daten werden dann tägliche Updates erzeugt, die man in den PageSpeed-Insight-Berichten sehen kann.
Schon das Tool Lighthouse analysiert auf Basis einer 3G-Fast-Verbindung, daher ist man auf der sicheren Seite, wenn man sich für Analysen an dieser mobilen Verbindung orientiert. Wer dort die Kennzahlen einhält, wird das sehr wahrscheinlich auch bei schnellerer Datenverbindung tun. Doch Vorsicht: Einzelne Beispiele zeigen, dass bestimmte Werte beim Desktop deutlich schlechter ausfallen können. Dazu mehr später.
Google führt unter einfach.st/cwv9 ausführlich aus, wie die Schwellenwerte und auch die Grenzwerte zur Messung und Bewertung der Kennzahlen entstanden sind. Zudem wird genau beschrieben, warum man als Grenzwert für die Erfüllung der Kennzahlen die Schwelle von 75 % definiert hat.
Dass die meisten Websites derzeit die CWV-Kennzahlen nicht erfüllen, also bei den drei wichtigsten Kennzahlen die 75 %-Grenze einhalten, soll nicht bedeuten, dass man das Problem nicht zeitnah angehen sollte. Dass sich die Platzierungen dadurch verbessern, ist zunächst nur eine „Androhung“ von Google. Wie stark sich das auswirken wird, weiß niemand, aber in jedem Fall lohnt es sich immer, die Nutzererfahrung zu verbessern.
Hier ein paar Beispiele zur Einhaltung der Kennzahlen:
Allen Untersuchungen gemein ist, dass die Ermittlung der Daten nicht genau offengelegt wird. Tatsache ist auch, dass dies reproduzierbar und wissenschaftlich belegbar nicht möglich ist. Denn die offengelegten Daten der CrUX-Berichte sind aggregierte Werte, die man verlässlich heranziehen kann, die aber nicht aussagen, welche Seiten/URLs es betrifft. Zudem sind es gemittelte Werte über alle Besucher, was die Aussagekraft dieser Zahlen erschwert.
Google hat im April 2021 unter einfach.st/chromeux3 die folgenden Zahlen veröffentlicht. Die Tabelle zeigt zusätzlich Daten der Core-Web-Vitals-Studie der Top 500 Websites weltweit:
| LCP | FID | CLS | Alle drei eingehalten |
Alle Origins | 47,99 % | 89,46 % | 45,99 % | 21,98 % |
Top 500 Origins | 56,7 % | 92,3 % | 54,5 % | 26,4 % |
Laut Google erfüllen also 22 % aller Origins/Websites alle drei Kennzahlen. Letztlich ist es aber nicht aussagekräftig, wie viel Prozent Ihrer Mitbewerber die Kennzahlen erfüllen. Entscheidend ist, wie man die verschiedenen Zahlen analysiert, auswertet, bewertet und optimiert.
Die CWV-Grenzwerte wirken zunächst sehr ambitioniert. Man muss aber bedenken, dass Google stets die „Origins“ bewertet, sprich die URL von Domains, die im Browser in der Adresszeile steht. Weiterleitungen von HTTP zu HTTPS fallen da raus, wie auch Weiterleitungen von ohne www. zu mit www., und die Datenverbindung liegt im Schnitt deutlich höher als bei 3G.
Das Problem ist, dass Tools keine Felddaten wie in den CrUX-Daten vorhanden ermitteln können. Teilweise werden die Daten aber ausgegeben. Es ist im wahrsten Sinne eine „Crux“, die Abkürzung passt wie die Faust aufs Auge. Die Tools sind weitgehend bekannt und werden daher folgend nur zu Besonderheiten bezüglich der CrUX-Daten untersucht.
Beim Tool PageSpeed Insights ist zu beachten, dass es eine mobile und eine Desktop-Version gibt (siehe in Abbildung 3 links oben unter 1). Die mobile Variante simuliert eine mobile 3G-Fast-Datenverbindung mit 1,6 MBit/s, die Desktopversion eine schnelle Datenverbindung mit 5 Mbit/s.
Grundsätzlich ist zu beachten, dass die CrUX-Felddaten aus dem Mittelwert der letzten 28 Tage bestehen und nur einmal monatlich generiert werden, während die Werte der Felddaten innerhalb der PageSpeed-Ergebnisse unter Punkt 5 täglich aktualisiert werden. Die Zahlen bleiben auch bei Analysen am selben Tag gleich, solange man die Zeitverschiebung und den Standort des Servers berücksichtigt.
Die hier ausgegebenen Werte sind für die eingegebene URL, können also für einzelne Seiten ermittelt werden. Allerdings sagt Google auch, dass diese Werte geschätzt sind und sich aus den Kennzahlen ähnlicher Seiten der Website ergeben. Es ist also wichtig zu wissen, dass man diese Zahlen nicht als absolut gesichert interpretieren darf. Diese Daten erscheinen letztlich auch in der Search Console und sind entsprechend zu interpretieren.
Ein weiteres Problem ist die Analyse bei Sprach- bzw. Länderweichen, siehe dazu den Punkt 2 und 4 in Abbildung 3 am Beispiel von zalando.de. Schon seit dem früheren PageSpeed-Service von 2015 empfahl Google, in solchen Fällen auf eine IP-Adresse auszuweichen, was auch heute noch geht (siehe Bild rechts), oder einen URL-Parameter zu implementieren, der sicherstellt, dass die Weiche nicht greift.
In der Regel greifen die Server aus den USA auf die Websites zu. Zwar kann man die Ladezeit auch über die IP-Adresse messen, allerdings werden keine CrUX-Felddaten ausgegeben, da es zu den IP-Adressen keine „Origin“-Daten gibt. Zudem erreicht man über die IP-Adresse beim Beispiel Zalando die Auswahlseite für Land und Sprache und nicht den Shop selbst. Daher lässt sich das Problem meist nur über URL-Parameter lösen, die man serverseitig implementiert, wenn man solche Weichen bei Analysen umgehen möchte.
Der angezeigte „Leistungsfaktor“ unter Punkt 3 in Abbildung 3, eine Punktzahl von 0-100, kommt von der Lighthouse-Analyse, die in PageSpeed implementiert ist. Die genaue Berechnung zeigt Abbildung 5. Die Berechnung hat sich immer wieder geändert, Werte sind daher über die Zeit nur bedingt vergleichbar.
Die Felddaten zu LCP und FID unter 6 und 7 in Abbildung 3 sind hilfreich, aber die angegebenen Summenwerte 1,9 s und 89 ms entsprechen nicht dem Wert, den 75 % der Nutzer erzielen. Tatsächlich gibt Google in der Dokumentation dazu an, dass hier für den FCP-Wert der 90. Prozentrang angegeben wird und bei FID der 95. Prozentrang. Das wird damit begründet, dass man die schlechteste Nutzererfahrung wiedergeben möchte. Das Ziel soll sein, dass selbst unter schwierigsten Geräte- und Netzwerkbedingungen ein Mindeststandard für die Leistung erfüllt wird. Dennoch bleibt die Frage, warum man nicht die Werte heranzieht, die für die Erfüllung der Kennzahlen gelten, nämlich 75 %.
PageSpeed Insight liefert auch konkrete Vorschläge zu Optimierungsmaßnahmen, die aus dem Tool Lighthouse stammen. Diese sind hilfreich und helfen bei der Optimierung. Die Tücken stecken aber auch hier im Detail.
Der Leistungsfaktor schwankt und hängt natürlich davon ab, ob man Mobile oder Desktop wählt. Zusätzlich wird aber auch die CPU-Leistung angepasst, bei mobiler Messung wird sie geviertelt. Dies begründet Google damit, dass man dadurch näher an realistischen Zahlen von „Low-End Mobile“-Geräten sei. Detailliert erklärt wird dies unter einfach.st/guthub81.
Lighthouse-Messungen können und werden nicht nur an verschiedenen Geräten unterschiedliche Ergebnisse liefern, sondern auch am gleichen Gerät. Chrome ermittelt die vorhandene CPU-Leistung bei jeder Analyse und speichert einen Benchmark-Index für das verwendete Gerät. Die Tabelle für typische Werte unter einfach.st/github82 zeigt, dass sich der Index durchaus maximal um den Faktor 2 zwischen älteren Desktop-Geräten und sehr schnellen unterscheiden kann. Dies hat sich auch in der Praxis bei Tests gezeigt. Der Einfluss auf die Kennzahlen dürfte aber deutlich geringer sein.
Wer einen Lighthouse-Bericht erstellt, muss wissen, dass die Ergebnisse von der Leistung und Auslastung eines Geräts abhängen, von der aktuellen Internetverbindung, den Schwankungen in der CPU-Last und der Last auf dem Server der untersuchten Website, was auch Google detailliert unter einfach.st/github83 beschreibt.
So werden selbst A/B-Tests auf untersuchten Seiten genannt, die Testergebnisse beeinflussen können. Unter einfach.st/lhcpu gibt es einen Kalkulator (Abbildung 6) , mit dem man die CPU-Leistung an Durchschnittswerte im lokalen Chrome anpassen kann.
Lighthouse ist mittlerweile in die Chrome Developer Tools eingebunden. Es gibt hierfür ab Chrome-Version 88 einen eigenen Tabreiter, mit dem man in Chrome Analysen machen kann.
Website-Boosting-Lesern wird das Analyse-Werkzeug Chrome Developer Tools bekannt sein. Sie können es in Chrome durch Drücken der F12-Taste öffnen. Es beinhaltet nicht nur Lighthouse, sondern unter Network > Coverage lässt sich aufzeigen, zu welchem Teil Ressourcen überhaupt benötigt werden. Bei der Optimierung von Websites ist dies neben weiteren Analysen in diesem Tool ein unverzichtbares Instrument.
Eine Auswertung der Web Vitals ist unter Performance > Web Vitals enthalten. Dort kann man detailliert die Messpunkte der Web Vitals beim Seitenaufbau identifizieren.
Vom einem Entwicklungsleiter von Google stammt diese Erweiterung, die man vom Chrome-Store unter einfach.st/chrome343 installieren kann. Sie misst für die aufgerufene Seite die drei wichtigen Kennzahlen LCP, FID und CLS. Bei FID ist das Problem, dass es nur für Klicks funktioniert, bei denen der Nutzer auf derselben Seite bleibt. Für Klicks zu einer anderen Seite kann der Wert nicht ausgegeben werden.
Allerdings muss hier erwähnt werden, dass eine Messung des FID-Wertes im Labor wie bei diesem Tool keine vergleichbaren Messwerte ergibt. Google misst die Werte mit echten Nutzern in Chrome. Labormessungen geben daher nur Anhaltspunkte, wo sich Flaschenhälse befinden können.
Auch dieses bekannte Tool basiert auf den gleichen Algorithmen von Google, liefert aber noch andere Daten und Auswertungen, die helfen, Probleme zu identifizieren. Zukünftig werden die Felddaten soweit verfügbar mit ausgegeben wie in Abbildung 9. Die dort mit angegebenen 75 % Perzentilwerte (p75) geben den gemittelten Wert für die 75 % besten Messwerte wieder. Schaut man sich den Wert bei diesem Beispiel zu CLS an, stellt sich aber die Frage, warum der p75-Pfeil am rechten Anschlag der Grafik für CLS steht.
Die Kennzahlen aller Top-500-Seiten standen bereits in der Tabelle weiter oben. Da viele große Websites Besucher aus der ganzen Welt haben, ist es technisch schwierig, sehr gute CWV-Werte zu erzielen. Google erfüllt alle CWV-Kennzahlen für alle Google.xy Origins mit Bestwerten. Dass Google aber auch selbst bei den Kennzahlen Probleme hat, war schon in Abbildung 1 zu sehen.
Amazon ist in den Top-500-Websites 10-mal mit Länderdomains vertreten, erfüllt aber mit keiner alle Kennzahlen. Lediglich amazon.cn nimmt diese Hürde, dieser Shop sieht allerdings auch völlig anders und sehr verspielt aus.
Die Zahlen von ok.ru sind ebenfalls auffallend. Es gibt Zahlen für ok.ru und www.ok.ru. Die Ursache liegt darin, dass zum Start des Dienstes 2014 zunächst die Variante mit www gewählt wurde, 2015 wechselte man zu ok.ru ohne www. Da es aber noch viele Backlinks im Netz zur Variante mit www gibt und auch Treffer in der Google-Suche, fallen in Chrome noch genügend Nutzerdaten an für die Origin www.ok.ru. Man sollte also sicherheitshalber prüfen, ob es in den CrUX-Daten auch Origins der eigenen Website zu anderen Subdomains gibt.
Alibaba und Aliexpress zeigen auch Auffälligkeiten. Obwohl beide Websites vom selben Unternehmen für verschiedene Zielgruppen sind, wird bei Aliexpress eine separate mobile Website eingesetzt. Daher gibt es für alle mobilen Varianten in verschiedenen Sprachen separate Origins, in Deutschland ist es die m.de.aliexpress.com. Die CrUX-Daten weisen dabei auch nur Daten für Smartphones aus.
Der Fall eines Energieversorgers zeigt, dass die Kennzahlen ausschließlich durch Nutzerdaten erhoben werden. Wenn Smartphone-Nutzer zur Eingabe von Zählerständen in den Keller gehen, zeigen sich Probleme. Selten sieht man so stark unterschiedliche LCP-Werte zwischen Desktop und Mobile wie in diesem Fall (Abbildung 10).
Der Fall zajac.de zeigt, dass Kennzahlen beim Desktop deutlich schlechter sein können als bei Smartphones. Die sogenannte Strip-View-Ansicht in den webpagetest.org-Ergebnissen zeigt, dass ein „Shiften“ in der Darstellung auf dem Desktop flächenmäßig deutlich größer sein kann (Abbildung 11) als auf dem Smartphone. Daher ergeben sich bei zajac.de deutlich schlechtere CLS-Werte auf dem Desktop.
Wenn man beim Desktop ganz genau hinsieht, erkennt man, dass die Navigation zunächst umbricht, zwei Elemente werden in der zweiten Zeile dargestellt, kurz danach rutschen diese nach oben. Abgesehen von der Tatsache, dass die Navigation zu viele Elemente hat und diese mobil kaum lesbar, geschweige denn antippbar sind, ist das Problem in diesem Fall schnell identifiziert.
Weitere nützliche Informationen in den CWV-Daten sind die „Notification Permissions“. Websites können dem Besucher über die Web Notification API in einem Layer anbieten, dass er Nachrichten auf seinem Desktop angezeigt bekommt. Diese Push-Nachrichten sind für Marketer interessant, kann man doch damit den User auch erreichen, wenn er nicht die Website besucht. Allerdings empfinden nicht wenige diese Benachrichtigungen als Belästigung. Die Daten zeigen, wie Nutzer diese Benachrichtigungen beantworten.
Im Bericht „Notification Permission“ kann man hier am Beispiel der Origin www.tz.de sehen, wie Nutzer diese Benachrichtigungen wie oben annehmen.
Die Ergebnisse sind hier relativ typisch, aber etwas schlechter als die durchschnittlichen Werte.
Weitere nützliche Daten kann man aus den CrUX-Zahlen lesen: die tatsächliche Datenverbindung aller Besucher (2G Slow, 2G, 3G, 4G) und die Geräte-Nutzung der Besucher auf der Website.
In der nächsten Ausgabe werden diese Erkenntnisse im Kontext von Mobile Only analysiert. Auch durch den „Mobile First“-Claim seitens Google hat sich auf den mobilen Websites viel getan. Neben der Herausforderung der CWV gibt es bei zum Beispiel bei Amazon erste Versuche der individualisierten User Experience, eine völlig neue Dimension personalisierter Webseiten.
Die CrUX-Zahlen sind wichtig, sie bieten weitere Einblicke und sind Googles zukünftig genutzte Daten für das Ranking. Klar wird aber auch, dass die vorhandenen Daten zu 8 Millionen Origins nur einen kleinen Bruchteil des Internets abdecken und man ernsthaft fragen muss, wie man daraus einen Rankingfaktor basteln will. Allerdings sollte man es so sehen: Die Nutzererfahrung der eigenen Website zu verbessern, ist stets nachhaltig für mehr Umsatz, Kontakte und Conversions. Allein das wird sich positiv auswirken, letztendlich auch immer auf die Platzierungen bei Google.
Sie können unter einfach.st/cyberpromote einen kostenlosen CrUX-Bericht für Ihre Website anfordern, der den CrUX-Berichten in diesem Artikel gleicht. Die vollständige Core-Web-Vitals-Studie können Sie unter einfach.st/cyberpromote2 anfordern.