lakexyde web 1935737 1920

Core Web Vitals 2026: Was moderne Webseiten technisch leisten müssen

Aktualisiert am 9. Oktober 2026

Kurzantwort

Die Core Web Vitals bestehen 2026 weiterhin aus drei Metriken: LCP (Laden, gut bis 2,5 s), INP (Reaktionsfähigkeit, gut bis 200 ms) und CLS (visuelle Stabilität, gut bis 0,1). Maßgeblich ist das 75. Perzentil der echten Nutzerdaten aus dem Chrome User Experience Report (CrUX), getrennt nach Mobil und Desktop. Ein guter Lighthouse-Score allein reicht deshalb nicht. Die Grenzwerte sind seit der Einführung von INP im März 2024 unverändert.

Die drei Metriken und ihre Grenzwerte

Metrik Misst Gut Verbesserungswürdig Schlecht
LCP – Largest Contentful Paint Zeit bis das größte sichtbare Element gerendert ist ≤ 2,5 s 2,5–4 s > 4 s
INP – Interaction to Next Paint Verzögerung zwischen Interaktion und nächstem Frame ≤ 200 ms 200–500 ms > 500 ms
CLS – Cumulative Layout Shift unerwartete Layoutverschiebungen ≤ 0,1 0,1–0,25 > 0,25

Eine URL oder Seitengruppe „besteht“ nur, wenn alle drei Werte im 75. Perzentil im grünen Bereich liegen.

Was sich seit 2024 geändert hat

  • März 2024: INP hat First Input Delay (FID) ersetzt. FID maß nur die Verzögerung der ersten Eingabe. INP berücksichtigt praktisch alle Klicks, Taps und Tastatureingaben einer Sitzung und wertet die langsamste (bei vielen Interaktionen ein hohes Perzentil) aus.
  • Dezember 2025: Mit Safari 26.2 unterstützen alle großen Browser-Engines die APIs für LCP und INP. Laut web.dev bleibt CrUX aber auf Chrome-Nutzer beschränkt. Wer wissen will, wie Safari- und Firefox-Nutzer die Seite erleben, braucht ein eigenes Real User Monitoring (RUM).
  • 2026: Chrome testet die Soft Navigations API in einem letzten Origin Trial (Chrome 147 bis 149). Sie soll Core Web Vitals auch für Seitenwechsel in Single-Page-Apps messbar machen. Laut Chrome-Team ist noch nicht entschieden, ob und wie diese Daten in CrUX einfließen.

Behauptungen, Google habe 2026 die Grenzwerte verschärft, findest du auf vielen Blogs. In der offiziellen Dokumentation auf web.dev ist das nicht nachvollziehbar (Stand September 2026).

LCP optimieren: das Hauptelement schneller laden

Das LCP-Element ist meist ein Hero-Bild, ein Video-Poster oder ein großer Textblock. Chrome DevTools und PageSpeed Insights zeigen dir, welches Element es ist, und teilen die Zeit in vier Teile auf:

  1. Time to First Byte (TTFB): Serverantwort. Hier helfen Caching, ein CDN und schnelleres Hosting.
  2. Ladeverzögerung der Ressource: Wie spät entdeckt der Browser das Bild?
  3. Ladedauer der Ressource: Wie groß ist die Datei?
  4. Render-Verzögerung: Blockieren CSS oder JavaScript das Zeichnen?

Die wirksamsten Maßnahmen für das LCP-Bild:

<!-- Hero-Bild: kein Lazy Loading, hohe Priorität, modernes Format -->
<img src="/img/hero.avif" width="1200" height="630"
     fetchpriority="high" alt="Produktansicht">

<!-- Nur wenn das Bild erst per CSS/JS geladen wird: früh vorladen -->
<link rel="preload" as="image" href="/img/hero.avif" fetchpriority="high">

Ein häufiger Fehler in WordPress-Themes: loading="lazy" auf dem ersten Bild. Das verzögert genau das Element, das LCP misst. Außerdem wichtig: Bilder in passender Größe ausliefern (srcset), kritisches CSS inline setzen und Skripte mit defer laden.

Um die technische Umsetzung nicht selbst stemmen zu müssen, kann man zumeist mit einer spezialisierten Webagentur aus der Schweiz zusammenarbeiten, die Performance-Audits mit strukturierten Optimierungsprozessen verbindet. Wer selbst optimiert, sollte beim Server anfangen, denn eine TTFB von über einer Sekunde lässt sich im Frontend kaum wieder aufholen. Hintergründe zu Hosting und Skalierung findest du in unserem Artikel über skalierbare Cloud-Lösungen.

INP optimieren: den Main Thread freihalten

INP wird schlecht, wenn der Browser nach einem Klick nicht schnell zeichnen kann, weil der Main Thread blockiert ist. Typische Ursachen:

  • lange JavaScript-Tasks (über 50 ms) beim Seitenaufbau oder im Event-Handler
  • zu viele Third-Party-Skripte (Tag-Manager, Chat-Widgets, Ads, Consent-Tools)
  • teures Re-Rendering in Frameworks, große DOM-Bäume

Die wichtigste Technik ist, Arbeit aufzuteilen und dem Browser zwischendurch das Zeichnen zu erlauben. scheduler.yield() ist dafür gedacht, aber noch nicht in allen Browsern verfügbar (laut MDN nicht „Baseline“). Nutze deshalb eine Fallback-Funktion:

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise(resolve => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();          // sofort sichtbares Feedback
  await yieldToMain();    // Browser darf jetzt zeichnen
  await filterLargeList(); // teure Arbeit danach
});

Außerdem hilft es, rechenintensive Aufgaben in Web Worker auszulagern, Drittanbieter-Skripte kritisch auszumisten und Event-Handler zu entprellen (Debounce bei Eingabefeldern).

CLS optimieren: nichts darf springen

Layoutverschiebungen entstehen, wenn Inhalte nachträglich Platz beanspruchen. Die häufigsten Auslöser und Lösungen:

Ursache Lösung
Bilder/Videos ohne Maße width und height oder CSS aspect-ratio setzen
nachgeladene Werbung, Embeds festen Platzhalter mit Mindesthöhe reservieren
Web Fonts ändern die Textbreite Fonts vorladen, font-display: optional oder Fallback-Font per size-adjust angleichen
Cookie-Banner schiebt Inhalte Banner als Overlay (fixed/sticky) statt oben in den Seitenfluss einfügen
Animationen über top/height stattdessen transform animieren 
.ad-slot { min-height: 250px; }
.video-embed { aspect-ratio: 16 / 9; width: 100%; }

Seiten, die den Back/Forward-Cache (bfcache) nutzen können, profitieren doppelt: Beim Zurück-Navigieren lädt die Seite praktisch sofort und ohne Verschiebungen. Chrome DevTools zeigt unter „Application > Back/forward cache“, was das verhindert.

Messen: Felddaten schlagen Labordaten

Datenquelle Art Wofür
Search Console (Bericht „Core Web Vitals“) Felddaten aus CrUX, nach URL-Gruppen Überblick, welche Seitentypen Probleme haben
PageSpeed Insights Felddaten (oben) plus Lighthouse-Labortest Einzel-URL prüfen
Lighthouse / DevTools Labordaten Ursachen finden, Änderungen testen
RUM (z. B. web-vitals-Bibliothek) eigene Felddaten, alle Browser echte Nutzer inkl. Safari und Firefox

Beachte: CrUX-Daten sind ein gleitender 28-Tage-Zeitraum. Nach einer Optimierung dauert es also rund vier Wochen, bis sich die Werte in Search Console vollständig ändern. INP lässt sich im Labor nur eingeschränkt nachstellen, weil es echte Interaktionen braucht.

Audit in 6 Schritten

  1. In der Search Console den Bericht „Core Web Vitals“ öffnen, zuerst Mobil prüfen.
  2. Die schlechteste URL-Gruppe und die betroffene Metrik notieren.
  3. Eine Beispiel-URL in PageSpeed Insights testen und LCP-Element bzw. Diagnose ansehen.
  4. Ursache in DevTools eingrenzen (Performance-Panel, Netzwerk, Layout-Shift-Regionen).
  5. Maßnahme umsetzen, zuerst die größten Hebel: TTFB, LCP-Bild, Third-Party-Skripte.
  6. In Search Console „Korrektur überprüfen“ starten und die 28 Tage abwarten.

Viele Probleme entstehen schon bei der Wahl von CMS, Theme und Baukasten. Einen Überblick über Werkzeuge gibt unser Artikel Die besten Tools für die Webseiten-Erstellung.

FAQ

Sind Core Web Vitals ein Rankingfaktor?

Ja, Google nutzt sie als Teil der Seitennutzererfahrung in seinen Ranking-Systemen. Relevanz und Qualität des Inhalts wiegen aber schwerer. Gute Werte gleichen schwachen Content nicht aus.

Gibt es 2026 neue Grenzwerte?

Nein. Laut web.dev gelten weiterhin 2,5 s (LCP), 200 ms (INP) und 0,1 (CLS) im 75. Perzentil.

Warum ist mein Lighthouse-Score gut, aber die Search Console rot?

Lighthouse simuliert ein einzelnes Gerät unter Laborbedingungen. Die Search Console zeigt echte Nutzerdaten, oft von langsameren Smartphones und Netzen.

Meine Seite hat zu wenig Traffic für CrUX-Daten. Was nun?

Dann gibt es keine Felddaten in PageSpeed Insights. Miss selbst mit der web-vitals-Bibliothek oder einem RUM-Tool und nutze Lighthouse für die Ursachenanalyse.

Zählen Safari-Nutzer mit?

Nicht für CrUX. Safari kann LCP und INP seit Version 26.2 zwar messen, die Daten landen aber nur in deinem eigenen Monitoring.

Auch interessant

Menü