Google bewertet die Nutzererfahrung einer Seite mit drei Kennzahlen, den Core Web Vitals. Sie beantworten drei einfache Fragen: Wann ist der Hauptinhalt sichtbar? Reagiert die Seite schnell auf Klicks und Tippen? Springt das Layout beim Laden herum? Wer diese Werte im grünen Bereich hält, hat zufriedenere Besucher, oft eine bessere Conversion-Rate und erfüllt nebenbei ein Rankingsignal.
Die drei Kennzahlen und ihre Grenzwerte
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Ladezeit des größten sichtbaren Elements | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP (Interaction to Next Paint) | Reaktionszeit auf Eingaben | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Unerwartete Layoutverschiebungen | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Entscheidend ist das 75. Perzentil: Eine URL gilt nur dann als „gut“, wenn mindestens 75 % der Seitenaufrufe den Grenzwert einhalten. Mobile und Desktop werden getrennt bewertet. Diese Werte gelten in Googles Dokumentation unverändert auch im Jahr 2026.
Felddaten vs. Labordaten
- Felddaten stammen von echten Chrome-Nutzern (Chrome UX Report, CrUX) und werden über 28 Tage gesammelt. Diese Daten nutzt Google für die Bewertung; Sie sehen sie in der Search Console unter „Core Web Vitals“ und oben im PageSpeed-Insights-Bericht.
- Labordaten entstehen bei einer simulierten Messung (Lighthouse) mit festgelegtem Gerät und gedrosselter Verbindung. Sie sind reproduzierbar und ideal zur Fehlersuche, spiegeln aber nicht Ihre echten Besucher wider.
Wichtig: INP lässt sich im Labor nicht direkt messen, weil dort niemand klickt. Lighthouse zeigt ersatzweise die Total Blocking Time (TBT), die eng mit INP zusammenhängt. Kleine Websites mit wenig Traffic haben oft gar keine CrUX-Daten; dann bleiben nur Labormessungen. Einen schnellen Laborwert erhalten Sie mit unserem Website-Geschwindigkeitstest.
LCP verbessern
Das LCP-Element ist meist ein Hero-Bild, ein großes Produktfoto oder eine Überschrift. Die Ladezeit setzt sich aus vier Teilen zusammen: Serverantwort (TTFB), Verzögerung bis zum Start des Ladens, Ladedauer der Ressource und Rendern.
- Serverantwort beschleunigen: Seiten-Caching, schnellerer Hoster, CDN. Eine TTFB über 800 ms macht ein gutes LCP fast unmöglich.
- LCP-Bild früh entdecken lassen: Das Bild gehört als
<img>ins HTML, nicht als CSS-Hintergrund oder per JavaScript nachgeladen. - Priorität setzen und Lazy Loading für dieses eine Bild abschalten:
<img src="/hero-1200.avif" width="1200" height="600"
fetchpriority="high" alt="Werkstatt von innen">- Bild verkleinern: AVIF oder WebP, passende Abmessungen,
srcsetfür Mobilgeräte – etwa mit dem Bildkompressor. Mehr dazu im Ratgeber Bilder fürs Web optimieren. - Render-blockierendes CSS und JavaScript reduzieren: kritisches CSS inline, Skripte mit
defer. - Webfonts lokal hosten und mit
font-display: swapladen – das spart Verbindungen zu Drittservern und ist auch aus Datenschutzsicht (DSGVO) die sauberere Lösung als das Einbinden von Google Fonts über deren Server.
INP verbessern
INP misst die Zeit von einer Interaktion (Klick, Tippen, Tastendruck) bis zum nächsten sichtbaren Bildaufbau. Schlechte Werte entstehen fast immer durch zu viel JavaScript auf dem Hauptthread.
- Lange Tasks aufteilen: Aufgaben über 50 ms blockieren den Browser. Arbeit in kleinere Teile zerlegen und dazwischen dem Browser Luft geben (z. B. mit
scheduler.yield()odersetTimeout). - Drittanbieter-Skripte prüfen: Chat-Widgets, Tag-Manager, Tracking und Consent-Banner sind häufige Bremsen. Laden Sie nur, was Sie wirklich brauchen, und erst nach Einwilligung.
- Event-Handler schlank halten: Erst sichtbares Feedback geben, schwere Berechnungen danach erledigen.
- DOM-Größe begrenzen: Sehr große Seiten mit Tausenden Elementen machen jedes Neuzeichnen teuer.
- Frameworks: Bei React, Vue & Co. unnötige Re-Renderings vermeiden und Hydration reduzieren.
CLS verbessern
CLS summiert unerwartete Verschiebungen sichtbarer Elemente. Klassiker: Sie wollen auf einen Link tippen, und plötzlich schiebt sich ein Banner davor.
- Breite und Höhe für Bilder und Videos angeben (
width/heightoderaspect-ratio), damit der Platz reserviert ist. - Platz für Werbung, Embeds und Cookie-Banner reservieren oder Banner als Overlay ohne Verschiebung einblenden.
- Keine Inhalte oberhalb bestehender Inhalte einfügen, außer als direkte Reaktion auf eine Nutzeraktion.
- Webfonts abstimmen: Fallback-Schrift mit
size-adjustangleichen, damit der Textwechsel nichts verschiebt. - Animationen mit
transformstatt mittop,leftoderheight.
Messen, ändern, erneut messen
- Search Console öffnen und betroffene URL-Gruppen identifizieren.
- Einzelne Seiten im Labor testen, um die Ursache zu finden.
- Eine Änderung nach der anderen umsetzen und dokumentieren.
- Geduld: Da Felddaten über 28 Tage gesammelt werden, zeigt die Search Console Verbesserungen erst nach einigen Wochen. Mit „Korrektur überprüfen“ starten Sie eine neue Bewertung.
Einen umfassenden Plan für alle Geschwindigkeitsthemen finden Sie im Ratgeber Website schneller machen.
Ein typisches Beispiel
Ein Onlineshop für Fahrradzubehör hat mobil ein LCP von 4,1 Sekunden (schlecht), INP von 310 ms und CLS von 0,18. Die Analyse zeigt: Das Hero-Bild ist ein 1,8-MB-JPEG mit Lazy Loading, ein Chat-Widget und drei Tracking-Skripte laden sofort, und der Cookie-Banner schiebt den Inhalt nach unten. Die Maßnahmen: Hero-Bild als AVIF mit 160 KB und fetchpriority="high", Chat erst bei Klick, Tracking erst nach Einwilligung, Banner als Overlay. Vier Wochen später liegen die Felddaten bei 2,2 Sekunden, 170 ms und 0,04 – alle drei im grünen Bereich.
Tools im Überblick
- PageSpeed Insights: kombiniert Felddaten (falls vorhanden) und Lighthouse-Labordaten für eine URL.
- Search Console: Felddaten gruppiert für die ganze Website, getrennt nach Mobil und Desktop.
- Chrome DevTools (Performance): zeigt lange Tasks, Layoutverschiebungen und das LCP-Element im Detail.
- web-vitals-Bibliothek: misst die Werte bei echten Besuchern auf Ihrer eigenen Website, etwa zur Auswertung in einem datenschutzfreundlichen Analytics-Tool.
Checkliste
- LCP-Bild im HTML, mit
fetchpriority="high", ohne Lazy Loading, in AVIF/WebP. - TTFB unter 800 ms dank Caching und gutem Hosting.
- Keine langen JavaScript-Tasks; Drittanbieter-Skripte auf das Nötige reduziert.
- Alle Bilder, Videos und Embeds mit festen Abmessungen.
- Cookie-Banner verschiebt kein Layout.
- Felddaten in der Search Console monatlich kontrolliert.