Aktuell beobachte ich, dass viele Webmasterïnnen sich erhebliche Sorgen um die von Google eingeführten Core Web Vitals machen. Diese Gruppe von Daten umfasst spezielle Informationen über die Benutzbarkeit (Usability) einer Website. Zunächst sollten diese Daten schon im Frühjahr als Rankingfaktoren mit über die Positionierung in Google-Suchergebnissen bestimmen, dann wurde es auf den Sommer verschoben. Mittlerweile sollte die Umstellung aber gelaufen sein.
Um die Core Web Vitals ist eine Panik ausgebrochen, die ich mit der Umstellung auf Mobile First oder gar mit der Umsetzung der DSGVO vergleichen möchte. Das halte ich zunächst einmal grundsätzlich für unnötig: bei schon bisher über 200 Ranking-Faktoren werden diese paar weiteren Faktoren kaum einen merklichen Effekt haben. Aber leider hat das Konzept der Core Web Vitals auch weitere technische und konzeptionelle Schwächen, die teilweise absurde Auswüchse haben. Während die Grundidee gut ist, ist die Umsetzung aus meiner Sicht ein Rohrkrepierer, ähnlich wie AMP.
Was sind die Core Web Vitals?
Die Core Web Vitals umfassen sechs Messdaten:
First Contentful Paint: Die Zeit vom ersten Aufruf der Website bis zur Darstellung sinnhaltigen Inhalts (Text, Bilder…), also einer für Benutzerïnnen verarbeitbaren Information.
Speed Index: Eine Zahl in Sekunden bis zur Darstellung des Inhalts der Website.
Largest Contentful Paint: Die Zeit, die benötigt wird, um das in Bytes größte Inhaltselement darzustellen, meist ein Bild.
Time to Interactive: Die Zeit, die vergeht, bis Besucherïnnen der Website nach dem Aufruf mit der Website vollständig interagieren können.
Total Blocking Time: Die Zeit, die vergeht, während der Browser nicht sichtbare Informationen vom Webserver erhält (z.B. Skripte, CSS-Dateien), bevor er etwas darstellt.
Cumulative Layout Shift: Ein Wert, der Bewegungen und Verschiebungen von Inhalten auf der Website misst. Er hat keine Einheit, also weder Zeit noch Byte, und ein willkürlich festgelegter Grenzwert von 0,25 soll nicht überschritten werden.
Insbesondere der letzte Wert, Cumulative Layout Shift, ist schwer zu begreifen, denn Zeiten und Dateigrößen kann man noch relativ gut verstehen und ggfs. beeinflussen. Wenn jedoch dieser Wert nicht stimmt, ist oft Detektivarbeit angesagt, wenn man hier bessere Ergebnisse erzielen möchte. Dieser Wert ist auch der einzige, der nicht durch längst bestehende und bekannte Rankingfaktoren abgedeckt ist, da Ladezeit und Datenmenge schon seit langem im Fokus sämtlicher Optimierungen stehen. Und leider ist er auch eine schlecht funktionierende Black Box: niemand weiß, wie die Daten ermittelt werden, und bei der Prüfung schlechter Ergebnisse zeigt sich oft, dass völliger Unsinn bemängelt wird. Dazu später mehr.
Core Web Vitals in der Google Search Console
In der Google Search Console werden diese Metriken seit neuerem mit eigenen Menüpunkten geehrt (siehe nebenstehend). Die drei Menüpunkte überlappen sich inhaltlich, was der Übersichtlichkeit nicht zuträglich ist:
Verhalten von Seiten enthält sogenannte „Signale für die Nutzerfreundlichkeit einer Seite“. Auf drei Karten werden Core Web Vitals, Nutzerfreundlichkeit auf Mobilgeräten und HTTPS abgehandelt. Die ersten beiden beziehen sich also auf die Inhalte der weiteren Menüpunkte.
Betreiberïnnen kleinerer Webseiten werden hier meist feststellen, dass ihnen gar nichts angezeigt wird. Stattdessen steht dort nur „Deine Website hat nicht genügend Nutzungsdaten“. Dazu unten mehr.
Core Web Vitals enthält eine Übersicht mit jeweils einem Gesamtwert für die gemessenen Daten für die mobile Ansicht und die Desktopansicht. Auch hier ist es gut möglich, dass eine oder beide wegen ungenügender Nutzungsdaten nicht angezeigt werden.
Der dritte Menüpunkt, Nutzerfreundlichkeit auf Mobilgeräten, ist schon länger vorhanden und nicht Gegenstand der heutigen Betrachtung.
So wenig deutliche Inhalte diese Menüpunkte auch anzeigen, wenn überhaupt, so können sie doch zu starker Verwirrung führen, wenn sie umfassende Probleme anzeigen.
Core Web Vitals in Page Speed Insights
In den Page Speed Insights von Google tauchen die sechs oben beschriebenen Werte an prominenter Stelle auf:
In diesem Beispiel sind alle Werte grün, mäßige Werte würden gelb und schlechte Werte rot eingefärbt. Die Ergebnisse derselben Website werden nach mobil und Desktop unterschieden. Bei den mobilen Ergebnissen werden die schlechteren Ladezeiten mobiler Verbindungen zugrunde gelegt, weshalb das Ergebnis für mobil häufig schlechter ausfällt als für Desktop.
Absurde Messprobleme bei den Core Web Vitals
Leider sind manche Messungen schlecht nachzuvollziehen, vor allem der Cumulative Layout Shift, der völlig willkürlich wirkt. Eigentlich soll der Cumulative Layout Shift vor allem dort schlechte Werte erzielen, wo die Inhalte sich durch später dazwischen geschobene Elemente verschieben, so dass der Lesefluss unterbrochen wird oder ein anklickbares Element plötzlich woanders hin hüpft. Auf vielen größeren Websites, die stark mit Werbung versetzt sind, kann man das häufig beobachten, und es ist in der Tat sehr frustrierend. Insofern ist es eigentlich eine gute Idee, eine aufgrund dieser Verschiebungen schlecht nutzbare Seite im Ranking etwas herunterzustufen. Aber die von mir bisher beobachteten Beispiele von Cumulative Layout Shift auf von mir betreuten Seiten sind durchweg entweder minimal oder gar nicht wahrnehmbar, und trotzdem erreichen sie bereits kritische Werte.
Für meine Website wurde zum Beispiel zunächst ein CLS-Wert leicht schlechter als 0,25 ermittelt. Ich habe mich auf die Suche gemacht, woran das liegen mag, und habe schließlich das schuldige Element entdeckt: es waren die links und rechts bei Blogbeiträgen eingeblendeten Pfeile zum Blättern zwischen den Beiträgen. Sie wirkten sich auf den CLS-Wert der gesamten Website aus, obwohl sie überhaupt nur auf Blogbeiträgen angezeigt wurden und auch dort gar keine sichtbaren Verschiebungen verursachten. ich habe sie entfernt, und schon ist CLS grün. Allerdings würde bei einem Blog, bei dem diese Pfeile einen Mehrwert darstellen, die Usability durch diese Korrektur sogar verringert.
Vergleichbare Gründe lagen anderswo vor: ein Parallax-Hintergrundbild, das sich an den Viewport anpasst, ein fixiertes Menü, das sich beim Scrollen verkleinert… Wenn solche Einzelelemente bereits den Wert auf mehr als 0,25 heben, was für Werte erreichen dann solche Seiten, bei denen sich wirklich alles mögliche ständig verschiebt?
Ich habe das gleich bei der ersten sich bietenden realen Gelegenheit getestet. Bei der Lektüre eines Artikels auf spiegel.de am Desktop wurde plötzlich der Absatz, den ich gerade las, um mehr als seine eigene Höhe verschoben, weil sich Werbung dazwischendrängte. In solchen Fällen geht immer die Sucherei los: wo war ich gerade? Aber Page Speed Insights bescheinigt genau dieser Seite mobil einen Cumulative Layout Shift von gerade mal 0,16 und am Desktop sogar nur 0,08. Dazu kann man nur sagen: 6, setzen. Ziel absolut verfehlt.
Man muss darüber hinaus bei der Optimierung auch bedenken: entweder wird das CSS, welches ein Element formatiert, vor dem Element geladen, dann blockiert es das Rendering. Oder man lädt es danach, dann wird es das Element in der Regel ein wenig verschieben. Man kann eben nicht auf allen Hochzeiten tanzen.
Ein besonders absurder, weiterer Messfehler betraf meine Website: obwohl die gesamte Website ausschließlich über https erreichbar ist und so auch seit Jahren in der Google Search Console angemeldet ist, behauptete die GSC im Bereich „Verhalten von Seiten“ steif und fest, keine meiner Seiten sei über https erreichbar. Offensichtlicher Unsinn, dem ich aber in keiner Weise entgegenwirken kann.
Minimale Realmessung: die eigentliche CrUX
Der größte Kritikpunkt ist aber, dass die Page Speed-Messung aus Schätzwerten besteht, wie man unter den oben im Bild gezeigten Werten ablesen kann. Man liest in den Ergebnissen der Page Speed Messung oben häufig: „Im Bericht zur Nutzererfahrung in Chrome sind nicht genügend tatsächliche Geschwindigkeitsdaten für diesen Ursprung vorhanden.“
Hier liegt die eigentliche Crux, und so heißt sie auch, nämlich CrUX: Chrome User Experience Report.
Google sammelt die Daten, auf denen die Core Web Vitals basieren, nämlich nicht bei der Indizierung von Websites und auch nicht (nur) bei und für Messungen mit Page Speed Insights, sondern vor allem über den hauseigenen Browser Chrome, der von tatsächlichen Besucherïnnen der Website verwendet wird.
Hier liegt natürlich ein Problem. Laut meiner Zugriffsstatistik für die letzten 12 Monate benutzten knapp 25% meiner Besucherïnnen Chrome auf dem Desktop, weitere 7,5% Chrome Mobile. Zwar will ich annehmen, dass meine Statistik nicht unbedingt repräsentativ für das Internet ist, Statista nennt für das erste Halbjahr ’21 z.B. einen Marktanteil für Chrome von gut 68%. Aber bei mir ist es eben nur ein Drittel der Gesamtzahl, und davon fließen längst nicht alle ein. Ein Chrome-Browser nimmt an der Datenerhebung laut Google nur dann teil, wenn die Benutzerïnnen a ) zugestimmt haben, die Browserhistorie zu synchronisieren, b) diese Synchronisierung aber nicht über eine Passphrase gesichert ist und c) zusätzlich die Erhebung statistischer Daten ausdrücklich akzeptiert wurde (vgl. verlinktes Dokument, 1. Absatz „Methodology“). Das dürfte wiederum nur für einen Bruchteil der tatsächlichen Benutzerïnnen von Chrome zutreffen.
Es ist also nur eine kleine Zahl an Besucherïnnen, die für die Core Web Vitals tatsächliche Daten aus der Realität liefern. Gibt es nicht genug dieser Daten, erfolgt eine Schätzung beim Ermitteln des Page Speeds mit Insights, die von zahlreichen Faktoren abhängt. Man sollte sie also mehrfach zu verschiedenen Zeiten ausführen, um ein gewisses Bild zu erhalten.
Und wenn nicht genügend Daten für die letzten 90 Tage vorliegen, um einen echten Wert zu ermitteln, dann zeigt zumindest die Google Search Console eben auch keine Daten an. Zumindest: keine guten.
Ich betreue einige Websites mit relativ wenigen Besucherïnnen, bei denen auf der Basis von nicht mehr als 3 oder 4 Impressionen behauptet wird, keine URL biete eine hohe Nutzerfreundlichkeit, während nur Websites mit 180 und mehr Impressionen positive Daten erhalten. Dazwischen liegt der Großteil der Websites, für die gar keine Daten angezeigt werden.
Ich nehme an, dass mit „Impressionen“ hier zum Stichtag aufsummierte Seitenaufrufe durch passend konfigurierte Chrome-Browser innerhalb des herangezogenen Zeitraums, wohl 90 Tage, gemeint sind. Seitenansichten pro Tag können es jedenfalls nicht sein, die Zahlen liegen in einigen Fällen sehr weit über dem, was normale Statistiken an täglichen Seitenansichten erfassen.
Ob und mit wie viel Aufwand man sich mit den Core Web Vitals der eigenen Website auseinandersetzen will, bleibt jedem selbst überlassen. Es bleibt nur zu hoffen, dass bei solch schlechter Datenlage wie beschrieben auch auf die Heranziehung dieser Daten zum Ranking verzichtet wird.
