Technisches SEO

Core Web Vitals verbessern: Schritt-für-Schritt-Anleitung 2026

15. Januar 2026 ·Alexander Müller ·11 min Lesezeit

Schlechte Core Web Vitals kosten Rankings – das ist 2026 keine Theorie mehr, sondern Praxis. Diese Anleitung zeigt konkret, wie Sie LCP, INP und CLS verbessern, welche Tools Sie benötigen und was CMS-spezifisch zu beachten ist.

Core Web Vitals 2026: Was gemessen wird

Die drei Core Web Vitals sind seit 2021 offizieller Google-Rankingfaktor. 2024 wurde FID (First Input Delay) durch INP (Interaction to Next Paint) ersetzt – ein sensiblerer und umfassenderer Messwert. In 2026 sind die drei aktuellen Metriken:

LCP – Largest Contentful Paint: Wie lange dauert es, bis das grösste sichtbare Element geladen ist? Zielwert: unter 2,5 Sekunden.
INP – Interaction to Next Paint: Wie schnell reagiert die Seite auf Nutzereingaben (Klicks, Tippen, Wischen)? Zielwert: unter 200 Millisekunden.
CLS – Cumulative Layout Shift: Wie stabil ist das Layout beim Laden – springen Elemente hin und her? Zielwert: unter 0,1.

Für alle drei gilt: «gut» ist der grüne Bereich, «verbesserungswürdig» ist gelb und «schlecht» ist rot. Nur wenn alle drei im grünen Bereich sind, gilt eine Seite als «bestanden» im Page Experience Signal.

Messen: So prüfen Sie Ihre aktuellen Werte

Bevor Sie optimieren, müssen Sie wissen, wo Sie stehen. Die wichtigsten Mess-Tools:

Google Search Console (empfohlen als Ausgangspunkt)

Unter «Nutzererfahrung > Core Web Vitals» sehen Sie die Field Data für Ihre Website – also echte Nutzerdaten aus dem Chrome User Experience Report (CrUX). Das ist die Datenbasis, die Google für das Ranking verwendet. Hier sehen Sie auch, welche spezifischen Seiten problematisch sind.

Google PageSpeed Insights

Gibt sowohl Lab Data (simulierter Test) als auch Field Data (echte Nutzerdaten, falls vorhanden). Besonders nützlich: konkrete Optimierungsempfehlungen mit geschätzter Zeitersparnis pro Massnahme.

Chrome DevTools / Lighthouse

Für technische Analyse direkt im Browser. Lighthouse im Performance-Modus gibt detaillierte Wasserfall-Diagramme, die zeigen, welche Ressourcen die Ladezeit blockieren.

WebPageTest.org

Fortgeschrittenes Tool mit vielen Optionen: echte Browser-Tests, Filmstrips der Ladesequenz, Analyse aus verschiedenen Standorten (wichtig: testen Sie aus der Schweiz, nicht nur aus den USA).

Wichtig: Lab Data (PageSpeed Insights, Lighthouse) und Field Data (Search Console, CrUX) können abweichen. Google rankt auf Basis der Field Data. Lab Data ist nützlich zur Diagnose, aber nicht das Ziel.

LCP verbessern: Das grösste sichtbare Element schneller laden

Das LCP-Element ist meistens ein Hero-Bild, ein grosses Banner oder ein H1-Text-Block. Die häufigste Ursache für schlechten LCP: Das Hero-Bild ist zu gross, im falschen Format oder wird zu spät geladen.

Bilder optimieren (stärkster LCP-Hebel)

Format: Nutzen Sie WebP oder AVIF statt JPEG/PNG. WebP ist typischerweise 25–35 % kleiner bei gleicher Qualität. AVIF ist noch effizienter, aber nicht überall unterstützt.
Grösse: Laden Sie nicht ein 3000px-Bild, das nur 800px gross dargestellt wird. Skalieren Sie Bilder auf die tatsächliche Darstellungsgrösse.
Kompression: Nutzen Sie Tools wie Squoosh, TinyPNG oder automatisierte Pipelines (Cloudinary, imgix) für verlustbehaftete Kompression ohne sichtbaren Qualitätsverlust.
Preload: Das LCP-Element sollte nicht lazy-loaded werden. Stattdessen: <link rel="preload" as="image" href="hero.webp"> im <head>. Das teilt dem Browser mit, dieses Bild priorisiert zu laden.
Lazy Loading nur below the fold: Das loading="lazy"-Attribut darf NICHT auf das LCP-Element angewendet werden – nur auf Bilder, die beim Seitenaufruf nicht sichtbar sind.

Server-Response-Time (TTFB) reduzieren

TTFB (Time to First Byte) ist die Zeit, bis der Server die erste Antwort sendet. Über 600 ms TTFB ist problematisch. Lösungen:

CDN (Content Delivery Network) einsetzen, damit statische Ressourcen von einem Server näher beim Nutzer ausgeliefert werden. Für Schweizer Websites: CDN-Nodes in Frankfurt oder Zürich.
Server-Caching aktivieren (für WordPress: WP Rocket, W3 Total Cache, LiteSpeed Cache).
Hosting upgraden – Shared Hosting ist oft der Hauptverursacher hoher TTFB.

Render-blocking Ressourcen eliminieren

CSS und JavaScript, die im <head> geladen werden, blockieren das Rendering der Seite. Lösungen:

Kritisches CSS inline einfügen, unkritisches CSS asynchron laden.
JavaScript mit defer oder async laden, wo möglich.
JavaScript, das nicht für das initiale Rendering benötigt wird, ans Ende des Body verschieben oder code-splitten.

INP verbessern: Reaktionszeiten auf Nutzereingaben optimieren

INP ist die jüngste und für viele Websites problematischste der drei Metriken. Ein hoher INP-Wert bedeutet: Die Seite «hängt» kurz, wenn Nutzer klicken, tippen oder scrollen.

JavaScript minimieren und optimieren

Ungenutzte JavaScript-Bibliotheken entfernen: Häufig werden grosse Libraries geladen, von denen nur ein Bruchteil genutzt wird. Prüfen Sie mit Chrome DevTools Coverage, welche JS-Anteile ungenutzt sind.
Code-Splitting: Laden Sie nur den JavaScript-Code, der für die aktuelle Seite benötigt wird, nicht den gesamten Site-Bundle.
JavaScript-Ausführung verschieben: Nicht-kritisches JavaScript (Analytics, Chat-Widgets, Marketing-Scripts) sollte nach dem ersten Laden initialisiert werden.

Main Thread entlasten

Der Main Thread des Browsers ist für Rendering und JavaScript-Ausführung verantwortlich. Wenn er überlastet ist, entstehen Verzögerungen bei der Reaktion auf Nutzereingaben. Massnahmen:

Lange JavaScript-Tasks aufteilen (Long Tasks > 50 ms identifizieren und aufbrechen).
Web Workers für rechenintensive Aufgaben nutzen, die nicht DOM-Zugriff benötigen.
Event Listener optimieren: Verhindern Sie, dass zu viele Events gleichzeitig ausgelöst werden (Debouncing, Throttling).

Third-Party-Scripts ausladen oder verzögern

Cookie-Banner, Chat-Widgets, Social-Media-Buttons, Marketing-Pixel: Diese Scripts können erheblich zum INP-Problem beitragen. Strategien:

Third-Party-Scripts erst nach einer Nutzerinteraktion oder mit Verzögerung laden.
Unnötige Scripts vollständig entfernen.
Facade-Pattern nutzen: Zeigen Sie zunächst ein statisches Bild (z.B. ein YouTube-Thumbnail), und laden Sie das echte Embed erst auf Klick.

CLS verbessern: Layout-Sprünge verhindern

CLS misst, wie stark sich das Layout verschiebt, während die Seite lädt. Ein klassisches Beispiel: Ein Text lädt, der Nutzer beginnt zu lesen – plötzlich erscheint ein Bild und der Text springt nach unten.

Bildgrössen immer definieren

Das häufigste CLS-Problem: Bilder ohne width und height-Attribute. Der Browser weiss nicht, wie viel Platz er reservieren soll, und das Layout springt, wenn das Bild geladen wird. Lösung: Immer explizite Dimensionen setzen.

<img src="bild.webp" width="800" height="450" alt="Beschreibung">

Werbeflächen und Embeds reservieren

Banner, Anzeigen und Embeds (YouTube, Google Maps) sollten einen fixen Platzhalter haben, bevor der Inhalt geladen wird. Setzen Sie min-height auf Container, die dynamisch befüllt werden.

Font-Loading optimieren

Web Fonts können CLS verursachen, wenn die Fallback-Schrift andere Dimensionen hat als die geladene Font. Lösungen:

font-display: optional oder swap nutzen, je nach Priorität der Font.
Fonts preloaden: <link rel="preload" href="font.woff2" as="font" crossorigin>
size-adjust und ascent-override CSS-Properties nutzen, um Fallback-Fonts an die Ziel-Font anzupassen.

Problem-Lösungs-Matrix Core Web Vitals

Problem	Ursache	Lösung	Aufwand	Impact
Schlechter LCP	Hero-Bild zu gross	WebP + Preload + korrekte Grösse	Gering	Sehr hoch
Schlechter LCP	Langsame Server-Response	CDN, Caching, Hosting-Upgrade	Mittel	Hoch
Schlechter LCP	Render-blocking CSS/JS	Kritisches CSS inline, defer/async	Mittel–Hoch	Hoch
Schlechter INP	Zu viel JavaScript	Code-Splitting, Lazy Loading JS	Hoch	Hoch
Schlechter INP	Third-Party-Scripts	Verzögerte Initialisierung, Facade	Mittel	Mittel–Hoch
Schlechtes CLS	Bilder ohne Dimensionen	width/height-Attribute setzen	Sehr gering	Hoch
Schlechtes CLS	Dynamische Inhalte ohne Platzhalter	min-height für Container	Gering	Mittel
Schlechtes CLS	Webfont-Wechsel	font-display: optional, Preload	Gering	Mittel

CMS-spezifische Tipps

WordPress

WordPress ist die häufigste Ursache für CWV-Probleme – und hat gleichzeitig die breiteste Palette an Lösungs-Plugins. Empfehlungen:

Caching: WP Rocket (bezahlt, sehr effektiv) oder W3 Total Cache (kostenlos). LiteSpeed Cache falls Ihr Hosting LiteSpeed nutzt.
Bildoptimierung: Imagify, ShortPixel oder Smush für automatische WebP-Konvertierung und Kompression.
CDN: Cloudflare (kostenlose Basis-Version oft ausreichend) oder Bunny.net für Schweizer CDN-Nodes.
Theme-Wahl: Aufgeblähte Page-Builder-Themes (Divi, Avada, Elementor ohne Optimierung) sind häufige INP-Verursacher. Leichtgewichtige Themes wie Kadence oder GeneratePress schneiden besser ab.
Plugin-Audit: Deaktivieren und testen Sie jeden Plugin-Schritt für Schritt – häufig liegt das CWV-Problem an einem einzelnen problematischen Plugin.

Shopify

Shopify hat weniger Optimierungsmöglichkeiten als WordPress, da der Code teilweise vom System kontrolliert wird. Trotzdem:

Liquid-Templates optimieren, unnötige Sektionen entfernen.
App-Anzahl minimieren – jede Shopify-App fügt JavaScript hinzu.
Hero-Bilder als WebP mit korrekten Dimensionen hochladen.
Theme-Auswahl: Dawn (offizielles Shopify-Theme) ist bereits gut optimiert.

Webflow

Webflow-Seiten sind oft bereits gut optimiert, haben aber häufig Probleme mit Custom-Code-Einbindungen und zu vielen Interaktionen. Prüfen Sie:

Webflow Interactions sparsam einsetzen – jede Animation lädt JS.
Externe Scripts über den Tag Manager verzögert laden.
Bilder über Webflow's nativer Asset-Pipeline hochladen (automatische Optimierung).

Individuelle Systeme / Custom Development

Hier liegt die grösste Flexibilität – und die grösste Verantwortung. Setzen Sie auf modern gebaute Frontends (Next.js, Nuxt.js) mit serverseitigem Rendering (SSR) oder Static Site Generation (SSG), die von Natur aus schnell sind. Messen Sie von Anfang an und integrieren Sie CWV-Prüfungen in den CI/CD-Prozess.

Monitoring: Core Web Vitals dauerhaft im Blick behalten

Core Web Vitals zu verbessern ist kein einmaliges Projekt. Jedes Software-Update, jedes neue Plugin, jede neue Werbekampagne kann die Werte wieder verschlechtern. Deshalb:

Google Search Console: Wöchentlich auf Warnungen prüfen. Schlechte Seiten werden dort proaktiv gemeldet.
Monitoring-Alerts: Tools wie Calibre, SpeedCurve oder einfach PageSpeed Insights Alerting via Google Looker Studio einrichten.
Nach jedem grossen Deployment: Core Web Vitals erneut messen, bevor ein Launch live geht.

Mehr zu den technischen Grundlagen finden Sie in unserem Artikel über das technische SEO Audit.

FAQ

Häufige Fragen zu Core Web Vitals

Wie stark beeinflussen Core Web Vitals mein Google-Ranking?

Core Web Vitals sind ein Rankingfaktor, aber kein dominanter. Google hat mehrfach bestätigt, dass hochwertige, relevante Inhalte schwächer bewertete CWV kompensieren können. Allerdings: Bei ähnlich guten Inhalten gewinnt die schnellere Seite. Auf sehr kompetitiven Keywords kann der Unterschied zwischen «gut» und «schlecht» bei CWV durchaus mehrere Positionen ausmachen.

Welches ist der wichtigste Core Web Vital?

LCP hat in der Praxis den grössten Impact auf Nutzererfahrung und Ranking, weil er direkt die wahrgenommene Ladegeschwindigkeit misst. CLS ist für E-Commerce-Seiten besonders kritisch, da Layoutsprünge zu versehentlichen Klicks und Kaufabbrüchen führen. INP ist der neueste und für viele JavaScript-schwere Websites das aktuell dringendste Problem.

Meine CWV-Werte sind in PageSpeed Insights gut, aber in der Search Console schlecht. Was stimmt?

Die Search Console zeigt Field Data – echte Nutzerdaten über 28 Tage. PageSpeed Insights zeigt Lab Data aus einer simulierten Umgebung. Field Data ist massgeblich für das Google-Ranking. Wenn Ihre echten Nutzer auf langsameren Geräten oder mit schlechterer Verbindung surfen, kann Field Data deutlich schlechter sein als Lab Data.

Wie lange dauert es, bis verbesserte CWV im Ranking sichtbar werden?

Google aktualisiert die CrUX-Daten alle 28 Tage. Das bedeutet: Selbst nach vollständiger Optimierung dauert es bis zu 28 Tage, bis die verbesserten Werte in der Search Console reflektiert sind – und nochmals einige Wochen, bis sich das im Ranking niederschlägt. Erwarten Sie keine sofortigen Ranking-Gewinne.

Core Web Vitals professionell optimieren lassen

DeepRank analysiert Ihre Core Web Vitals, identifiziert die Hauptursachen und setzt konkrete Optimierungen um – mit messbaren Ergebnissen in Search Console und PageSpeed Insights.

Technisches SEO Kostenlose Analyse →