Ein ausführlicher Leitfaden zur Messung von Kern-Web-Vitals

Google hat angekündigt, dass sie ab Mai 2021 ( Bearbeiten : das Datum wurde gerade auf Juni 2021 verschoben) die „Seitenerfahrung“ als Teil des Suchrankings berücksichtigen werden, gemessen an einer Reihe von Metriken namens Core Web Vitals. Dieses Datum nähert sich schnell und ich bin sicher, dass viele von uns gebeten werden, sicherzustellen, dass wir unsere Core Web Vitals bestehen, aber wie können Sie wissen, ob Sie es sind?

Die Beantwortung dieser Frage ist tatsächlich schwieriger, als Sie vielleicht annehmen, und obwohl viele Tools diese Core Web Vitals jetzt aufdecken, gibt es viele wichtige Konzepte und Feinheiten zu verstehen. selbst die Google-Tools wie PageSpeed ​​Insights und der Core Web Vitals-Bericht in der Google Search Console scheinen verwirrende Informationen zu liefern.

Warum ist das so und wie können Sie sicher sein, dass Ihre Korrekturen wirklich funktioniert haben? Wie können Sie sich ein genaues Bild von den Core Web Vitals Ihrer Website machen? In diesem Beitrag werde ich versuchen, etwas mehr darüber zu erklären, was hier vor sich geht, und einige der Nuancen und Missverständnisse dieser Tools erklären.

Was sind die Kern-Web-Vitals?

Die Core Web Vitals sind eine Reihe von drei Metriken, die entwickelt wurden, um das „Kern“-Erlebnis zu messen, ob sich eine Website für die Benutzer schnell oder langsam anfühlt und somit ein gutes Erlebnis bietet.

Webseiten müssen innerhalb der grünen Messungen für alle drei Core Web Vitals liegen, um den vollen Nutzen aus einem Ranking-Boost zu ziehen. Außerhalb des guten Bereichs können unterschiedliche Werte einer Core Web Vital-Metrik auf zwei Seiten zu einem unterschiedlichen Ranking der Seitenerfahrung führen.

1. Größte zufriedene Farbe (LCP)

Diese Metrik ist wahrscheinlich am einfachsten zu verstehen – sie misst, wie schnell Sie das größte Element auf der Seite gezeichnet bekommen – was wahrscheinlich der Inhalt ist, an dem der Benutzer interessiert ist. Dies könnte ein Bannerbild, ein Stück Text oder sein wie auch immer. Die Tatsache, dass es das größte inhaltliche Element auf der Seite ist, ist ein guter Indikator dafür, dass es das wichtigste Element ist. LCP ist relativ neu, und wir haben früher den ähnlich benannten First Contentful Paint (FCP) gemessen, aber LCP wurde als bessere Metrik dafür angesehen, wann der Inhalt, den der Besucher wahrscheinlich sehen möchte, gezeichnet wird.

LCP soll die Ladeleistung messen und ist ein guter Proxy für all die alten Metriken, die wir in der Leistungsgemeinschaft verwendet haben (z. B. Zeit bis zum ersten Byte ( TTFB ), geladener DOM-Inhalt, Start-Rendering, Geschwindigkeitsindex) – aber aus Erfahrung des Benutzers. Es deckt nicht alle Informationen ab, die von diesen Metriken abgedeckt werden, sondern ist eine einfachere, einzelne Metrik, die versucht, einen guten Hinweis auf die Seitenlast zu geben.

2. Erste Eingangsverzögerung (FID)

Diese zweite Metrik misst die Zeit zwischen der Interaktion des Benutzers mit einer Seite, beispielsweise dem Klicken auf einen Link oder eine Schaltfläche, und der Verarbeitung des Klicks durch den Browser. Es dient dazu, die Interaktivität einer Seite zu messen . Wenn der gesamte Inhalt geladen wird, die Seite jedoch nicht reagiert, ist dies für den Benutzer frustrierend.

Ein wichtiger Punkt ist, dass diese Metrik nicht simuliert werden kann, da sie wirklich davon abhängt, wann ein Benutzer tatsächlich auf eine Seite klickt oder anderweitig mit ihr interagiert und wie lange es dann dauert, bis die Aktion ausgeführt wird. Die Total Blocking Time (TBT) ist ein guter Proxy für FID, wenn Sie ein Testtool ohne direkte Benutzerinteraktion verwenden, aber behalten Sie auch die Time to Interactive (TTI) im Auge, wenn Sie sich FID ansehen.

3. Kumulative Layoutverschiebung (CLS)

Eine sehr interessante Metrik, ganz anders als andere Metriken, die es aus mehreren Gründen zuvor gab. Es wurde entwickelt, um die visuelle Stabilität der Seite zu messen – im Grunde wie viel sie herumspringt, wenn neue Inhalte eingefügt werden. Ich bin sicher, wir haben alle schon einmal auf einen Artikel geklickt, angefangen zu lesen und dann den Text herumspringen lassen, während Bilder, Anzeigen und andere Inhalte geladen wurden.

Dies ist ziemlich störend und ärgerlich für Benutzer, also minimieren Sie es am besten. Noch schlimmer ist es, wenn sich die Schaltfläche, auf die Sie gerade klicken wollten, plötzlich bewegt und Sie stattdessen auf eine andere Schaltfläche klicken! CLS versucht, diese Layoutverschiebungen zu berücksichtigen.

Labor gegen RUM

Einer der wichtigsten Punkte, die Sie über Core Web Vitals verstehen sollten, ist, dass sie auf Feldmetriken oder Real User Metrics (RUM) basieren. Google verwendet anonymisierte Daten von Chrome-Nutzern für Feedback-Metriken und stellt diese im Chrome User Experience Report (CrUX) zur Verfügung. Diese Daten verwenden sie, um diese drei Metriken für die Suchrankings zu messen. CrUX-Daten sind in einer Reihe von Tools verfügbar, einschließlich in der Google Search Console für Ihre Website.

Die Tatsache, dass RUM-Daten verwendet werden, ist ein wichtiger Unterschied , da einige dieser Metriken (mit Ausnahme von FID) in synthetischen oder „laborbasierten“ Web-Performance-Tools wie Lighthouse verfügbar sind, die in der Vergangenheit für viele der Grundpfeiler der Web-Performance-Überwachung waren . Diese Tools führen Seitenladevorgänge auf simulierten Netzwerken und Geräten aus und teilen Ihnen dann die Metriken für diesen Testlauf mit.

Wenn Sie also Lighthouse auf Ihrem leistungsstarken Entwicklercomputer ausführen und hervorragende Ergebnisse erzielen, spiegelt dies möglicherweise nicht wider, was die Benutzer in der realen Welt erleben und was Google verwendet, um die Benutzererfahrung Ihrer Website zu messen.

LCP wird sehr stark von den Netzwerkbedingungen und der Verarbeitungsleistung der verwendeten Geräte abhängen (und viel mehr Ihrer Benutzer verwenden wahrscheinlich Geräte mit geringerer Leistung, als Ihnen bewusst ist!). Ein Kontrapunkt ist jedoch, dass unsere Handys zumindest für viele westliche Websites vielleicht nicht ganz so leistungsschwach sind, wie Tools wie Lighthouse im Mobilmodus vermuten lassen, da diese ziemlich gedrosselt sind. Sie werden also möglicherweise feststellen, dass Ihre Felddaten auf Mobilgeräten besser sind, als das Testen mit diesem Vorschlag nahelegt (es gibt einige Diskussionen über das Ändern der mobilen Lighthouse-Einstellungen).

In ähnlicher Weise hängt FID oft von der Prozessorgeschwindigkeit ab und davon, wie das Gerät mit all diesen Inhalten umgehen kann, die wir an es senden – seien es zu verarbeitende Bilder, Elemente, die auf der Seite angeordnet werden sollen, und natürlich all das JavaScript, das wir gerne senden an den Browser zum Durchblättern.

CLS lässt sich theoretisch leichter in Tools messen, da es weniger anfällig für Netzwerk- und Hardwarevariationen ist, sodass Sie denken würden, dass es nicht so sehr den Unterschieden zwischen LAB und RUM unterliegt – mit Ausnahme einiger wichtiger Überlegungen, die zunächst nicht offensichtlich sind :

• Es wird während der gesamten Lebensdauer der Seite gemessen und nicht nur für das Laden der Seite, wie dies bei typischen Tools der Fall ist, auf die wir später in diesem Artikel näher eingehen werden. Dies führt zu großer Verwirrung, wenn im Labor simulierte Seitenladevorgänge einen sehr niedrigen CLS aufweisen, der Feld-CLS-Score jedoch viel höher ist, da der CLS durch Scrollen oder andere Änderungen nach dem anfänglichen Laden verursacht wird, die Testtools normalerweise messen.
• Dies kann von der Größe des Browserfensters abhängen – typischerweise Tools wie PageSpeed ​​Insights, messen Mobilgeräte und Desktops, aber verschiedene Mobilgeräte haben unterschiedliche Bildschirmgrößen, und Desktops sind oft viel größer als diese Tools (Web Page Test hat kürzlich ihre Standardbildschirmgröße erhöht um zu versuchen, die Nutzung genauer widerzuspiegeln).
• Unterschiedliche Benutzer sehen unterschiedliche Dinge auf Webseiten . Cookie-Banner, angepasste Inhalte wie Werbeaktionen, Adblocker, A/B-Tests, um nur einige Elemente zu nennen, die unterschiedlich sein können, wirken sich alle darauf aus, welche Inhalte gezeichnet werden und was CLS-Benutzer erleben können.
• Es entwickelt sich immer noch weiter und das Chrome-Team war damit beschäftigt , „unsichtbare“ Verschiebungen und dergleichen zu beheben , die nicht zum CLS zählen sollten. Größere Änderungen an der Art und Weise, wie CLS tatsächlich gemessen wird, sind ebenfalls im Gange. Das bedeutet, dass Sie je nach ausgeführter Chrome-Version unterschiedliche CLS-Werte sehen können.

Die Verwendung desselben Namens für die Metriken in laborbasierten Testwerkzeugen, wenn sie möglicherweise keine genauen Widerspiegelungen realer Versionen sind, ist verwirrend, und einige schlagen vor, dass wir einige oder alle dieser Metriken in Lighthouse umbenennen sollten, um diese simulierten Metriken von den zu unterscheiden reale RUM-Metriken, die die Google-Rankings antreiben.

Frühere Webleistungsmetriken

Ein weiterer Punkt der Verwirrung ist, dass diese Metriken neu sind und sich von den Metriken unterscheiden, die wir in der Vergangenheit traditionell zur Messung der Webleistung verwendet haben und die von einigen dieser Tools wie PageSpeed ​​Insights – einem kostenlosen Online-Audit-Tool – auftauchen. Geben Sie einfach die URL ein, für die Sie ein Audit wünschen, und klicken Sie auf Analysieren. Ein paar Sekunden später werden Ihnen zwei Registerkarten (eine für Mobilgeräte und eine für Desktops) angezeigt, die eine Fülle von Informationen enthalten:

An der Spitze steht der große Lighthouse-Performance-Score von 100. Dieser ist in Web-Performance-Communities seit einiger Zeit bekannt und wird oft als eine wichtige Leistungsmetrik zitiert, die angestrebt und die Komplexität vieler Metriken in einer einfachen zusammengefasst werden soll , leicht verständliche Nummer. Das hat einige Überschneidungen mit dem Ziel der Core Web Vitals, aber es ist keine Zusammenfassung der drei Core Web Vitals (auch nicht der laborbasierten Versionen), sondern einer breiteren Palette von Metriken.

Derzeit bilden sechs Metriken den Lighthouse-Leistungswert – darunter einige der Core Web Vitals und einige andere Metriken:

• Erste zufriedene Farbe (FCP)
• Geschwindigkeitsindex (SI)
• Größte zufriedene Farbe (LCP)
• Zeit bis zur Interaktivität (TTI)
• Gesamtsperrzeit (TBT)
• Kumulative Layoutverschiebung (CLS)

Um die Komplexität noch zu erhöhen, wird jede dieser sechs im Performance-Score unterschiedlich gewichtet, und CLS macht, obwohl es zu den Core Web Vitals gehört, derzeit nur 5 % des Lighthouse Performance-Scores aus (ich werde darauf wetten, dass dieser Wert bald danach steigt die nächste Iteration von CLS wird veröffentlicht). All dies bedeutet, dass Sie eine sehr hohe, grün gefärbte Lighthouse-Leistungsbewertung erhalten und denken können, dass Ihre Website in Ordnung ist, und dennoch die Core Web Vitals-Schwelle nicht überschreiten. Daher müssen Sie Ihre Bemühungen möglicherweise jetzt neu fokussieren, um sich diese drei Kernmetriken anzusehen.

Wenn wir über die große grüne Punktzahl in diesem Screenshot hinausgehen, gehen wir zu den Felddaten und sehen einen weiteren Punkt der Verwirrung: First Contentful Paint wird in diesen Felddaten zusammen mit den anderen drei Core Web Vitals angezeigt, obwohl es nicht Teil des Core Web ist Vitals und, wie in diesem Beispiel, finde ich oft, dass es als Warnung gekennzeichnet ist, selbst wenn die anderen alle bestehen. (Vielleicht müssen die Schwellenwerte dafür ein wenig angepasst werden?) Hat FCP es knapp verpasst, ein Core Web Vital zu sein, oder sieht es mit vier Metriken einfach besser ausbalanciert aus? Dieser Felddatenabschnitt ist wichtig, und wir werden später darauf zurückkommen.

Wenn für die bestimmte zu testende URL keine Felddaten verfügbar sind, werden stattdessen Ursprungsdaten für die gesamte Domäne angezeigt (dies ist standardmäßig ausgeblendet, wenn Felddaten für diese bestimmte URL verfügbar sind, wie oben gezeigt).

Nach den Felddaten erhalten wir die Labordaten und sehen oben die sechs Metriken, die den Leistungswert ausmachen. Wenn Sie auf den Schalter oben rechts klicken, erhalten Sie sogar eine etwas ausführlichere Beschreibung dieser Metriken:

Wie Sie sehen können, sind die Laborversionen von LCP und CLS hier enthalten, und da sie Teil von Core Web Vitals sind, erhalten sie ein blaues Etikett, um sie als besonders wichtig zu kennzeichnen. PageSpeed ​​Insights enthält auch einen hilfreichen Taschenrechner-Link, um die Auswirkungen dieser Punktzahlen auf die Gesamtpunktzahl oben zu sehen, und Sie können sie anpassen, um zu sehen, wie sich die Verbesserung jeder Metrik auf Ihre Punktzahl auswirkt. Aber wie gesagt, der Web-Performance-Score wird wahrscheinlich für eine Weile in den Hintergrund treten, während die Core Web Vitals im Moment im Glanz der ganzen Aufmerksamkeit aalen.

Lighthouse führt außerdem fast 50 weitere Überprüfungen von zusätzlichen Gelegenheiten und Diagnosen durch. Diese wirken sich weder direkt auf die Punktzahl noch auf Core Web Vitals aus, können aber von Webentwicklern verwendet werden, um die Leistung ihrer Website zu verbessern . Diese werden auch in PageSpeed ​​Insights unter allen Metriken angezeigt, also nur aus dem Bild für den obigen Screenshot. Betrachten Sie diese als Vorschläge zur Verbesserung der Leistung und nicht als spezifische Probleme, die unbedingt angegangen werden müssen.

Die Diagnose zeigt Ihnen das LCP-Element und die Verschiebungen, die zu Ihrem CLS-Score beigetragen haben, was sehr nützliche Informationen bei der Optimierung Ihrer Core Web Vitals sind!

Während sich Befürworter der Web-Performance in der Vergangenheit möglicherweise stark auf Lighthouse-Scores und Audits konzentriert haben, sehe ich, dass dies auf die drei Core Web Vital-Metriken fokussiert ist – zumindest für die nächste Zeit, während wir uns damit beschäftigen. Die anderen Lighthouse-Metriken und die Gesamtpunktzahl sind immer noch nützlich, um die Leistung Ihrer Website zu optimieren, aber die Core Web Vitals nehmen derzeit den größten Teil der Tinte für neue Web-Performance- und SEO-Blogposts in Anspruch.

Anzeigen der wichtigsten Web Vitals für Ihre Website

Der einfachste Weg, einen schnellen Blick auf die Core Web Vitals für eine einzelne URL und für den gesamten Ursprung zu werfen, besteht darin, eine URL wie oben beschrieben in PageSpeed ​​Insights einzugeben. Um jedoch zu sehen, wie Google die Core Web Vitals für Ihre gesamte Website sieht, erhalten Sie Zugriff auf die Google Search Console. Dies ist ein kostenloses Produkt von Google, mit dem Sie verstehen können, wie Google Ihre gesamte Website „sieht“, einschließlich der Core Web Vitals für Ihre Website (obwohl es einige – sagen wir – „ Frustrationen “ darüber gibt, wie oft die Daten hier aktualisiert werden ).

Die Google Search Console wird seit langem von SEO-Teams verwendet, aber mit dem Input, den Website-Entwickler benötigen, um sich mit Core Web Vitals zu befassen, sollten Entwicklungsteams wirklich auch Zugang zu diesem Tool erhalten, wenn sie dies noch nicht getan haben. Um Zugriff zu erhalten, benötigen Sie ein Google-Konto und müssen dann auf verschiedene Weise Ihr Eigentum an der Website bestätigen (Platzieren einer Datei auf Ihrem Webserver, Hinzufügen eines DNS-Eintrags usw.).

Der Core Web Vitals-Bericht in der Google Search Console gibt Ihnen eine Zusammenfassung darüber, wie Ihre Website die Core Web Vitals in den letzten 90 Tagen erfüllt hat:

Um die Core Web Vitals vollständig zu bestehen, sollten im Idealfall alle Ihre Seiten grün sein, ohne Gelb- oder Rottöne. Während ein Gelb ein guter Indikator dafür ist, dass Sie kurz vor dem Passieren stehen, zählen wirklich nur die Grüns, um den vollen Nutzen zu erzielen. Geben Sie sich also nicht mit dem Zweitbesten zufrieden. Es liegt an Ihnen, ob Sie alle Ihre Seiten übergeben müssen oder nur Ihre wichtigsten, aber oft treten auf vielen Seiten ähnliche Probleme auf, und die Behebung dieser Probleme für die Website kann dazu beitragen, die Anzahl der URLs, die nicht übergeben werden, überschaubarer zu machen Ebene, auf der Sie diese Entscheidungen treffen können.

Anfangs wird Google das Ranking von Core Web Vitals nur auf Mobilgeräte anwenden, aber es ist sicherlich nur eine Frage der Zeit, bis dies auch auf Desktops eingeführt wird. Ignorieren Sie also Desktop nicht, während Sie Ihre Seiten überprüfen und korrigieren.

Wenn Sie auf einen der Berichte klicken, erhalten Sie weitere Einzelheiten darüber, welche der Web Vitals nicht erfüllt werden, und dann eine Auswahl der betroffenen URLs. Die Google Search Console gruppiert URLs in Buckets , damit Sie theoretisch ähnliche Seiten gemeinsam ansprechen können. Sie können dann auf eine URL klicken, um PageSpeed ​​Insights auszuführen, um eine schnelle Leistungsprüfung für die bestimmte URL durchzuführen (einschließlich der Anzeige der Core Web Vitals-Felddaten für diese Seite, falls verfügbar). Sie beheben dann die hervorgehobenen Probleme, führen PageSpeed ​​Insights erneut aus, um zu bestätigen, dass die Lab-Metriken jetzt korrekt sind, und fahren dann mit der nächsten Seite fort.

Sobald Sie sich jedoch diesen Core Web Vitals-Bericht ansehen (für einige von uns obsessiv!), waren Sie möglicherweise frustriert, dass dieser Bericht anscheinend nicht aktualisiert wird , um Ihre harte Arbeit widerzuspiegeln. Es scheint jeden Tag aktualisiert zu werden, wenn sich das Diagramm bewegt, aber es ändert sich oft kaum, selbst nachdem Sie Ihre Fixes veröffentlicht haben – warum?

In ähnlicher Weise zeigen die Felddaten von PageSpeed ​​Insights diese URL und Website immer noch als fehlerhaft an. Was ist denn hier die Geschichte?

Der Chrome User Experience Report (CrUX)

Der Grund für die langsame Aktualisierung der Web Vitals liegt darin, dass die Felddaten auf den Daten der letzten 28 Tage im Chrome User Experience Report (CrUX) und darin nur auf dem 75. Perzentil dieser Daten basieren. Die Verwendung von Daten aus 28 Tagen und dem 75. Perzentil der Daten ist insofern eine gute Sache, als sie Abweichungen und Extreme entfernen, um die Leistung Ihrer Website genauer widerzuspiegeln, ohne viel Rauschen zu verursachen, das schwer zu interpretieren ist.

Leistungsmetriken sind sehr anfällig für das Netzwerk und die Geräte , daher müssen wir dieses Rauschen glätten, um die wahre Geschichte darüber zu erfahren, wie Ihre Website für die meisten Benutzer funktioniert. Die Kehrseite davon ist jedoch, dass sie frustrierend langsam aktualisiert werden, wodurch eine sehr langsame Rückkopplungsschleife von der Korrektur von Problemen entsteht, bis Sie die Ergebnisse dieser Korrektur dort widerspiegeln.

Besonders das 75. Perzentil (oder p75) ist interessant und die Verzögerung, die es verursacht, da ich denke, dass das nicht gut verstanden wird. Es wird untersucht, welche Metrik 75 % der Seitenaufrufe Ihrer Besucher in diesen 28 Tagen für jedes der Core Web Vitals ausmacht.

Es ist daher der höchste Core Web Vital-Score von 75 % Ihrer Seitenaufrufe (oder umgekehrt der niedrigste Core Web Vitals-Score, den 75 % Ihrer Seitenaufrufe unterschreiten). Es ist also nicht der Durchschnitt dieser 75 % der Seitenaufrufe, sondern der schlechteste Wert dieser Gruppe von Benutzern.

Dies führt zu einer Verzögerung bei der Berichterstattung , die bei einem nicht auf Perzentilen basierenden gleitenden Durchschnitt nicht der Fall wäre. Wir müssen hier ein wenig mathematisch werden (ich werde versuchen, es auf ein Minimum zu beschränken), aber nehmen wir der Einfachheit halber an, dass jeder im letzten Monat ein LCP von 10 Sekunden erhalten hat, und Sie es behoben haben, also jetzt dauert nur 1 Sekunde, und sagen wir, Sie hatten jeden Tag genau die gleiche Anzahl von Besuchern und alle haben dieses LCP erzielt.

In diesem allzu vereinfachten Szenario würden Sie die folgenden Metriken erhalten:

Sie können also sehen, dass Sie Ihre drastischen Verbesserungen im CrUX-Score erst an Tag 22 sehen, wenn er plötzlich auf den neuen, niedrigeren Wert springt (sobald wir 75 % des 28-Tage-Durchschnitts überschreiten – kein Zufall!). Bis dahin basierten über 25 % Ihrer Benutzer auf Daten, die vor der Änderung gesammelt wurden, und daher erhalten wir den alten Wert von 10, und daher blieb Ihr p75-Wert bei 10 hängen.

Daher sieht es so aus, als ob Sie lange Zeit überhaupt keine Fortschritte gemacht haben, während ein mittlerer Durchschnitt (falls er verwendet wurde) einen allmählichen Tick-Down zeigen würde, der sofort beginnt, und so könnte ein Fortschritt tatsächlich gesehen werden. Auf der positiven Seite ist der Mittelwert in den letzten Tagen sogar höher als der p75-Wert, da p75 per Definition die Extreme vollständig herausfiltert.

Das Beispiel in der obigen Tabelle erklärt, obwohl es stark vereinfacht ist, einen Grund, warum viele Web Vitals-Diagramme wie unten sehen, bei denen eines Tages alle Ihre Seiten einen Schwellenwert überschreiten und dann gut sind ( woohoo! ):

Dies mag für diejenigen überraschend sein, die eher allmähliche (und sofortige) Änderungen erwarten, wenn Sie Seitenprobleme durcharbeiten und da einige Seiten häufiger besucht werden als andere. In diesem Zusammenhang ist es auch nicht ungewöhnlich, dass Ihr Search Console-Diagramm eine bernsteinfarbene Phase durchläuft, abhängig von Ihren Korrekturen und wie sie sich auf die Schwellenwerte auswirken, bevor sie diese süße, süße grüne Farbe erreichen:

Dave Smart führte ein faszinierendes Experiment zum Tracking von Änderungen in den Web Vitals-Berichtskerndaten der Search Console durch, bei dem er untersuchen wollte, wie schnell es dauerte, die Diagramme zu aktualisieren. Er hat den 75. Perzentil-Anteil von CrUX nicht berücksichtigt (was den Mangel an Bewegung in einigen seiner Diagramme sinnvoller erscheinen lässt), aber dennoch ein faszinierendes Experiment aus dem wirklichen Leben, wie sich dieses Diagramm aktualisiert, und es lohnt sich, es zu lesen!

Meine eigene Erfahrung ist, dass diese 28-tägige p75-Methodik die Verzögerung im Core Web Vitals-Bericht nicht vollständig erklärt, und wir werden gleich einige andere mögliche Gründe diskutieren.

Ist das also das Beste, was Sie tun können, die Korrekturen vornehmen, dann geduldig warten und mit den Fingern tippen, bis CrUX Ihre Korrekturen für würdig erachtet und das Diagramm in Search Console und PageSpeed ​​Insights aktualisiert? Und wenn sich herausstellt, dass Ihre Korrekturen nicht gut genug waren, dann den ganzen Zyklus von vorne beginnen? In der heutigen Zeit des sofortigen Feedbacks, um unser Verlangen zu stillen, und der engen Feedbackschleifen für Entwickler , um die Produktivität zu verbessern , ist das überhaupt nicht sehr befriedigend!

Nun, es gibt einige Dinge, die Sie in der Zwischenzeit tun können, um zu sehen, ob irgendwelche Korrekturen die beabsichtigte Wirkung erzielen.

Genaueres Eintauchen in die Crux-Daten

Da der Kern der Messung die CrUX-Daten sind, lassen Sie uns näher darauf eingehen und sehen, was sie uns sonst noch sagen können. Wenn wir zurück zu PageSpeed ​​Insights gehen, können wir sehen, dass es nicht nur den p75-Wert für die Website anzeigt, sondern auch den Prozentsatz der Seitenaufrufe in jedem der grünen, gelben und roten Buckets, die in den Farbbalken darunter angezeigt werden:

Der obige Screenshot zeigt, dass CLS die Bewertung von Core Web Vitals mit einem p75-Wert von 0,11 nicht bestanden hat, was über der 0,1-Grenze zum Bestehen liegt. Obwohl die Farbe der Schrift rot ist, handelt es sich tatsächlich um ein gelbes Ranking (da Rot über 0,25 liegen würde). Interessanter ist, dass der grüne Balken bei 73 % liegt – sobald dieser 75 % erreicht, besteht diese Seite die Core Web Vitals.

Während Sie die historischen CrUX-Werte nicht sehen können, können Sie diese im Laufe der Zeit überwachen. Wenn es morgen auf 74 % geht, dann tendieren wir in die richtige Richtung (Schwankungen vorbehalten!) und können hoffen, bald die magischen 75 % zu erreichen. Bei Werten, die weiter entfernt sind, können Sie regelmäßig überprüfen und den Anstieg sehen und dann projizieren, wann Sie beginnen, als bestanden zu erscheinen.

CrUX ist auch als kostenlose API verfügbar, um genauere Zahlen für diese Prozentsätze zu erhalten. Sobald Sie sich für einen API-Schlüssel angemeldet haben, können Sie ihn mit einem Curl-Befehl wie diesem aufrufen (wobei API_KEY, formFactor und URL nach Bedarf ersetzen):

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

Und Sie erhalten eine JSON-Antwort wie diese:

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

Übrigens, wenn Sie oben ein wenig Angst haben und Sie einen schnelleren Weg suchen, um sich diese Daten für nur eine URL anzusehen, gibt PageSpeed ​​Insights auch diese Genauigkeit zurück, die Sie sehen können, indem Sie DevTools öffnen und dann Ihren PageSpeed ​​Insights-Test ausführen Finden des XHR-Aufrufs, den es macht:

Es gibt auch einen interaktiven CrUX-API-Explorer, mit dem Sie Beispielabfragen der CrUX-API durchführen können. Für den regelmäßigen Aufruf der API ist es jedoch normalerweise einfacher, einen kostenlosen Schlüssel zu erhalten und Curl oder ein anderes API-Tool zu verwenden.

Die API kann auch mit einem „Ursprung“ anstelle einer URL aufgerufen werden, an welcher Stelle sie den zusammengefassten Wert aller Seitenbesuche auf dieser Domain liefert. PageSpeed ​​Insights legt diese Informationen offen, was nützlich sein kann, wenn für Ihre URL keine CrUX-Informationen verfügbar sind, die Google Search Console jedoch nicht. Google hat nicht genau angegeben (und wird dies wahrscheinlich auch nicht tun!), wie sich die Core Web Vitals auf das Ranking auswirken werden . Wirkt sich die Punktzahl auf Ursprungsebene auf Rankings aus oder nur auf einzelne URL-Punktzahlen? Oder wird Google wie bei PageSpeed ​​Insights auf die ursprünglichen Punktzahlen zurückgreifen, wenn keine individuellen URL-Daten vorhanden sind? Im Moment schwer zu wissen und der einzige Hinweis bisher ist dieser in den FAQ:

F : Wie wird eine Punktzahl für eine URL berechnet, die kürzlich veröffentlicht wurde und noch keine 28-Tage-Daten generiert hat?

A : Ähnlich wie Search Console Daten zur Seitenerfahrung meldet, können wir Techniken wie das Gruppieren ähnlicher Seiten und das Berechnen von Bewertungen basierend auf dieser Aggregation anwenden. Dies gilt für Seiten, die wenig bis gar keinen Verkehr erhalten, sodass kleine Websites ohne Felddaten nicht beunruhigt sein müssen.

Die CrUX-API kann programmgesteuert aufgerufen werden, und Rick Viscomi vom Google CrUX-Team hat einen Google Sheets-Monitor erstellt, mit dem Sie URLs oder Ursprünge in großen Mengen überprüfen und CrUX-Daten im Laufe der Zeit sogar automatisch verfolgen können, wenn Sie eine Reihe von URLs oder Ursprüngen genau überwachen möchten . Klonen Sie einfach das Blatt, gehen Sie zu Tools → Script Skripteditor und geben Sie dann eine Skripteigenschaft von CRUX_API_KEY mit Ihrem Schlüssel ein (dies muss im Legacy-Editor erfolgen), und führen Sie dann das Skript aus, und es ruft die CrUX-API für die gegebenen auf URLs oder Ursprünge und fügen Sie unten auf dem Blatt Zeilen mit den Daten hinzu. Dies kann dann periodisch ausgeführt oder für eine regelmäßige Ausführung geplant werden.

Ich habe dies verwendet, um alle URLs für eine Website mit einem sich langsam aktualisierenden Core Web Vitals-Bericht in der Google Search Console zu überprüfen, und es bestätigte, dass CrUX für viele URLs keine Daten hatte und die meisten anderen bestanden waren, was erneut zeigt, dass die Der Bericht der Google Search Console ist im Rückstand – sogar von den CrUX-Daten, auf denen er basieren soll. Ich bin mir nicht sicher, ob es an URLs liegt, die zuvor fehlgeschlagen sind, aber jetzt nicht genug Verkehr haben, um aktualisierte CrUX-Daten zu erhalten, die zeigen, dass sie bestehen, oder ob es an etwas anderem liegt, aber das beweist mir, dass dieser Bericht definitiv langsam ist .

Ich vermute, dass ein großer Teil davon auf URLs ohne Daten in CrUX und der Google-Suche zurückzuführen ist, die ihr Bestes tun, um einen Wert für sie zu ermitteln. Dieser Bericht ist also ein großartiger Ausgangspunkt, um sich einen Überblick über Ihre Website zu verschaffen, und einer, den Sie in Zukunft überwachen können, aber kein großartiger Bericht, um die Probleme zu bearbeiten, bei denen Sie sofortiges Feedback wünschen.

Für diejenigen, die noch mehr in CrUX eintauchen möchten, gibt es in BigQuery monatliche Tabellen mit CrUX-Daten (nur auf Ursprungsebene, also nicht für einzelne URLs) und Rick hat auch dokumentiert, wie Sie ein CrUX-Dashboard auf der Grundlage dessen erstellen können, was möglich ist eine gute Möglichkeit, die Gesamtleistung Ihrer Website über die Monate hinweg zu überwachen.

Weitere Informationen zu den Crux-Daten

Mit dem oben Gesagten sollten Sie also ein gutes Verständnis des CrUX-Datensatzes haben, warum einige der Tools, die ihn verwenden, langsam und unberechenbar zu aktualisieren scheinen, und auch, wie Sie ihn ein wenig genauer untersuchen können. Aber bevor wir zu Alternativen dazu übergehen, gibt es noch einige Dinge, die Sie über CrUX verstehen sollten, um Ihnen zu helfen, die angezeigten Daten wirklich zu verstehen. Hier ist also eine Sammlung anderer nützlicher Informationen, die ich über CrUX in Bezug auf Core Web Vitals gesammelt habe.

CrUX ist nur Chrome . All diese iOS-Benutzer und andere Browser (Desktop Safari, Firefox, Edge … etc.), ganz zu schweigen von älteren Browsern (Internet Explorer – beeilen Sie sich und blenden Sie aus, würden Sie!) lassen ihre Benutzererfahrung nicht in CrUX-Daten widerspiegeln und so weiter auf Googles Ansicht von Core Web Vitals.

Jetzt ist die Verwendung von Chrome sehr hoch (wenn auch vielleicht nicht für Ihre Website-Besucher?), und in den meisten Fällen wirken sich die hervorgehobenen Leistungsprobleme auch auf diese anderen Browser aus, aber Sie sollten sich dessen bewusst sein. Und es fühlt sich, gelinde gesagt, ein wenig „eklig“ an, dass die Monopolstellung von Google bei der Suche die Leute jetzt dazu ermutigt, für ihren Browser zu optimieren. Wir werden unten über alternative Lösungen für diese eingeschränkte Ansicht sprechen.

Die verwendete Chrome-Version wird sich ebenfalls auswirken, da sich diese Metriken (insbesondere CLS) noch weiterentwickeln und Fehler gefunden und behoben werden . Dies fügt dem Verständnis der Daten eine weitere Dimension der Komplexität hinzu. In den letzten Versionen von Chrome wurden kontinuierliche Verbesserungen an CLS vorgenommen, mit einer größeren Neudefinition von CLS, die in Chrome 91 gelandet ist. Auch hier bedeutet die Tatsache, dass Felddaten verwendet werden, dass es einige Zeit dauern kann, bis diese Änderungen bei den Benutzern ankommen, und dann in die CrUX-Daten.

CrUX ist nur für Benutzer, die bei Chrome angemeldet sind, oder um die eigentliche Definition zu zitieren:

„[CrUX wird] von Benutzern aggregiert, die sich für die Synchronisierung ihres Browserverlaufs entschieden haben, keine Synchronisierungspassphrase eingerichtet haben und die Nutzungsstatistikberichte aktiviert haben.“

— Bericht zur Benutzererfahrung von Chrome, Google Developers

Wenn Sie also nach Informationen auf einer Website suchen, die hauptsächlich von Unternehmensnetzwerken besucht wird, wo solche Einstellungen durch zentrale IT-Richtlinien deaktiviert sind, sehen Sie möglicherweise nicht viele Daten – insbesondere wenn diese armen Unternehmensbenutzer immer noch gezwungen sind, das Internet zu nutzen Entdecker auch!

CrUX umfasst alle Seiten, einschließlich derjenigen, die normalerweise nicht in der Google-Suche angezeigt werden, wie z. B. „noindexed/robboted/login pages will be included“ (obwohl es Mindestschwellenwerte für eine URL und einen Ursprung gibt, die in CrUX offengelegt werden müssen). Jetzt werden diese Seitenkategorien wahrscheinlich nicht in den Google-Suchergebnissen enthalten sein, und daher ist die Auswirkung auf das Ranking wahrscheinlich unwichtig, aber sie werden immer noch in CrUX enthalten sein. Der Core Web Vitals-Bericht in der Google Search Console scheint jedoch nur indexierte URLs anzuzeigen , sodass sie dort nicht angezeigt werden.

Die in PageSpeed ​​Insights und in den CrUX-Rohdaten angezeigte Ursprungszahl umfasst diese nicht indizierten, nicht öffentlichen Seiten, und wie ich oben erwähnt habe, sind wir uns der Auswirkungen nicht sicher. Eine Website, an der ich arbeite, hat einen großen Prozentsatz von Besuchern, die unsere eingeloggten Seiten besuchen, und während die öffentlichen Seiten sehr leistungsfähig waren, waren die eingeloggten Seiten nicht so, und das hat die ursprünglichen Web Vitals-Ergebnisse stark verzerrt.

Die CrUX-API kann verwendet werden, um die Daten dieser angemeldeten URLs abzurufen, aber Tools wie PageSpeed ​​Insights können dies nicht (da sie einen tatsächlichen Browser ausführen und daher auf die Anmeldeseiten umgeleitet werden). Als wir die CrUX-Daten gesehen und die Auswirkungen erkannt hatten, haben wir sie behoben, und die Ursprungszahlen sind allmählich gesunken, aber wie immer dauert es einige Zeit, bis sie durchkommen.

Nicht indizierte oder angemeldete Seiten sind auch oft „Apps“ und keine einzelnen Sammlungen von Seiten, sodass möglicherweise eine Einzelseitenanwendungsmethode mit einer echten URL, aber vielen verschiedenen Seiten darunter verwendet wird. Dies kann sich insbesondere auf CLS auswirken, da es über die gesamte Lebensdauer der Seite gemessen wird (obwohl hoffentlich die bevorstehenden Änderungen an CLS dabei helfen werden).

Wie bereits erwähnt, enthält der Core Web Vitals-Bericht in der Google Search Console, obwohl er auf CrUX basiert, definitiv nicht die gleichen Daten. Wie ich bereits sagte, vermute ich, dass dies hauptsächlich darauf zurückzuführen ist, dass die Google Search Console versucht, Web Vitals für URLs zu schätzen, für die keine CrUX-Daten vorhanden sind. Die Beispiel-URLs in diesem Bericht stimmen auch nicht mit den CrUX-Daten überein.

I've seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing . I'm not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views . That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into Mobile , Desktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I'd advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it's marked as PHONE rather than MOBILE to reflect it's based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you've been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it's not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren't sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it's still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it's doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I'll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript library, which allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module'; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) { ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The `id` value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires `eventLabel` to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use `sendBeacon()` if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Or alternatively, you can include this as an external script instead:

 <script type="module" src="/javascript/send-web-vitals.js"></script>

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don't understand web vitals), its execution is deferred so shouldn't impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it's RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it's fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular data , but that means you're more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google's Phil Walton created a Web-Vitals dashboard, that can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

Wie ich bereits sagte, werden kommerzielle RUM-Produkte oft auch diese Art von Daten (und mehr!) Offenlegen, aber für diejenigen, die nur ihren Zeh ins Wasser tauchen und nicht bereit sind, sich finanziell für diese Produkte zu engagieren, bietet dies zumindest den ersten Versuch in RUM-basierte Metriken und wie nützlich sie sein können , um das entscheidende schnellere Feedback zu den Verbesserungen zu erhalten, die Sie implementieren. Und wenn Sie Lust auf diese Informationen bekommen haben, dann schauen Sie sich unbedingt die anderen RUM-Produkte an, um zu sehen, wie sie Ihnen auch helfen können.

Wenn Sie sich alternative Messungen und RUM-Produkte ansehen, denken Sie daran, zu dem zurückzukehren, was Google für Ihre Website sieht, da es durchaus anders sein kann. Es wäre eine Schande, hart an der Leistung zu arbeiten, aber nicht alle Ranking-Vorteile gleichzeitig zu nutzen! Behalten Sie also diese Grafiken der Search Console im Auge, um sicherzustellen, dass Ihnen nichts entgeht.

Fazit

Die Core Web Vitals sind eine interessante Reihe von Schlüsselmetriken, die die Benutzererfahrung beim Surfen im Internet darstellen sollen. Als leidenschaftlicher Verfechter der Web-Performance begrüße ich jeden Versuch, die Performance von Websites zu verbessern, und die Auswirkungen dieser Metriken auf das Ranking haben sicherlich für viel Aufsehen in den Web-Performance- und SEO-Communities gesorgt.

Während die Metriken selbst sehr interessant sind, ist die Verwendung von CrUX-Daten , um diese zu messen, vielleicht noch spannender. Dadurch werden RUM-Daten Websites zugänglich gemacht, die noch nie zuvor in Betracht gezogen haben, die Website-Performance in diesem Bereich auf diese Weise zu messen. RUM-Daten sind das, was Benutzer tatsächlich erleben , in all ihren wilden und vielfältigen Konfigurationen, und es gibt keinen Ersatz dafür, zu verstehen, wie Ihre Website wirklich funktioniert und von Ihren Benutzern erlebt wird.

Aber der Grund, warum wir so lange von Labordaten abhängig waren, liegt darin, dass RUM-Daten verrauscht sind . Die Schritte, die CrUX unternimmt, um dies zu reduzieren, tragen zwar zu einer stabileren Ansicht bei, erschweren es jedoch auf Kosten, die jüngsten Änderungen zu erkennen.

Hoffentlich erklärt dieser Beitrag die verschiedenen Möglichkeiten des Zugriffs auf die Core Web Vitals-Daten für Ihre Website und einige der Einschränkungen jeder Methode. Ich hoffe auch, dass es dazu beiträgt, einige der Daten zu erklären, für die Sie Schwierigkeiten hatten, sie zu verstehen, sowie einige Möglichkeiten vorzuschlagen, um diese Einschränkungen zu umgehen.

Viel Spaß beim Optimieren!