Was Core Web Vitals wirklich messen, und welche ein Besucher spürt

Core Web Vitals sind drei Zahlen, und fast alles, was darüber geschrieben wird, erklärt, was sie messen. Die nützlichere Frage ist aber deren Erfahrung sie messen, denn die Antwort steckt in der Definition und entscheidet, welche Schlüsse Sie aus einem grünen Score ziehen können.

Die drei und die eine, die weg ist

Googles eigene Schwellenwerte in je drei Kategorien:

• Largest Contentful Paint (LCP): Gut 2500 ms oder weniger, Verbesserung erforderlich 2501 bis 4000 ms, Schlecht über 4000 ms.
• Interaction to Next Paint (INP): Gut 200 ms oder weniger, Verbesserung erforderlich 201 bis 500 ms, Schlecht über 500 ms.
• Cumulative Layout Shift (CLS): Gut 0,1 oder weniger, Verbesserung erforderlich 0,11 bis 0,25, Schlecht über 0,25.

LCP ist das Laden: wie lange dauert es, bis das größte Element auf dem Bildschirm ankommt. INP ist die Interaktivität: Sie berühren etwas, und wie lange dauert es, bis die Seite eine Reaktion anzeigt. CLS ist die visuelle Stabilität, und es ist die einzige, die keine Dauer ist, sondern ein Wert dafür, wie viel sich das Layout nach dem initialen Laden verschoben hat.

First Input Delay existiert nicht mehr. INP hat FID ersetzt und wurde 2024 stabil, was vor allem deshalb wichtig ist, weil jede Anleitung, die davor geschrieben wurde, eine Metrik nennt, die nicht mehr gemessen wird. Falls Ihnen jemand einen Leistungsbericht mit einer FID-Spalte zeigt, berichtet dieser über ein anderes Web.

Welche ein Besucher wirklich spürt

Das ist der Teil, der es wirklich bringt, denn kein Nutzer berichtet über eine Metrik. Er berichtet über ein Gefühl, und das Gefühl sagt Ihnen, welche der drei Sie untersuchen sollten.

“Ich habe da gesessen und auf das Laden gewartet.” Das ist LCP. Die Seite wurde erreicht, der Server hat geantwortet, und das, wofür die Person kam, ist noch nicht angekommen. Nichts ist kaputt, nichts produziert einen Fehler.

“Ich habe darauf getippt und nichts ist passiert, also habe ich nochmal getippt.” Das ist INP, und der zweite Tipp ist die diagnostische Hälfte. Eine Seite, die keine Reaktion innerhalb weniger hundert Millisekunden anzeigt, wird zweimal getippt, wodurch eine beabsichtigte Aktion zu zwei eingereichten wird.

“Es hat sich verschoben und ich habe auf das Falsche geklickt.” Das ist CLS. Ein spät ankommendes Bild oder eine Web-Font, die nach dem initialen Laden eintrifft, verschiebt den Button zwischen dem Moment, in dem das Auge entscheidet, und dem Moment, in dem der Finger landet.

Also “die Seite fühlt sich langsam an” sind mindestens drei verschiedene Fehler, und die Wörter, die jemand wählt, grenzen es ein, bevor Sie überhaupt gemessen haben. Das ist mehr wert, als es klingt, denn die drei haben nichts gemeinsam: LCP ist normalerweise Bytes und Round Trips, INP ist normalerweise JavaScript, das den Haupt-Thread belastet, und CLS ist normalerweise Layout, für das Sie keinen Platz reserviert haben.

Das 75. Perzentil ist die ganze Geschichte

Hier ist der Satz, der ändert, wie Sie einen Score lesen. Die Beurteilung wird beim 75. Perzentil der Seitenladen, segmentiert über mobile und Desktop-Geräte gemacht.

Nicht der Durchschnitt und nicht Ihr Besuch. Drei Viertel der Ladevorgänge müssen auf oder unter dem Schwellenwert liegen, damit eine Seite besteht, was bedeutet, dass ein Laden von vier schlechter sein darf als Ihre grüne Zahl, während die Zahl grün bleibt. Das ist kein Fehler in der Metrik, das ist das, was die Metrik aussagt.

Googles Begründung für die Wahl dieses Perzentils ist veröffentlicht und sehenswert, denn es erklärt, warum der Schwanz absichtlich ist: Das 75. Perzentil stellt sicher, dass eine Mehrheit der Besuche das angestrebte Leistungsniveau erlebt, während höhere Perzentile gelegentliche schlechte Erfahrungen zu stark gewichten. Mit hundert Besuchen erfordert das Verschieben des Riegels zum 75. Perzentil, dass fünfundzwanzig davon betroffen sind, bevor der Score sich ändert. Beim 95. sind es fünf.

Die Design-Entscheidung ist also, robust gegen Ausreißer zu sein. Die Kosten dieser Robustheit sind, dass ein echter, wiederholbarer Fehler, der ein Fünftel Ihrer Besucher betrifft, auf unbestimmte Zeit unter einem bestandenen Score liegen kann.

Warum Ihre eigene Erfahrung nie die Messung ist

Öffnen Sie Ihre eigene Seite und Sie sind fast sicher in den komfortablen drei Vierteln, und nicht aus Glück. Sie sitzen an einer Maschine, die für Entwicklungsarbeit ausgewählt wurde, mit einer Verbindung, die Sie bezahlen, mit einem bereits warmen Cache, bereits heruntergeladenen Schriftarten und bereits installiertem Service Worker, wahrscheinlich nahe an einem Edge-Standort, der Sie in einstelligen Millisekunden bedient.

Das langsame Viertel ist jemand auf einem Mittelklasse-Handy in einem Zug mit einem kalten Cache. Das sind keine Ausreißer. Das ist der Teil der Messung, den Sie von Ihrem Schreibtisch nicht erreichen können, was auch der Teil ist, den der Score tolerieren soll.

Deshalb ist “bei mir funktioniert es einwandfrei” eine wahre Aussage und kein Beweis für etwas, und warum eine Seite sich langsam anfühlen kann, während jede Server-Metrik sagt, dass sie schnell ist.

Was ein Field-Score nicht tun kann

Core Web Vitals, wie Google sie bewertet, sind Field-Daten: ein Aggregat über eine Population echter Besuche. Das ist das, was sie sehenswert macht, und es ist auch die Grenze.

Ein Aggregat kann keine Frage über einen einzelnen Besuch beantworten. Wenn eine bestimmte Person sagt, die Kasse war am Dienstagmittag unbrauchbar, sagt Ihnen kein Perzentil, was mit ihnen passiert ist, und eine Seite, die besteht, sagt Ihnen nur, dass mindestens drei Viertel der Besuche in Ordnung waren. Die Beschwerde kommt sehr wahrscheinlich aus dem Viertel, das der Schwellenwert absorbieren sollte.

Die beiden Dinge erledigen also unterschiedliche Aufgaben und keines ersetzt das andere. Der Field-Score sagt Ihnen, ob die Erfahrung im Allgemeinen akzeptabel ist und wo Sie Ingenieurzeit ausgeben sollten. Ein erfasster Besuch sagt Ihnen, was mit der Person vor Ihnen passiert ist. Nach dem ersten zu greifen, wenn jemand nach dem zweiten fragt, ist wie ein echter Bericht als nicht reproduzierbar geschlossen wird.

Was Sie mit einer Beschwerde über Langsamkeit tun

Drei Schritte, in der Reihenfolge, die am wenigsten kostet.

Lesen Sie die Wörter für die Metrik. Wartend, nicht ansprechend oder beweglich. Das allein wählt aus, welche der drei zu untersuchen ist und schließt die anderen zwei aus.

Erhalten Sie den einen Besuch anstelle des Aggregats. Wann es passiert ist, auf welchem Gerät und mit welcher Verbindung, und was die Seite zu der Zeit tat. Ein Perzentil kann nicht auf eine Person eingegrenzt werden, aber eine erfasste Sitzung ist bereits eine.

Überprüfen Sie dann den Field-Score, um herauszufinden, ob Sie den Schwanz oder die Mitte verfolgen. Falls die Seite besteht und die Beschwerde real ist, befinden Sie sich im eingebauten Viertel, und das ändert die Entscheidung eher, als sie zu beenden.

In einem Absatz

Core Web Vitals sind LCP bei 2500 ms, INP bei 200 ms und CLS bei 0,1, bewertet beim 75. Perzentil der Ladevorgänge und aufgeteilt zwischen Mobile und Desktop, wobei FID zugunsten von INP eingezogen wurde. Jede ordnet sich einer Beschwerde zu, die eine Person tatsächlich macht: Warten, zweimal tippen oder auf die falsche Schaltfläche drücken. Und das Perzentil bedeutet, dass ein Viertel Ihrer Besuche schlechter sein darf als Ihr bestandener Score, deshalb sind ein grünes Dashboard und ein unzufriedener Nutzer normalerweise beide korrekt, und deshalb braucht die Lösung einen erfassten Besuch statt eines besseren Durchschnitts.