Core Web Vitals 2026: Was sie sind und warum sie noch immer wichtig sind
Core Web Vitals messen echte Nutzererfahrung auf Ihrer Website. Google nutzt sie als Rankingfaktor. Was jede Metrik bedeutet und wie man alle drei verbessert.
Kurzzusammenfassung: Core Web Vitals sind drei spezifische Metriken, mit denen Google die reale Nutzererfahrung beim Laden, der Interaktion und der visuellen Nutzung Ihrer Website misst. Sie sind ein offizieller Google-Rankingfaktor — Teil der sogenannten “Page Experience Signals.” 2026 bleiben sie relevant — nicht nur für SEO, sondern als direkter Indikator dafür, wie wahrscheinlich Nutzer auf Ihrer Seite bleiben, konvertieren und zurückkehren. Dieser Leitfaden erklärt jede Metrik in verständlicher Sprache, wie man sie präzise misst, was schlechte Werte verursacht und welche Maßnahmen die Werte wirklich bewegen.
Warum Performance ein SEO-Problem ist, nicht nur ein UX-Problem
Es gibt ein hartnäckiges Missverständnis in der Art, wie lokale Unternehmen über Website-Performance nachdenken. Die meisten Inhaber betrachten sie als Design- oder Entwicklungsthema — etwas, das man einem Webentwickler übergibt und nie wieder bedenkt. Die Realität ist, dass Website-Performance gleichzeitig ein SEO-Problem, ein Konversionsproblem und ein Geschäftsproblem ist.
Google nutzt Seitengeschwindigkeit seit 2010 für Desktop und seit 2018 für Mobile als Rankingfaktor. Mit der Einführung der Core Web Vitals als Teil des Page Experience Updates 2021 wurden Performance-Signale spezifischer, messbarer und direkter an echtes Nutzerverhalten geknüpft.
Der Zusammenhang ist klar: Wenn Ihre Website langsam lädt, sich beim Lesen verschiebt oder bei Interaktionen träge reagiert — verlassen Nutzer die Seite. Google weiß das und nutzt dieses Wissen, um schnellere, stabilere, responsivere Websites über langsamere zu ranken. Das hängt direkt damit zusammen, wie Google lokale Unternehmen rankt — mithilfe von Page-Experience-Signalen neben Relevanz und Bekanntheit.
Was Core Web Vitals sind: Die drei Metriken
Google definiert Core Web Vitals als eine Teilmenge der Web Vitals — spezifische, quantifizierbare Signale, die drei Dimensionen der Nutzererfahrung messen:
- LCP — Largest Contentful Paint (Ladeleistung)
- INP — Interaction to Next Paint (Reaktionsfähigkeit und Interaktivität)
- CLS — Cumulative Layout Shift (Visuelle Stabilität)
Jede Metrik hat festgelegte Schwellenwerte, die “Gut”, “Verbesserungsbedarf” und “Schlecht” trennen. Das Ziel ist, alle drei im “Gut”-Bereich zu bestehen.
Metrik 1: LCP — Largest Contentful Paint
Was er misst
LCP misst, wie schnell das größte sichtbare Element auf der Seite lädt und für den Nutzer sichtbar wird. Dieses Element ist typischerweise ein Hero-Bild oder Banner-Foto, ein großer Textblock above the fold, ein Video-Thumbnail oder ein Hintergrundbild in einem Schlüsselbereich.
LCP beantwortet im Wesentlichen: “Wie lange dauert es, bis der Nutzer den Hauptinhalt dieser Seite sehen kann?”
Die Schwellenwerte
| Bewertung | LCP-Zeit |
|---|---|
| ✅ Gut | Unter 2,5 Sekunden |
| ⚠️ Verbesserungsbedarf | 2,5 – 4,0 Sekunden |
| ❌ Schlecht | Über 4,0 Sekunden |
Was schlechte LCP-Werte verursacht
Langsame Server-Antwortzeit (TTFB). Wenn Ihr Webserver lange braucht, um zu antworten, ist alles andere von Anfang an verzögert. Lösung: Wechseln Sie zu einem schnelleren Hosting-Anbieter. Für die meisten kleinen Betriebe macht der Wechsel von Shared Hosting zu einem VPS oder Managed WordPress Hosting (z. B. Kinsta, WP Engine, Hetzner) sofort einen Unterschied.
Nicht optimierte Bilder. Große Bilder im falschen Format sind die häufigste Ursache für schlechte LCP-Werte bei kleinen Unternehmenswebsites. Ein 4 MB JPEG-Hero-Bild zerstört LCP-Werte auf Mobilgeräten. Lösung: Konvertieren Sie Bilder in WebP- oder AVIF-Format. Komprimieren Sie Bilder auf unter 200 KB. Verwenden Sie responsive Bilder.
Render-blockierende Ressourcen. CSS- und JavaScript-Dateien, die im <head> geladen werden, blockieren den Browser beim Rendern. Lösung: Nicht kritisches JavaScript verzögern. Kritisches CSS inlinen. Nicht verwendetes CSS und JS entfernen. Performance-Plugin nutzen (z. B. WP Rocket für WordPress).
Kein Content Delivery Network (CDN). Ohne CDN müssen alle Ressourcen vom Ursprungsserver geladen werden — auch für Besucher weit entfernt. Lösung: CDN aktivieren. Cloudflares kostenloser Plan funktioniert gut für die meisten kleinen Unternehmenswebsites.
Metrik 2: INP — Interaction to Next Paint
Was er misst
INP (Interaction to Next Paint) ersetzte First Input Delay (FID) im März 2024 als Interaktivitäts-Core-Web-Vital. Er misst die Verzögerung zwischen einer Nutzerinteraktion mit der Seite — Klicken eines Buttons, Antippen eines Links, Abschicken eines Formulars — und der visuellen Reaktion des Browsers auf diese Interaktion.
FID maß nur die Verzögerung, bevor der Browser begann, die Interaktion zu verarbeiten. INP misst den vollständigen Zyklus — von der Interaktion bis zum visuellen Update des Browsers. Das macht ihn zu einem viel umfassenderen Maß der Seitenresponsivität.
Die Schwellenwerte
| Bewertung | INP-Zeit |
|---|---|
| ✅ Gut | Unter 200 Millisekunden |
| ⚠️ Verbesserungsbedarf | 200 – 500 Millisekunden |
| ❌ Schlecht | Über 500 Millisekunden |
Warum schlechter INP spürbar schädigt
Schlechter INP bedeutet: Die Website fühlt sich träge und nicht responsiv an. Ein Nutzer tippt auf einen Navigationsbutton und scheinbar passiert eine halbe Sekunde lang nichts. Er tippt erneut — die Aktion wird doppelt ausgelöst. Das zerstört Vertrauen. Für lokale Unternehmenswebsites manifestiert sich schlechter INP als träge Kontaktformulare, hakende Navigationsmenüs auf Mobilgeräten, und langsam reagierende Buchungs-Widgets.
Was schlechte INP-Werte verursacht
Schwere JavaScript-Ausführung. Der häufigste INP-Killer. Wenn der Haupt-Thread des Browsers mit JavaScript-Verarbeitung beschäftigt ist, kann er nicht auf Nutzerinteraktionen reagieren. Lösung: Drittanbieter-JavaScript prüfen und reduzieren. Jedes Analytics-Tag, Chat-Widget und Werbe-Skript addiert Haupt-Thread-Last.
Lange Aufgaben auf dem Haupt-Thread. JavaScript-Aufgaben über 50ms gelten als “lange Aufgaben.” Während einer langen Aufgabe kann der Browser nicht auf Interaktionen reagieren. Lösung: Für WordPress: leichteres Theme verwenden, ungenutzte Plugins deaktivieren.
Metrik 3: CLS — Cumulative Layout Shift
Was er misst
CLS misst, wie stark sich sichtbare Seiteninhalte unerwartet verschieben, während die Seite lädt. Er erfasst die gesamte visuelle Instabilität — das frustrierende Phänomen, bei dem man kurz vor dem Klick auf einen Button steht und dieser plötzlich nach unten springt, weil ein Bild oder eine Anzeige darüber geladen hat. CLS wird als Score gemessen (nicht als Zeit).
Die Schwellenwerte
| Bewertung | CLS-Wert |
|---|---|
| ✅ Gut | Unter 0,1 |
| ⚠️ Verbesserungsbedarf | 0,1 – 0,25 |
| ❌ Schlecht | Über 0,25 |
Was schlechte CLS-Werte verursacht
Bilder ohne Breiten- und Höhenangaben. Wenn der Browser die Dimensionen eines Bildes vor dem Laden nicht kennt, reserviert er keinen Platz dafür. Wenn das Bild lädt, verschiebt sich alles. Lösung: Immer explizite width- und height-Attribute auf <img>-Tags setzen.
Webfonts, die Text-Reflow verursachen. Wenn Webfonts Zeit zum Laden brauchen, zeigt der Browser zunächst einen Fallback-Font. Wenn der Webfont lädt, ändert sich die Textgröße. Lösung: font-display: swap im CSS verwenden. Kritische Fonts im <head> vorladen. Fonts lokal hosten statt von Google Fonts laden.
Anzeigen und Einbettungen ohne reservierten Platz. Von Drittanbieter-Netzwerken ausgelieferte Anzeigen haben oft variable Höhen. Lösung: Immer Mindesthöhen-Container für Werbeplätze definieren. min-height CSS für jeden Container verwenden, dessen Inhalt dynamisch lädt.
Cookie-Consent- und Benachrichtigungs-Banner. Pop-ups, die nach dem Seitenladen erscheinen und Inhalte nach unten schieben, sind eine große CLS-Quelle. Lösung: Consent-Banner als Overlay gestalten (fixierte Position oben oder unten), nicht als Elemente, die Inhalte verschieben.
Wie man Core Web Vitals misst
Labordaten werden von automatisierten Tools unter kontrollierten Bedingungen generiert — konsistent und nützlich zum Debuggen, spiegeln aber keine echten Nutzerbedingungen wider. Felddaten werden von echten Nutzern gesammelt — das ist es, was Google für das Ranking verwendet.
Primäre Mess-Tools
Google Search Console — Core Web Vitals Bericht. Das wichtigste Tool. Zeigt Felddaten von echten Nutzern Ihrer Website, aufgeteilt nach Mobil und Desktop. Zugang: Search Console → Nutzerfreundlichkeit → Core Web Vitals. Hier beginnen.
Google PageSpeed Insights. Liefert Labor- und Felddaten für jede URL. Direkt unter pagespeed.web.dev aufrufbar.
Chrome DevTools Lighthouse. Labortest im Browser. F12 → Lighthouse → Bericht generieren. Nützlich für lokale Entwicklungsversionen und Seiten mit wenig Traffic. Hinweis: Lab-Scores weichen oft von Felddaten-Scores ab.
Web Vitals Chrome-Erweiterung. Zeigt Core Web Vitals in Echtzeit beim Browsen Ihrer eigenen Website.
Core Web Vitals für lokale Unternehmenswebsites: Die spezifischen Risiken
Das Shared-Hosting-Problem. Viele kleine lokale Unternehmenswebsites sind auf günstigen Shared-Hosting-Plänen gehostet — oft demselben Plan, der seit Jahren jährlich verlängert wird. Shared Hosting bedeutet, dass Ihre Website einen Server mit Hunderten oder Tausenden anderen teilt. Das ist das wirkungsvollste und am häufigsten übersehene LCP-Problem für lokale Unternehmen.
Die Builder-Plattform-Falle. Websites, die mit Page Buildern (Elementor, Divi, Wix) erstellt wurden, erzeugen oft aufgeblähten HTML-Code und laden übermäßig viel CSS und JavaScript. Diese Plattformen können performant sein — erfordern aber bewusstere Optimierung als handgeschriebener Code.
Das Plugin-Akkumulationsproblem. Für WordPress-Websites gilt: Jedes installierte Plugin fügt Code hinzu, der bei jedem Seitenaufruf ausgeführt wird. Kontaktformular-Plugin, Slider, SEO-Plugin, Buchungssystem, Chat-Widget, Social-Media-Feed, Kalender — einzeln harmlos, gemeinsam verheerend für die Performance.
Mobile-First-Realität. Googles Core-Web-Vitals-Bewertung gewichtet Mobile-Performance stärker. Der Großteil des Traffics auf lokalen Unternehmenswebsites kommt von Mobilgeräten. Eine Seite, die auf Desktop gut läuft, aber auf Mobilgeräten schlecht, wird im Ranking schlechter abschneiden.
Ihre Prioritätsliste für Maßnahmen
Hohe Wirkung, geringer Aufwand — Zuerst umsetzen
- Bilder komprimieren und in WebP konvertieren — heute umsetzen
- Cloudflare aktivieren (kostenloser CDN und Caching) — 30 Minuten Einrichtung
widthundheightallen Bildern hinzufügen — schnelle Entwickleraufgabefont-display: swapfür Webfonts festlegen — eine CSS-Zeile
Hohe Wirkung, mittlerer Aufwand
- Zu schnellerem Hosting wechseln — Migrationsprojekt, aber transformativ für LCP
- Unnötige Plugins prüfen und entfernen (WordPress) — erfordert Tests
- Browser-Caching und GZIP-Kompression konfigurieren
Hohe Wirkung, höherer Aufwand
- Drittanbieter-JavaScript prüfen und reduzieren — erfordert Entwickler
- Lazy Loading für Off-Screen-Bilder implementieren
- Lange JavaScript-Aufgaben refaktorieren oder ersetzen
Häufig gestellte Fragen
Was sind Core Web Vitals?
Core Web Vitals sind drei von Google definierte Performance-Metriken: LCP (wie schnell das größte Inhaltselement lädt, Ziel unter 2,5 Sekunden), INP (wie schnell die Seite auf Nutzerinteraktionen reagiert, Ziel unter 200 Millisekunden) und CLS (wie stabil das Seitenlayout während des Ladens ist, Ziel unter 0,1).
Sind Core Web Vitals ein Google-Rankingfaktor?
Ja. Google hat Core Web Vitals als offizielles Ranking-Signal bestätigt, als das Page Experience Update 2021 eingeführt wurde. Sie bleiben 2026 ein Rankingfaktor.
Was ist ein guter Core Web Vitals Score?
Gute Schwellenwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Ziel ist “Gut” bei allen drei.
Was ersetzte First Input Delay (FID)?
Interaction to Next Paint (INP) ersetzte FID im März 2024 als dritten Core Web Vital. INP ist ein umfassenderes Maß der Seitenresponsivität.
Wie oft aktualisieren sich Core Web Vitals-Daten in der Google Search Console?
Die Daten aktualisieren sich etwa alle 28 Tage und zeigen einen rollenden 28-Tage-Durchschnitt der Felddaten von echten Nutzern.
Braucht meine lokale Unternehmenswebsite perfekte Core Web Vitals zum Ranken?
Nein — Core Web Vitals sind ein Signal unter vielen. Eine Site mit ausgezeichnetem Inhalt, starken GBP-Signalen und guten Bewertungen wird eine technisch perfekte, aber inhaltsschwache Seite übertreffen. In wettbewerbsintensiven Märkten können Core Web Vitals jedoch der entscheidende Faktor sein.
Core Web Vitals sind das technische Fundament unter allen anderen SEO-Bemühungen. Selbst das beste optimierte Google Business Profile, das auf eine langsame, instabile Website verweist, verliert Conversions im letzten Schritt. Kombinieren Sie Core-Web-Vitals-Arbeit mit Schema Markup — zusammen bilden sie die komplette technische Schicht des Local SEO. Dieses technische Fundament ist auch für AI SEO entscheidend — KI-Systeme können nur Inhalte abrufen und zitieren, auf die sie schnell zugreifen und die sie parsen können. Seitengeschwindigkeit ist auch ein expliziter technischer Faktor in unserem Google AI Overviews Ranking-Playbook. Möchten Sie wissen, wie Ihre Website bei Core Web Vitals abschneidet? Kostenlosen technischen SEO-Audit bei Viserno anfordern →
Kostenlos für neue Kunden
Sollen wir das für Ihr Unternehmen umsetzen?
Fordern Sie einen kostenlosen lokalen SEO-Audit an und erfahren Sie genau, wo Sie stehen, und was nötig ist, um Ihre Mitbewerber zu überholen.
