Core Web Vitals sind drei von Google definierte Metriken, die das tatsächliche Nutzererlebnis auf Webseiten messen: Largest Contentful Paint (LCP) für das Laden, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Eine Seite besteht, wenn das 75. Perzentil der Aufrufe alle drei Grenzwerte erfüllt.
Was sind Core Web Vitals?
Core Web Vitals sind eine kleine Gruppe von Metriken, die Google im Rahmen der Initiative Web Vitals definiert, um zu beschreiben, wie Nutzer eine Webseite erleben. Jede Metrik deckt eine Dimension ab: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf Eingaben reagiert und wie stabil das Layout während des Ladens bleibt. Google nutzt die Core Web Vitals als Teil seiner Page-Experience-Signale in der Suche, ihr eigentlicher Wert ist aber operativ: Sie machen aus „die Seite fühlt sich langsam an“ messbare Zahlen.
Die Auswahl wird regelmäßig überprüft. Im März 2024 hat Interaction to Next Paint (INP) den First Input Delay (FID) als Metrik für die Reaktionsfähigkeit abgelöst. FID maß nur die Verzögerung der ersten Interaktion, INP berücksichtigt die Latenz aller Interaktionen während eines Besuchs.
Die drei Core Web Vitals und ihre Grenzwerte
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP Largest Contentful Paint | Zeit, bis das größte Bild oder der größte Textblock im Viewport gerendert ist | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP Interaction to Next Paint | Latenz von der Eingabe (Klick, Tippen, Taste) bis zum nächsten gezeichneten Frame | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS Cumulative Layout Shift | Unerwartete Layoutverschiebungen als einheitenloser Wert | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Bewertet werden diese Grenzwerte am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Eine Seite besteht nur, wenn mindestens 75 % der Besuche den guten Grenzwert jeder Metrik erreichen. Das 75. Perzentil statt des Mittelwerts stellt sicher, dass die meisten Nutzer ein gutes Erlebnis haben, nicht nur jene mit schnellen Geräten.
Felddaten vs. Labordaten
Core Web Vitals lassen sich auf zwei Wegen messen. Felddaten stammen von echten Nutzern auf echten Geräten, etwa über Real User Monitoring oder den Chrome User Experience Report (CrUX) von Google. Labordaten stammen aus kontrollierten Testläufen mit Werkzeugen wie Lighthouse oder skriptgesteuerten synthetischen Prüfungen. Labortests sind reproduzierbar und eignen sich, um Regressionen vor einem Release zu erkennen, können aber die Vielfalt an Geräten, Netzen und Nutzerverhalten nicht abbilden. Vor allem INP hängt von echten Interaktionen ab und ist in erster Linie eine Feldmetrik; Labortools nutzen Ersatzgrößen wie die Total Blocking Time.
Beispiel: Core Web Vitals im Browser messen
Die Open-Source-Bibliothek web-vitals von Google meldet die Metriken aus echten Sitzungen. Ein beispielhaftes Setup, das sie an einen Sammel-Endpunkt sendet:
import { onLCP, onINP, onCLS } from "web-vitals";
function send(metric) {
navigator.sendBeacon("/rum", JSON.stringify({
name: metric.name, value: metric.value,
rating: metric.rating, page: location.pathname
}));
}
onLCP(send); onINP(send); onCLS(send);Pro Seitenvorlage und Geräteklasse aggregiert ergeben diese Werte die entscheidenden p75-Zahlen. In Verbindung mit Backend-Daten wird sichtbar, ob ein langsamer LCP vom Server verursacht wird, etwa durch eine hohe Time to First Byte, oder vom Frontend.
Bei der Auswertung sind zwei Details wichtig. LCP und CLS stehen erst fest, wenn die Seite ausgeblendet wird oder der Nutzer interagiert; die Bibliothek meldet sie daher unter Umständen spät oder aktualisiert sie. Senden Sie stets den endgültigen Wert. INP meldet die langsamste Interaktion eines Besuchs, wobei auf Seiten mit sehr vielen Interaktionen einzelne Ausreißer ignoriert werden. Ein einziges langsames Menü oder ein träger Filter kann so den Wert einer ganzen Seite bestimmen. Prüfen Sie deshalb, welche Elemente die schlechtesten Interaktionen auslösen.
Core Web Vitals verbessern
- LCP: Serverantwortzeit senken, das LCP-Bild vorladen, Bilder in passender Größe und komprimiert ausliefern, renderblockierendes CSS und JavaScript vermeiden und ein CDN nutzen.
- INP: lange JavaScript-Tasks aufteilen, nicht kritische Skripte verzögert laden, Drittanbieter-Code reduzieren und Event-Handler kurz halten, damit der Browser schnell zeichnen kann.
- CLS: explizite Breite und Höhe für Bilder und Einbettungen angeben, Platz für Werbung und Banner reservieren und nach dem Laden keine Inhalte oberhalb bestehender Inhalte einfügen.
Häufige Fehler
- Nur Laborwerte zu optimieren, während echte Nutzer auf Mittelklasse-Smartphones weiterhin schlechte Werte sehen.
- Seitenweite Durchschnittswerte statt p75 je Seitenvorlage und Gerätetyp zu betrachten.
- Weiterhin FID zu verfolgen, das kein Core Web Vital mehr ist.
- Frontend-Metriken isoliert zu betrachten, ohne sie mit Backend-Latenz oder Releases zu verknüpfen.
Wie Obseria hilft
Das Real User Monitoring von Obseria erfasst LCP, INP und CLS aus echten Sitzungen und weist sie am 75. Perzentil nach Seite, Gerät und Region aus. Sitzungen mit schlechten Werten lassen sich per Session Replay nachvollziehen, und Frontend-Spans sind mit Backend-Traces verbunden. So sehen Sie, ob eine langsame Seite am Browser, am Netz oder an einem bestimmten Service liegt.