Core Web Vitals 2026: Warum Ihre Website Rankings verliert

Wenn Ihre Website seit Anfang 2024 spürbar weniger organischen Traffic bekommt, liegt das nicht zwingend an einem Google-Algorithmus-Update. Wahrscheinlicher ist: INP hat FID ersetzt. Und mit dieser Änderung sind über Nacht zehntausende Websites von "alles im grünen Bereich" zu "Performance-Problemen" gewechselt.

Core Web Vitals sind seit 2021 ein offizieller Ranking-Faktor bei Google. 2024 wurde der schwächste der drei Werte — First Input Delay (FID) — durch Interaction to Next Paint (INP) ersetzt. Der Unterschied klingt technisch, hat aber massive Folgen: INP misst alle Interaktionen während eines Besuchs, nicht nur die erste. Das deckt Probleme auf, die FID lange versteckt hat.

In diesem Artikel zeigen wir, was die drei Vitals 2026 wirklich messen, welche Schwellenwerte Google ansetzt, mit welchen Tools Sie messen — und wie Sie die häufigsten Probleme in Next.js, WordPress und klassischen HTML-Setups beheben.

Warum es Rankings beeinflusst — und wie stark

Google hat seit 2021 mehrfach klargestellt, dass Core Web Vitals ein "Tiebreaker" sind: Bei zwei Seiten mit ähnlicher inhaltlicher Relevanz gewinnt die schnellere. In der Praxis sehen wir bei Audit-Kunden zwei Muster:

• Bei umkämpften Keywords — Anwalt, Versicherung, lokale Dienstleister — bedeuten 100 ms LCP-Vorsprung oft 1–2 Positionen im Ranking.
• Bei langen Tail-Anfragen mit weniger Konkurrenz ist der Effekt geringer, aber nicht null. Hier wirken Vitals indirekter, über Nutzerverhalten (Bounce, Verweildauer).

Wichtiger als die direkten Rankings sind aber die indirekten Effekte: Eine Seite mit schlechtem CLS hat 24 % mehr Bouncing als eine mit gutem CLS (Quelle: Chrome UX Report Aggregat 2024). Ein hoher INP korreliert mit niedrigerer Conversion-Rate, besonders bei Formularen. Sie verlieren also nicht nur Rankings, sondern auch das, was Sie mit Rankings bekommen würden.

Die drei Metriken im Detail

LCP — Largest Contentful Paint

Was misst es: Die Zeit vom Beginn des Seitenaufrufs bis zum Rendern des größten sichtbaren Elements. Meist ist das ein Hero-Bild, ein Hintergrund oder eine große Headline.

Schwellenwerte 2026:

Wichtig: Google bewertet das 75. Perzentil Ihrer Nutzer. Wenn Ihr Median 1,8 Sek. ist, aber 30 % Ihrer Nutzer 4,2 Sek. erleben, gelten Sie als langsam — egal wie schnell Sie im eigenen Test sind.

CLS — Cumulative Layout Shift

Was misst es: Die Summe aller unerwarteten Layout-Verschiebungen während der Seitenbenutzung. Ein Banner, das nachträglich eingeblendet wird und den restlichen Inhalt nach unten schiebt, ist der klassische CLS-Killer.

Schwellenwerte 2026:

CLS ist die Metrik, die am ärgerlichsten für Nutzer ist — Sie kennen das Gefühl, wenn Sie auf einen Button klicken wollen und plötzlich einen anderen treffen, weil sich der Inhalt verschoben hat. Genau das misst CLS.

INP — Interaction to Next Paint (seit März 2024)

Was misst es: Die längste Verzögerung zwischen einer Nutzer-Interaktion (Klick, Tap, Tastatureingabe) und dem nächsten visuellen Update der Seite. INP ersetzte FID, weil FID nur die erste Interaktion gemessen hat — und damit fast immer den optimistischen Fall.

Schwellenwerte 2026:

Hier sind viele WordPress-Sites mit Plugins und JavaScript-Heavy-Themes 2024 dramatisch eingebrochen. Eine Seite, die mit FID grün war, kann mit INP schlechter sein als der Durchschnitt — weil INP die kumulative Last des JavaScripts während der gesamten Sitzung misst.

Wie Sie messen — die richtigen Tools

Ein häufiger Fehler: Vitals werden im eigenen Browser gemessen, mit schnellem Internet, leerem Cache und ohne den realen Plugin-Stack des Endkunden. Diese Werte sind irrelevant. Google rankt Sie auf Basis von Felddaten — was reale Nutzer auf realen Geräten erleben.

Die Reihenfolge der Tools, in der wir bei Audits arbeiten:

1. Google Search Console → Core Web Vitals. Echte Felddaten Ihrer Nutzer, aggregiert nach URL-Gruppen. Hier sehen Sie, welche Seiten tatsächlich problematisch sind.
2. PageSpeed Insights (pagespeed.web.dev). Kombiniert Felddaten (oben) mit Lab-Daten (synthetischer Test). Gibt konkrete Empfehlungen pro Metrik.
3. Chrome DevTools → Performance Insights. Lokale Diagnose mit Throttling. Identifiziert das genaue Element, das LCP verursacht.
4. Web Vitals Browser Extension. Zeigt Werte live während des Surfens — schnell, niederschwellig.

LCP-Probleme beheben

LCP-Probleme haben in 90 % der Fälle eine von vier Ursachen:

a) Hero-Bild lädt zu langsam

Das größte sichtbare Element ist meist ein Bild. Wenn es nicht priorisiert geladen wird, verzögert sich LCP automatisch.

In Next.js mit dem <Image>-Component ist die Lösung das priority-Attribut für das Above-the-Fold-Bild:

import Image from 'next/image'
 
export default function Hero() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero"
      width={1600}
      height={900}
      priority
      sizes="(max-width: 768px) 100vw, 1600px"
    />
  )
}

Das priority-Flag setzt automatisch fetchpriority="high" und entfernt das standard-Lazy-Loading. Ohne dieses Flag verzögern moderne Browser Hero-Bilder zugunsten anderer Ressourcen — was LCP zerstört.

b) Web Fonts blockieren das Rendering

Wenn Ihre H1 in einer Custom Font geschrieben ist und der Browser auf den Font wartet, bevor er rendert, entsteht ein FOIT (Flash of Invisible Text). LCP zählt erst, wenn der Text sichtbar wird.

Fix: font-display: swap setzen (zeigt Fallback-Font sofort an, tauscht später) und kritische Fonts vorladen:

<link
  rel="preload"
  href="/fonts/Outfit-Variable.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

In Next.js 15 mit next/font passiert das automatisch — ein weiterer Grund, native Font-Loader zu nutzen statt eigene <link>-Tags zu pflegen.

c) Render-Blocking JavaScript

Großes JavaScript im <head> ohne async oder defer blockiert das Rendering. Klassischer Übeltäter: Tracking-Scripts, A/B-Test-Tools, Cookie-Banner-Loader.

Fix: Alle nicht-kritischen Scripts mit defer laden, Tracking via Tag Manager nach DOMContentLoaded initialisieren. Cookie-Banner-Tools wie Cookiebot oder Usercentrics bieten eigene Performance-Modi an — nutzen Sie sie.

d) Server-Antwortzeit zu langsam

Wenn Ihr Server selbst 800 ms braucht, bevor er den ersten Byte liefert (TTFB), sind alle Frontend-Optimierungen begrenzt nützlich. Ziel: TTFB unter 200 ms.

Fix: CDN nutzen (Vercel, Cloudflare), statisches Pre-Rendering wo möglich, Caching auf Datenbank-Queries. Bei WordPress: Hosting-Wechsel von Shared auf Managed (Kinsta, WP Engine) bringt oft 300 – 500 ms Unterschied.

CLS-Probleme beheben

CLS-Probleme sind fast immer Layout-Probleme, keine Performance-Probleme. Die Hauptursachen:

Bilder ohne explizite Dimensionen. Wenn der Browser nicht weiß, wie groß ein Bild wird, reserviert er keinen Platz — und schiebt den Inhalt nach unten, sobald das Bild lädt.

<!-- Falsch: kein reservierter Platz -->
<img src="/foto.jpg" alt="..." />
 
<!-- Richtig: Browser reserviert Platz vorab -->
<img src="/foto.jpg" alt="..." width="800" height="450" />

Werbung ohne reservierten Platz. AdSense, Display-Ads, eingebettete YouTube-Videos — alle laden asynchron und schieben Layout. Lösung: Container mit fixer min-height oder aspect-ratio.

.ad-slot {
  min-height: 250px;
  /* Reserviert vertikalen Platz, bevor das Ad-Skript lädt */
}

Fonts mit fallbackfremden Metriken. Wenn Ihre Custom Font deutlich anders dimensioniert ist als der Fallback, springt der Text beim Swap. CSS size-adjust, ascent-override und descent-override lösen das:

@font-face {
  font-family: 'Outfit';
  src: url('/fonts/Outfit.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100.06%;
  ascent-override: 96%;
  descent-override: 27%;
}

Tools wie fontaine generieren diese Werte automatisch.

Cookie-Banner und Notifications, die nachträglich einblenden. Hier ist die Lösung nicht trivial. Best Practice: Banner als Overlay rendern (position: fixed mit Backdrop), nicht im Dokumentenfluss. Wenn er den Inhalt verschiebt, ist er ein CLS-Verursacher.

INP-Probleme beheben

INP ist die anspruchsvollste Metrik 2026, weil sie nicht durch Server-Performance lösbar ist — sie misst rein die Reaktionsfähigkeit des Browsers während der Nutzung.

Hauptursachen:

• Long Tasks im Main Thread (> 50 ms blockieren Interaktion)
• Viele synchrone Event-Listener
• Unoptimierte React-Renders bei komplexen State-Änderungen

Fixes:

1. Long Tasks aufbrechen. Wenn ein Klick eine schwere Berechnung auslöst, macht das setTimeout(fn, 0) oder scheduler.yield() einen großen Unterschied:

// Schlecht: blockiert den Main Thread
button.addEventListener('click', () => {
  heavyCalculation()
  updateUI()
})
 
// Besser: gibt Browser Zeit zu rendern
button.addEventListener('click', async () => {
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0))
  heavyCalculation()
  updateUI()
})

2. JavaScript-Bundle reduzieren. Pro 100 KB JavaScript steigt INP im 75. Perzentil um etwa 30 – 60 ms (basierend auf Chrome UX Report Aggregaten). In Next.js: Dynamic Imports nutzen, unnötige Polyfills entfernen, Tree-Shaking prüfen.

// Komponenten erst laden, wenn sie gebraucht werden
const HeavyChart = dynamic(() => import('./HeavyChart'), {
  loading: () => <ChartSkeleton />,
})

3. React Re-Renders kontrollieren. Wenn ein Klick den State eines Wurzel-Components ändert, rendert React standardmäßig den ganzen Baum neu. Bei großen Trees führt das zu langen Tasks. React.memo, useMemo und Splitting in kleinere Components helfen.

4. Third-Party-Scripts isolieren. Tracking, Live-Chats, Heatmap-Tools — alles, was Sie nicht selbst kontrollieren — gehört in Web Workers oder hinter einen Consent-Gate. Tools wie Partytown (@builder.io/partytown) verschieben Third-Party-JavaScript in Web Workers.

Real-World-Impact: ein konkretes Beispiel

Ein Audit-Kunde, mittelständischer B2B-Anbieter mit Next.js-Site, hatte folgende Werte vor Optimierung:

LCP (75. Perzentil)   : 4,8 Sek.   ❌
CLS                   : 0,18       ⚠️
INP                   : 620 ms     ❌

Organischer Traffic   : -32 % vs. Vorjahr

Identifizierte Hauptursachen: Hero-Bild ohne priority, drei Render-Blocking Scripts im <head>, eingebettetes Vimeo-Video ohne aspect-ratio-Container, ein 280-KB-Animation-Library für eine einzige Hover-Animation.

Nach Optimierung (4 Tage Aufwand):

LCP (75. Perzentil)   : 1,9 Sek.   ✅
CLS                   : 0,04       ✅
INP                   : 180 ms     ✅

Organischer Traffic   : +18 % nach 8 Wochen

Wichtig: Die Traffic-Zahl ist ein zusammengesetzter Effekt — bessere Vitals plus bessere User Signals plus einige inhaltliche Anpassungen, die parallel passierten. Aber die technische Basis war Voraussetzung dafür.

Was Sie als nächstes tun sollten

Wenn Sie nicht sicher sind, wie Ihre Vitals 2026 aussehen, sind das die drei konkreten Schritte für diese Woche:

1. Search Console → Core Web Vitals öffnen. Wenn dort URLs in "Schlecht" oder "Verbesserungswürdig" stehen, haben Sie konkrete Arbeit.
2. PageSpeed Insights für Ihre wichtigsten 3 Landing Pages laufen lassen — Felddaten, nicht Lab. Welche Metrik ist rot?
3. Chrome DevTools → Performance auf Mobile-Throttling stellen, Seite einmal aufrufen, das LCP-Element identifizieren.

Diese drei Schritte sagen Ihnen, ob Sie ein Problem haben und welches.

Wenn die Werte schlecht sind und Sie nicht selbst diagnostizieren möchten — wir bieten einen technischen Performance-Audit an. 30 Minuten Zugang zur Search Console (read-only), 90 Minuten Analyse, schriftlicher Report mit den drei größten Hebeln, geschätztem Aufwand und priorisierter Reihenfolge. Ob Sie dann mit uns oder Ihrem internen Team umsetzen, ist nicht Teil der Verpflichtung.

Was wir gelernt haben: Bei 80 % der schlechten Vitals 2026 sind die ersten zwei Fixes — Hero-Bild priorisieren, ein paar Render-Blocking-Scripts ent-blockieren — bereits genug, um die Schwellenwerte zu erreichen. Es lohnt sich, vor einem Komplett-Refactor erst mal die niedrig hängenden Früchte zu pflücken.