Wie cool sind Googles Core Web Vitals?

Google hätte das Web gerne „besser“. Und wer sich dort jeden Tag aufhält, mag dem wohl zustimmen. Man betritt eine Website und wird als Erstes von einem Banner belästigt, das meist darauf setzt, dass jeder auf den farbigsten Button klickt und allen Cookies zustimmt, statt sie in den Tiefen eines unverständlichen Formulars zu untersagen. Ist das erledigt, pullert oft schon nach fünf Sekunden eine Meldung hoch, dass man der Site doch erlauben möge, einen jederzeit mit „Push-Nachrichten“ zu belästigen, wenn der Betreiber das für nötig hält. Wer glaubt, anschließend endlich in Ruhe lesen zu können, warum man überhaupt hergekommen ist, der täuscht sich erneut. Gerade hat das Auge einen Anker auf den ersten Satz geworden, schwups, schiebt sich ein Bild oder gar ein Werbebanner darüber. Je nach Programmiergeschick des Verantwortlichen kann das im schlimmsten Fall sogar mehrfach hintereinander passieren. So what? Das Web scheint mittlerweile immer nutzerunfreundlicher zu werden.

Leider ist Google daran nicht ganz unschuldig. Aber gehen wir dazu ein paar Schritte zurück. In den 2010er-Jahren wurden Smartphones immer beliebter und die Versorgung mit Internet unterwegs zwar spürbar besser, aber für die oft mit Hunderten Kilobyte geschwängerten Webseiten war das oft zu langsam. Weil Techniken und Wissen in der Breite noch rar waren bzw. ignoriert wurden, verkauften Agenturen ihren Kunden eine Kopie ihrer Website, als „M-Dot“-Webpräsenz. Dort wurden die Inhalte, oft abgestrippt und inhaltlich (aus Kostengründen) kastriert, für Smartphones vorgehalten. Das „Burger-Menü“ (die drei waagrechten Striche) entstand, der Platz war schließlich knapp. Im April 2018 verkündete Google, den Index auf „Mobile First“ umzustellen. Es sollte nur noch der Content für das Ranking herangezogen werden, den man auf dem Smartphone sehen kann. Auf die Frage, wie man denn mit den aus der Not heraus erstellten Fuddelseiten noch gut ranken sollte – auf den „normalen“ Webseiten für Computer war ja deutlich mehr vorhanden – entstand der Trend zum „responsiven Design“. Eine Art fluides Seitenlayout, das sich der Größe des Bildschirms anpasst. Erneut wurde alles umprogrammiert. Weiterhin ließ Google uns wissen, dass unsichere Websites niemand haben will und bald Seiten mit dem HTTP-Protokoll ohne das S hintenan entweder schlechter ranken würden oder einen optischen Hinweis in den Suchergebnissen bekämen. Eine Art hübscher Totenkopf, der anders aussehen mag, aber sicherlich die Suchenden vom Klicken abhält. Das Icon kam nicht, ebenso wenig wie eine spürbare Rankingveränderung nach einer (bloßen) Umstellung auf HTTPS. Es passierte, was immer passiert: Meist wurde mit der Umstellung auch feucht durchgewischt und das wirkte sich positiv auf das Ranking aus. Ursache-Wirkungs-Ungeübte bliesen „Wir ranken danach besser“ in die Welt und der Mythos war da. Alle änderten erneut ihre Technik und machten selbst statische Seiten ohne jede Interaktion „abhörsicher“.

Ach ja, weil Nutzer schnelle Webseiten mögen, proklamierte Google Speed als Rankingfaktor. Erneut machten sich die Systemtechniker auf den Weg und stellten fest, dass jetzt zwar das Design auf Smartphones und großen Browserfenstern auf Computern aus einer HTML-Datei stammt, aber diese nun oft noch fetter und damit langsamer geworden ist als die beiden Einzelversionen. Mist. O. k., aber wenn es darum geht, dass man den ersten Bildschirmteil oberhalb der sog. Falz (was man sieht, ohne zu scrollen) schnell füllen muss, dann lädt man die dicken Bildchen halt erst später und schiebt sie dann oben rein. So erzeugte man gute Speed-Metriken. Die Seite blieb zwar gleich heftig, aber der sichtbare Teil war – schwups – schnell da. Die Stoppuhr war zufrieden und nachdem sie weggeräumt war, lud man einfach fleißig nach. Das führte teils zu Layouts, über die wir uns alle wirklich ärgern. Nun könnte man das getrost der (Technik-)Kurzsichtigkeit der Unternehmen vorwerfen. Aber wer weiß, wie knapp Geld und Ressourcen in Online-Abteilungen wirklich sind, könnte auf den Gedanken kommen, dass Google mit der „Das wird ein Rankingfaktor“-Drohung vielleicht auch nicht ganz unschuldig an der aktuellen Situation sein könnte.

Und was passiert gerade? Drei neue Kennzahlen habe man sich ausgedacht, verkündete Google im letzten Jahr. Und selbstverständlich auch wieder, dass diese für das Ranking herangezogen würden. Bald. Man hat dort offenbar gelernt, dass Bitten und freundliche Aufforderungen wenig bewirken. Es muss schon die Drohung über die Rankingkeule ausgepackt werden.

Die Metriken LCP, FID und CLS waren geboren und sollen nun für die Messung der Site-Performance verwendet werden. Das sei aber alles kein Problem, denn mit dem PageSpeed-Insights-Tool (https://developers.google.com/speed/pagespeed/insights/) oder dem Chrome-Lighthouse-Tool (https://developers.google.com/web/tools/lighthouse/) von Google könne man diese Metriken jederzeit einsehen. Gerne auch neu in der Search Console. Wenn die Tools denn auch funktionieren, wie Abbildung 2 zeigt. Die Messung über Pagespeed bringt die Fehlermeldung (Ziffer 1), dass die Startseite von websiteboosting.com keine HTML-Datei sei. Aber statt die Website deprimiert in die nächste Bahnhofsmission zu bringen, sollte man sie auf jeden Fall selbst testen. Und siehe da, im Browser funktioniert sie zur gleichen Zeit bestens (Ziffer 2). Aber nicht nur das – das im Chrome-Browser enthaltene und sofort gestartete Lighthouse von Google hatte bei der Analyse keinerlei Probleme (Ziffer 3). Ein Einzelfall? Wir werden sehen.  

Um an die Messwerte von Google zu kommen, gibt es mehrere Wege. Einige zeigen wir nachfolgend beispielhaft auf.

Die Google Search Console

Dort findet man mittlerweile einen eigenen Menüpunkt für die „Core Web Vitals“. Sieht man sich diese z. B. für www.websiteboosting.com an, steigen einem Glück und gleichzeitig Tränen ins Auge. Mobil, sagt die Search Console, ist alles erste Sahne. Nichts zu meckern. Von (via Menü „Abdeckung“ sichtbar) 1.329 gültigen Seiten liegen offenbar für 505 Seiten sog. UX-Bericht-Daten für Mobile vor und 524 für den Computer. „UX-Bericht“ bedeutet, dass es sich hier um von echten Nutzern generierte Daten handelt, die Google via Chrome-Browser zu statistischen Zwecken einsammelt (Abbildung 3). Wenn Freddy Krüger und Hannibal Lecter zusammen ein Kind hätten, könnte das nicht furchteinflößender wirken als diese Messwerte. Die einzige Entspannung brächte wohl das spontane Vergleichen von Äpfeln und Birnen.  

Der Kernfehler, der hier angemahnt wird, betrifft den CLS-Wert. Ein angeblicher „CLS-Fehler: mehr als 0,25 (Computer)“ färbt 505 Seiten tiefrot ein. So kann das nicht bleiben. Klickt man auf die Beispiele – hier u. a. ein online publizierter Artikel – und löst für diese Seiten das in die Search Console eingebundene PageSpeed-Tool aus, erscheint … erneut eine Fehlermeldung (Abbildung 4).  

Messungen direkt über den Chrome-Browser

Aktiviert man das „HUD“ (Head Up Display) im Chrome-Browser, bekommt man Einblick in die vom Browser erhobenen Messdaten bezüglich der drei Kernmetriken (siehe Kasten). Also prüfen wir die angemahnten URLs manuell dort. Und siehe da, der CLS-Wert ist tatsächlich schlecht. Wow – 1.610. Ideal liegt er unter 0.1, ab 0.25 wird alles rot. Kein Wunder. Aber halt, hat sich da nicht eben was verschlechtert? Tatsächlich! Der CLS-Wert verschlechtert sich in nicht einmal 2,5 Minuten von 1.610 auf 6.455. Je länger man die Seite geöffnet hat und den Beitrag liest, desto schlechter wird der Wert (Abbildung 6; siehe Uhrzeiten und Werte ein und derselben Seite).

Die Website des Toolanbieters SISTRIX weist nach einiger Zeit der Benutzung 192 Sekunden Ladezeit aus (Abbildung 7). Die Seite ist zwar nicht rankingrelevant, aber das weiß der Chrome-Browser ja nicht und sammelt fleißig und offenbar ziemlich fehlerbehaftet Daten. In welcher Weise Google diese dann in die Domainbewertung statistisch mit einfließen lässt, ist nicht bekannt. Für einige Seiten haben wir das Spielchen weitergetrieben. Bei einem fünfstelligen LCP-Wert von 11519 wurde es allerdings langweilig und auch absurd. Eines scheinen die „Felddaten“ des UX-Berichts, aus denen Google seine Bewertungen zieht, auf jeden Fall zu sein: unzuverlässig.

Messungen über die API

Google stellt über eine Datenschnittstelle auch jede Menge, also wirklich jede Menge Metriken für die Web Vitals zur Verfügung, wie Abbildung 9 auf den ersten Blick zeigt. Dabei kommt jeder Messwert grundsätzlich zweimal vor.

Zum einen z. B. als „First-Input-Delay“ mit einer prozentualen Aufspaltung der Anteile für eine URL mit „Fast“, „Avg“, also Durchschnitt und „Slow“. Diese Werte werden zusätzlich mit dem Wort „origin“ davor nochmals übermittelt, also hier „Origin-First-Input-Delay“ und die Werte weichen durchaus voneinander ab. Was ist wohl der Unterschied zwischen beiden Metriken? Dazu schweigt sich Google aus. Offenbar gibt es noch nicht einmal eine vollständige Dokumentation dazu. Die normalen Vitals werden natürlich erklärt. Aber was es mit den anderen Daten auf sich hat, lässt sich nicht ermitteln bzw. bringt zumindest keine Suchtreffer in der hauseigenen Suchmaschine (Abbildung 8).  

Sieht man sich die Werte in der Tabelle Abbildung 9 genauer an, wird es noch kruder. Die (anonymisierten) URLs sind für beide Datencluster (mit und ohne „origin) identisch. In der oberen Leiste fällt auf, dass die Werte für vier völlig unterschiedliche URLs identisch sind. Das ist ganz sicher kein Zufall. Nur für drei URLs liefert Google offenbar echte, sprich individuelle Werte. Die untere Leiste, bei der die Metrikbezeichnungen von Google vorne ein „Origin“ zeigen, sind sogar komplett identisch! Jetzt könnte man glauben, die „Origin“-Werte seien einfach nur die Startseitenwerte, die für alle gleich ausgespielt werden. Weit gefehlt, denn unten haben alle Zeilen identische Zahlen wie oben die Zeilen 3–6. Die Startseite hat also einen FCP von 1063, aber einen Origin-FCP von 1457. Welche ist denn nun der richtige? Man fühlt sich, als sei man kognitiv zu früh abgebogen. Kleiner Stolperstein am Rande: Da der FCP ansonsten mit drei Nachkommastellen ausgegeben wird, hier aber vierstellig ist, wurde wohl vermutlich einfach nur der Punkt nach der ersten Ziffer vergessen oder weggelassen. Kurzum: Die Qualität der Daten wirkt wie mit Leim beschmiert und durch einen Flohmarkt gezogen. Noch mal auf den Punkt: Nur wenn man wie hier mehrere Daten für mehrere URLs gleichzeitig abruft, fallen diese Inkonsistenzen auf. Ruft man nur einen Einzelwert über irgendein Tool von Google ab, sieht der normal prüfende Webverantwortliche keinen Widerspruch. Er wird den Wert für valide halten. Wer kommt schon auf die Idee, dass gerade Google hier einen so massiven Datenschluckauf hat?

Rein und wieder raus aus den Kartoffeln

Bisher kam die Tabelle in Abbildung 10 zum Einsatz für die Ampelfarbvergabe in Grün, Gelb und Rot. Vor Kurzem hat Google eine Anpassung vorgenommen. Die Grenzen werden jetzt stattdessen mit „kleiner-gleich“ angegeben. So konnte es durchaus dazu kommen, dass sich Farben veränderten, der Wert jedoch nicht.

Und kurz vor Redaktionsschluss erreicht uns die nächste Meldung. Die Dokumentation des CLS-Wertes wurde auf den Google-eigenen Seiten offenbar geändert. Auf den deutschen Seiten unter (https://support.google.com/webmasters/answer/9205520?hl=de) steht zu lesen:

„CLS (Cumulative Layout Shift): Gibt an, wie sehr sich das Seitenlayout während der Ladephase verschiebt. Er wird mit 0 bis 1 bewertet, wobei 0 für keine Verschiebung und 1 für die stärkste Verschiebung steht.“

Auf der internationalen Version (https://support.google.com/webmasters/answer/9205520?hl=en) wird nun alles ganz anders erklärt:

„CLS (Cumulative Layout Shift): CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. The score is zero to any positive number, where zero means no shifting and the larger the number, the more layout shift on the page.“

Während es in der alten Version hieß, die Verschiebung werde während der Ladephase gemessen, erklärt man nun, es werde die „entire lifespan of the page“ verwendet. Und welche „Lebensdauer“ hier gemeint ist, darüber kann man nur spekulieren. Es könnte die wirklich gesamte Lebensdauer, seit die Seite erreichbar ist, mit allen Aufrufen oder aber auch die Besuchszeit eines einzelnen Besuchers gemeint sein, also so lange die Seite in Chrome betrachtet wird oder einfach nur geöffnet ist.

Hey Google – so können wir nicht arbeiten!

Wir haben noch einen ganzen Eimer voller weiterer Beispiele, wie sich die Vital-Metriken offenbar willkürlich verändern. Ruft man z. B. immer ein und dieselbe URL via API im Abstand von zehn Sekunden auf, erhält man Score-Werte von 40 bis 80 (von jeweils 100). Man muss nur lange genug abrufen, dann erhält man früher oder später einen Wert, der von Gelb auf Grün oder von Rot auf Gelb springt. Abbildung 11 zeigt dieses Phänomen an einem Beispiel über die Zeit, aufgezeichnet von der SISTRIX-Toolbox. Das Layout und damit die Grundlage für die CLS-Berechnung hat sich bei der betroffenen Domain in diesem Zeitraum nicht geändert. Diese unzuverlässig schwankenden Daten mögen ja ganz tief im technischen Hinterzimmer ihre Begründung haben – sehr wahrscheinlich sogar. Aber sie sind für den normalen Webbetreiber so nicht durchschaubar.  

Im Januar 2021 hat Google über web.dev/better-layout-shift-metric/ zu Feedback aufgerufen, weil die Berechnung des CLS-Wertes wohl diverse Probleme macht. Reichlich spät für eine im Mai (!) angekündigte Verwendung für das Ranking.

Die neueste Verlautbarung ist nun, dass die Auswirkungen der Core Vitals nur sehr gering ausfallen werden und weiterhin die Qualität des Inhalts dominant wichtig sei. Also same procedure as every year? Wie bei HTTPS, Speed und Mobil? Starker Druck über die Ankündigung als Rankingfaktor, Verlängerung der Einführung als Rankingfaktor, dann Abmilderungsaussagen bezüglich der Wirkung und am Ende nach dem Eingang in die Bewertung: Nichts oder fast nicht zu spüren?

Wir müssen es uns fast wünschen! Zum einen sind die Werte der Vitals objektiv gesehen noch immer zu intransparent, volatil und machen keinen vertrauenerweckenden Eindruck. Wie soll man optimieren und prüfen, ob und was man erreicht hat, wenn die Werte so krass schwanken? Wenn es Zufall ist, zu welcher Tagessekunde man auf den Button „Analyse“ drückt? Wenn durch bloßes Betrachten einer Seite Werte im Browser entstehen können, die jeden gemittelten Wert spürbar hin zum Schlechteren schieben können und oft in absurde Höhen? Darf man Googles Messungen vertrauen, wenn sie über 16 Sekunden Ladezeit für nur ein Element (allerdings das größte) der Seite herauskalkulieren und der Gesamtindexwert pro Klick von 15 auf über das Doppelte auf 33 (Abbildung 12) innerhalb von nur drei Minuten hin und her schwankt? Selbst Amazon besteht den Core-Web-Vital-Test nicht. Wie soll Kalle Klein mit seinem Shop je besser sein als diese Verkaufsgiganten mit ihren Armeen von Systemtechnikern? Langsam, aber sicher gehen einem die Möglichkeiten aus, noch Begeisterung zu zeigen. Man fühlt sich, als müsste man ein chinesisches Kreuzworträtsel lösen, während man gleichzeitig von einem Tiger gefressen wird.