Core Web Vitals 2026: LCP, INP und CLS verständlich erklärt

Die drei Metriken und ihre Grenzwerte

Für jede Metrik gibt es einen Grenzwert für „gut“ und einen für „schlecht“. Eine Seite besteht, wenn sie beim 75. Perzentil echter Besuche im guten Bereich liegt – getrennt gemessen für Mobil und Desktop.

• Largest Contentful Paint (LCP): gut bei höchstens 2,5 s, schlecht über 4 s. Die Metrik markiert den Zeitpunkt, an dem das größte Bild oder der größte Textblock im sichtbaren Bereich dargestellt wird.
• Interaction to Next Paint (INP): gut bei höchstens 200 ms, schlecht über 500 ms. Gemessen wird die Verzögerung zwischen einem Tippen, Klick oder Tastendruck und der nächsten sichtbaren Aktualisierung – über den gesamten Besuch hinweg.
• Cumulative Layout Shift (CLS): gut bei höchstens 0,1, schlecht über 0,25. Die Metrik summiert unerwartete Layoutverschiebungen, etwa wenn Text springt, weil ein Bild oder Banner verspätet lädt.

INP hat im März 2024 First Input Delay (FID) als Core Web Vital abgelöst. Jedes Tool und jeder Bericht, der Sie noch nach FID bewertet, ist veraltet.

Felddaten und Labordaten im Vergleich

Felddaten stammen von echten Chrome-Nutzern aus dem Chrome UX Report (CrUX) und werden über die vorangegangenen 28 Tage zusammengefasst. Diese Daten verwendet Google. Kleine Websites haben oft keine Felddaten, weil der Traffic für eine Veröffentlichung nicht ausreicht.

Labordaten stammen aus einem einzelnen simulierten Seitenaufruf in Lighthouse, meist auf einem gedrosselten Mittelklasse-Smartphone. Sie sind reproduzierbar und ideal zur Fehlersuche, können INP aber nicht messen, weil niemand mit der Seite interagiert. Lighthouse zeigt stattdessen die Total Blocking Time (TBT) an – einen Wert, der gut mit INP-Problemen korreliert.

Nutzen Sie die Labordaten, um Ursachen zu finden, und die Felddaten, um zu bestätigen, dass eine Korrektur bei echten Besuchern wirkt. Felddaten ändern sich nur allmählich, weil sich das 28-Tage-Fenster erst vollständig erneuern muss.

So verbessern Sie LCP

Die meisten schlechten LCP-Werte haben eine von vier Ursachen: eine langsame Serverantwort, ein render-blockierendes Stylesheet oder Skript, ein Hero-Bild, das zu spät entdeckt wird, oder ein Bild, das schlicht zu groß ist.

• Halten Sie die Serverantwortzeit (TTFB) mit Seiten-Caching und einem CDN niedrig.
• Laden Sie das Hero-Bild nicht per Lazy Loading. Geben Sie ihm fetchpriority="high" und laden Sie es per Preload, wenn es über CSS eingebunden ist.
• Liefern Sie das Hero-Bild in einem modernen Format (AVIF oder WebP) in der tatsächlich angezeigten Größe aus, mit srcset für verschiedene Bildschirme.
• Binden Sie das kritische CSS inline ein oder halten Sie das Haupt-Stylesheet klein, und verzögern Sie Skripte, die für die erste Ansicht nicht nötig sind.
• Ersetzen Sie Hero-Slider und automatisch startende Videos nach Möglichkeit durch ein einzelnes aussagekräftiges statisches Bild.

So verbessern Sie INP

Ein schlechter INP-Wert bedeutet fast immer, dass der Main Thread beschäftigt ist, wenn der Nutzer interagiert. Die übliche Ursache ist umfangreiches JavaScript, und Skripte von Drittanbietern machen oft den größten Anteil davon aus.

• Entfernen Sie Skripte, die Sie nicht mehr nutzen – vor allem Überbleibsel alter Apps, Plugins und Tag-Manager-Experimente.
• Laden Sie Chat-Widgets, Heatmaps und Bewertungs-Widgets erst, wenn die Seite interaktiv ist – oder sogar erst, wenn der Nutzer sie öffnet.
• Teilen Sie lange Tasks in kleinere auf und halten Sie Klick-Handler schlank, damit der Browser nach jeder Interaktion schnell neu zeichnen kann.
• Vermeiden Sie riesige DOM-Bäume: Sehr große Menüs und Produktraster verlangsamen jede Aktualisierung.

So verbessern Sie CLS

Layoutverschiebungen entstehen, wenn der Browser erst nach dem Laden weiß, wie viel Platz ein Element braucht.

• Setzen Sie width und height (oder aspect-ratio) für jedes Bild, jedes Video und jeden iFrame.
• Reservieren Sie Platz für Werbeflächen, Cookie-Banner und Einbettungen, statt Inhalte nach unten zu schieben, sobald diese erscheinen.
• Verwenden Sie font-display: swap mit einer Ersatzschrift ähnlicher Größe oder laden Sie die Haupt-Webschrift per Preload vor, um springenden Text zu reduzieren.
• Fügen Sie niemals Inhalte oberhalb bestehender Inhalte ein, sofern der Nutzer das nicht ausgelöst hat.

Was der Sitequiry-Bericht zeigt

Sitequiry führt Google PageSpeed Insights für Mobil und Desktop aus und zeigt LCP, FCP, TBT und CLS auf Skalen mit den oben genannten Grenzwerten – zusammen mit dem Ladeverlauf in Einzelbildern und dem Seitengewicht nach Ressourcentyp. Wenn Google CrUX-Felddaten für die URL oder die gesamte Domain (Origin) hat, nutzt der Bericht diese ebenfalls. Ist PageSpeed nicht verfügbar, weist der Bericht darauf hin und kennzeichnet die Ladezeit-Bewertung als Schätzung, statt Zahlen zu erfinden.

Häufige Fragen