Core Web Vitals und Seitengeschwindigkeit: Der Leitfaden für 2026

Was sind Core Web Vitals?

Core Web Vitals sind die drei zentralen Metriken, mit denen Google die reale Nutzererfahrung auf Webseiten misst.

Seit 2021 zählen sie als Rankingfaktor. Im Jahr 2026 sind sie wichtiger denn je — Google gewichtet die Nutzererfahrung mit jedem Update stärker.

Diese Metriken sind nicht nur ein „Technical-SEO"-Thema. Sie beeinflussen direkt die Conversion-Rate. Eine langsame Seite treibt potenzielle Kunden geradewegs zu Ihren Mitbewerbern.

Die drei Kernmetriken

LCP — Largest Contentful Paint

Wie lange dauert es, bis der Hauptinhalt der Seite sichtbar wird?

Wenn ein Nutzer auf Ihre Seite kommt: Wie schnell rendert das größte Inhaltselement — in der Regel das Hero-Bild, ein großer Textblock oder ein Video — tatsächlich?

Faktoren, die den LCP verschlechtern:

• Langsame Serverantwortzeit (TTFB)
• Render-blockierendes CSS und JavaScript
• Langsam ladende Bilder und Videos
• Verzögerungen beim Client-seitigen Rendering

INP — Interaction to Next Paint

Misst, wie schnell die Seite auf Nutzerinteraktionen reagiert.

INP hat 2024 den FID (First Input Delay) abgelöst. Während FID nur die allererste Interaktion erfasste, deckt INP jede Interaktion ab — Klicks, Tippen und Tastatureingaben.

Faktoren, die den INP verschlechtern:

• Lang laufende JavaScript-Tasks
• Umfangreiche Drittanbieter-Skripte
• Operationen, die den Main Thread blockieren
• Übermäßig großes DOM

CLS — Cumulative Layout Shift

Misst unerwartete Layout-Verschiebungen beim Laden der Seite.

Sie kennen das: Sie wollen auf einen Button klicken, die Seite springt — und Ihr Klick landet woanders. Das ist ein CLS-Problem.

Faktoren, die den CLS verschlechtern:

• Bilder und Videos ohne explizite Abmessungen
• Dynamisch eingefügter Inhalt (Werbeanzeigen, Banner)
• Spät ladende Web-Fonts
• Unskalierte iFrames

Core Web Vitals messen

Lab-Daten (simuliert)

• Google PageSpeed Insights: Liefert sowohl Lab- als auch Felddaten
• Lighthouse: In den Chrome DevTools integriert
• WebPageTest: Detaillierte Waterfall-Analyse

Lab-Daten werden in einer kontrollierten Umgebung gemessen. Sie spiegeln die reale Nutzererfahrung möglicherweise nicht perfekt wider, sind aber ideal zur Problemidentifikation.

Felddaten (echte Nutzer)

• Google Search Console: Der CWV-Bericht basiert auf echten Nutzerdaten
• Chrome UX Report (CrUX): Anonymisierte Daten von Chrome-Nutzern
• PageSpeed Insights: Der Abschnitt „Felddaten für diese URL"

Google verwendet Felddaten für das Ranking. Selbst wenn Ihre Lab-Werte gut aussehen, schaden schlechte Felddaten Ihrem Ranking.

LCP optimieren

Serverantwortzeit reduzieren (TTFB)

Die Serverantwortzeit ist das Fundament des LCP.

• CDN verwenden: Inhalte vom nächstgelegenen Server ausliefern
• Server-seitiges Caching: Datenbankanfragen und Seitenausgaben cachen
• HTTP/2 oder HTTP/3 nutzen: Ermöglicht paralleles Ressourcenladen
• TTFB-Zielwert: Unter 800 ms

Bilder optimieren

Bilder sind auf den meisten Seiten das LCP-Element.

• WebP oder AVIF verwenden — 25–50 % kleiner als JPEG
• Responsive Bilder: srcset- und sizes-Attribute für gerätegerechte Größen
• Lazy Loading: loading="lazy" für Bilder unterhalb des sichtbaren Bereichs
• LCP-Bild vorladen: <link rel="preload" as="image" href="hero.webp">
• Über CDN ausliefern: Imgix, Cloudinary oder Cloudflare Images

Render-blockierende Ressourcen eliminieren

CSS- und JavaScript-Dateien können das Rendern der Seite verhindern.

• Kritisches CSS inline einbetten: Above-the-fold-Stile direkt in ein <style>-Tag schreiben
• CSS asynchron laden: media="print" onload="this.media='all'"
• JavaScript defer oder async: <script defer>
• Ungenutztes CSS entfernen: PurgeCSS oder ein ähnliches Tool verwenden

Schriften optimieren

Web-Fonts können den LCP erheblich verlangsamen.

• font-display: swap verwenden — die Systemschrift wird angezeigt, bis die Web-Font geladen ist
• Font-Dateien vorladen: <link rel="preload" as="font" type="font/woff2">
• Nur benötigte Zeichensatz-Subsets laden
• Systemschriften in Betracht ziehen, wo möglich

INP optimieren

Lange JavaScript-Tasks aufteilen

Wenn der Main Thread des Browsers mit Tasks länger als 50 ms beschäftigt ist, kann er nicht auf Nutzerinteraktionen reagieren.

• Große JavaScript-Bundles aufteilen (Code-Splitting)
• Lange Tasks mit requestIdleCallback oder scheduler.yield() unterbrechen
• Arbeit in Web Workers verlagern: Hintergrundverarbeitung unabhängig vom Main Thread

Drittanbieter-Skripte prüfen

Analytics, Werbung, Live-Chat-Widgets, Social-Media-Einbettungen — jedes davon konkurriert um Main-Thread-Zeit.

• Auswirkung jedes Skripts messen
• Nicht zwingend notwendige Skripte entfernen
• Verbleibende Skripte mit defer oder dynamischen Imports laden
• Facade-Pattern verwenden — z. B. ein Vorschaubild statt sofortiges Laden eines YouTube-Einbettung

DOM-Größe reduzieren

Ein zu großes DOM verlangsamt jede Interaktion.

• Nicht mehr als 1.500 DOM-Elemente
• Verschachtelungstiefe unter 32 Ebenen halten
• Unnötige Wrapper-Divs entfernen
• Virtual Scrolling für lange Listen — nur im Viewport befindliche Elemente rendern

CLS optimieren

Explizite Abmessungen für Bilder und Videos festlegen

width- und height-Attribute zu jedem <img>- und <video>-Element hinzufügen.

<img src="foto.webp" width="800" height="600" alt="Beschreibung">

Der Browser reserviert den Platz, bevor das Bild geladen wird — so verschiebt sich das Layout nie.

Alternativ kann auch die CSS-Eigenschaft aspect-ratio verwendet werden.

Werbeanzeigen und dynamische Inhalte

Werbeanzeigen sind der größte CLS-Feind.

• Festen Platz für Werbeslots mit min-height reservieren
• Den Container daran hindern, zu kollabieren, wenn keine Anzeige vorhanden ist
• Sticky-Anzeigenpositionen bevorzugen

Font-Verschiebungen verhindern

Wenn eine Web-Font lädt, können sich Textabmessungen ändern und Layoutverschiebungen verursachen.

• font-display: swap oder optional verwenden
• Font-Metriken mit size-adjust an die Fallback-Systemschrift anpassen
• Schriften im <head> vorladen

Allgemeine Seitengeschwindigkeit optimieren

Caching-Strategie

Ein solides Caching verkürzt die Ladezeit bei Folgebesuchen erheblich.

• Browser-Cache: Cache-Control-Header korrekt konfigurieren
• Service Worker: Ermöglicht Offline-Zugriff und granulare Cache-Kontrolle
• CDN-Cache: Statische Assets auf Edge-Servern cachen

Langfristiges Caching (1 Jahr) für statische Assets wie CSS, JS und Bilder verwenden. Kurze oder kein Cache für HTML.

HTTP-Anfragen reduzieren

Jede HTTP-Anfrage erhöht die Latenz.

• CSS- und JavaScript-Dateien bündeln
• SVG-Icon-Sets statt einzelner Bilder verwenden
• Unnötige Drittanbieter-Anfragen entfernen
• dns-prefetch und preconnect zur DNS-Auflösung nutzen

Komprimierung

• Gzip- oder Brotli-Komprimierung — reduziert Dateigröße um 60–80 %
• Brotli komprimiert 15–20 % besser als Gzip
• Komprimierung in der Serverkonfiguration aktivieren

Moderne Bildformate

Für jedes Bildformat eine Fallback-Strategie aufbauen.

Performance-Budget

Der zuverlässigste Weg zum Schutz der Seitengeschwindigkeit ist ein von Anfang an definiertes Performance-Budget.

Beispiel-Performance-Budget:

• Gesamtgröße der Seite: < 1,5 MB
• JavaScript: < 300 KB (komprimiert)
• Bilder: < 500 KB
• LCP: < 2 Sekunden
• INP: < 150 ms
• HTTP-Anfragen: < 50

Dieses Budget in die CI/CD-Pipeline integrieren und Deployments blockieren, die es überschreiten.

Mobile Performance

Mobile Geräte haben langsamere Prozessoren und Netzwerkverbindungen als Desktops.

Google verwendet Mobile-First-Indexing. Schlechte mobile Performance wirkt sich auch auf das Desktop-Ranking aus.

• Auf einer 3G-Verbindung testen
• Auf Low-End-Geräten mit Chrome-DevTools-Drosselung testen
• AMP oder Performance-orientierte Frameworks in Betracht ziehen

Core Web Vitals und SEO

Google nutzt CWV als Rankingsignal — aber was bedeutet das in der Praxis?

CWV allein katapultiert niemanden auf Position eins. Aber wenn zwei Seiten in Inhaltsqualität und Backlink-Profil gleichauf liegen, können die CWV den Ausschlag geben.

Die indirekten Auswirkungen sind genauso bedeutend:

• Schnelle Seite → niedrigere Absprungrate
• Gute UX → höheres Engagement
• Höheres Engagement → stärkere Nutzersignale
• Stärkere Nutzersignale → bessere Rankings

Dieser Dominoeffekt macht CWV wertvoller als einen einfachen Rankingfaktor.

E-Commerce und Seitengeschwindigkeit

Bei E-Commerce-Seiten wirkt sich Seitengeschwindigkeit direkt auf den Umsatz aus.

• 1 % Geschwindigkeitsverbesserung → ~2 % mehr Conversions (im Durchschnitt)
• Seiten, die länger als 3 Sekunden laden → 53 % der Besucher brechen ab
• Mobile Conversion-Rates sind bereits halb so hoch wie auf dem Desktop — mehr Geschwindigkeit schließt diese Lücke

CWV kontinuierlich überwachen

Einmalige Optimierung reicht nicht. Neue Inhalte, Plugins und Updates können die Performance jederzeit verschlechtern.

Tools für kontinuierliches Monitoring:

• Google Search Console — CWV-Bericht
• PageSpeed Insights — Analyse auf Seitenebene
• Web Vitals Chrome-Erweiterung — Echtzeitmessung
• Lighthouse CI — Automatisierte Tests in der Pipeline

Technische SEO-Probleme manuell zu verfolgen ist zeitaufwendig und fehleranfällig. DexterGPT crawlt Ihre Website automatisch, identifiziert CWV- und Seitengeschwindigkeitsprobleme und liefert umsetzbare Empfehlungen.

Fazit

Core Web Vitals und Seitengeschwindigkeit bilden das technische Fundament des SEO.

Die Optimierung von LCP, INP und CLS verbessert sowohl die Nutzererfahrung als auch das Ranking — mit direkt messbarem Einfluss auf Conversions.

Performance ist keine einmalige Aufgabe. Es ist ein fortlaufender Prozess. Messen, optimieren, wieder messen. Den Kreislauf niemals unterbrechen.

Unsere Technische-SEO-Checkliste deckt alles jenseits der Seitengeschwindigkeit umfassend ab.