Core-Web-Vitals-Bericht

Felddaten und Labordaten sind zwei verschiedene Dinge

Ein Labortest wie Lighthouse lädt Ihre Seite einmal auf einem simulierten Mittelklasse-Smartphone mit gedrosselter Verbindung. Sie können ihn beliebig oft wiederholen, und er steckt voller Details, aber der Besucher, den er beschreibt, ist erfunden.

Felddaten stammen aus echten Besuchen. Chrome-Nutzer, die dem Teilen von Nutzungsstatistiken zugestimmt haben, senden anonyme Messwerte, und Google fasst sie über die letzten 28 Tage im Chrome UX Report zusammen, kurz CrUX. Diese Daten liest die Google-Suche, wenn sie die Nutzererfahrung einer Seite bewertet. Eine Seite kann im Labor 95 Punkte erreichen und im Feld trotzdem durchfallen, weil ihr echtes Publikum ältere Smartphones nutzt. Sie kann auch mit mittelmäßigem Laborwert im Feld bestehen, weil die meisten Besucher mit gefülltem Cache kommen.

Dieser Bericht fragt zuerst nach Felddaten, denn das ist die Version, die zählt.

Die fünf Messwerte in der Tabelle

Die ersten drei sind die Core Web Vitals. FCP und TTFB sind als Zugabe dabei, weil sie helfen, ein langsames LCP zu erklären. Sie zählen nicht zur Note.

Wie der Bericht entsteht

Wir folgen Weiterleitungen bis zur endgültigen Adresse und fragen CrUX dann zweimal ab, einmal für Smartphones und einmal für Desktops. Jede Abfrage versucht zuerst die genaue Seite und greift auf die ganze Origin zurück, wenn die Seite allein zu wenig Verkehr hat. Die Zeile über jeder Tabelle sagt, was Sie gerade lesen.

Der angezeigte Wert eines Messwerts ist sein 75. Perzentil, das heißt, drei von vier Besuchen waren mindestens so schnell. Der farbige Balken daneben zeigt den Anteil der Besuche in den Bereichen gut, verbesserungswürdig und schlecht.

Für die Note bringt jedes Core Web Vital 2 Punkte, wenn es gut ist, 1, wenn es verbesserungswürdig ist, und 0, wenn es schlecht ist. Sechs von sechs Punkten ergeben ein A, fünf ein B, vier ein C, drei ein D, zwei ein E und weniger ein F. Ein schlechter Messwert begrenzt die Note auf D, egal wie gut die anderen beiden sind. Die Hauptnote ist die Smartphone-Note, wenn es Smartphone-Daten gibt.

Wenn Chrome keine Daten hat

CrUX deckt nur Seiten ab, die öffentlich sind und oft genug besucht werden. Für alles andere führt der Bericht einen PageSpeed-Insights-Test auf einem simulierten Smartphone aus und sagt Ihnen klar, dass er das getan hat. Sie erhalten dann den Lighthouse-Leistungswert (A ab 90, B ab 75, C ab 50, D ab 35, E ab 20), Laborwerte für LCP und CLS und die Total Blocking Time anstelle von INP, denn die Reaktion auf Eingaben lässt sich nicht messen, ohne dass ein Mensch etwas eingibt. Darunter stehen bis zu fünf Audits mit der größten geschätzten Zeitersparnis.

Was jeden Wert bewegt

LCP

Suchen Sie das LCP-Element im Performance-Panel der Chrome DevTools. Meist ist es das Hauptbild. Liefern Sie es in seiner Anzeigegröße als WebP oder AVIF aus, fügen Sie fetchpriority="high" hinzu und setzen Sie nie loading="lazy" darauf. Liegt die TTFB schon über 0,8 s, beheben Sie zuerst den Server mit Seiten-Caching oder einem CDN. Die Aufschlüsselung der Seitengröße zeigt die schwersten Dateien.

INP

Lange JavaScript-Aufgaben hindern die Seite daran, auf Eingaben zu reagieren. Entfernen Sie Tags und Plugins, die Sie nicht mehr nutzen, laden Sie Skripte von Drittanbietern mit defer und teilen Sie Arbeit auf, die länger als 50 ms läuft.

CLS

Geben Sie jedem Bild und Video die Attribute width und height, reservieren Sie Platz für Anzeigen und Einbettungen mit min-height oder aspect-ratio und fügen Sie keine Banner über bereits sichtbaren Inhalten ein.

Felddaten sind ein gleitendes Fenster von 28 Tagen. Nach einer Korrektur werden die Werte jeden Tag ein wenig besser und brauchen vier Wochen, bis die volle Wirkung sichtbar ist. Besuche aus Safari und aus jedem Browser auf einem iPhone sind nie Teil von CrUX, der Bericht beschreibt also nur Ihr Chrome-Publikum.