Core Web Vitals verbessern: Ein Praxisleitfaden
LCP, INP und CLS verständlich erklärt — mit konkreten Maßnahmen, die sofort messbare Ergebnisse liefern. Inklusive Prioritäts-Reihenfolge.
Paul Mill
Webdesign & Entwicklung
Inhaltsverzeichnis
Seiten auf Position 1 bei Google bestehen die Core-Web-Vitals-Schwellenwerte 10 % häufiger als Seiten auf Position 9. Das klingt nach wenig — bis man bedenkt, dass der Unterschied zwischen Position 3 und Position 8 für ein KMU den Unterschied zwischen 200 und 20 Anfragen pro Monat bedeuten kann.
Core Web Vitals sind Googles Metriken für die reale Nutzererfahrung. Seit dem Core Update im März 2026 gewichtet Google Performance-Signale stärker als zuvor. Dieser Leitfaden zeigt die drei Metriken, ihre Schwellenwerte und — vor allem — die Maßnahmen mit dem größten Hebel.
Die drei Metriken auf einen Blick
Core Web Vitals messen drei Aspekte der Nutzererfahrung: Ladegeschwindigkeit (LCP), Reaktionsfähigkeit (INP) und visuelle Stabilität (CLS).
| Metrik | Was sie misst | Gut | Schlecht |
|---|---|---|---|
| LCP — Largest Contentful Paint | Wie schnell der größte sichtbare Inhalt erscheint | ≤ 2,5 s | > 4,0 s |
| INP — Interaction to Next Paint | Wie schnell die Seite auf Klicks/Taps reagiert | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Wie stabil das Layout beim Laden bleibt | ≤ 0,1 | > 0,25 |
Wichtig: Google misst Felddaten — echte Nutzererfahrungen über den Chrome UX Report, nicht Labortests. Lighthouse-Scores sind nützlich zum Debuggen, aber Felddaten entscheiden über Ihr Ranking.
Die richtige Reihenfolge: TTFB → LCP → INP → CLS
Bevor Sie einzelne Metriken optimieren: Arbeiten Sie in dieser Reihenfolge. TTFB (Time to First Byte) ist das Fundament — wenn der Server langsam antwortet, kann keine Optimierung das kompensieren.
| Priorität | Metrik | Typischer Hebel |
|---|---|---|
| 1 | TTFB | CDN aktivieren, Server-seitig cachen |
| 2 | LCP | Bilder optimieren, kritische Ressourcen vorladen |
| 3 | INP | JavaScript reduzieren, Event-Handler schlank halten |
| 4 | CLS | Dimensionen setzen, Schriften vorladen |
Und: Optimieren Sie auf Template-Ebene, nicht URL für URL. Ein Fix im Basis-Layout behebt das Problem auf allen Seiten, die dieses Template verwenden.
LCP optimieren: Die drei stärksten Hebel
Das Hero-Bild ist fast immer der LCP-Kandidat. Drei Maßnahmen, die in meinen Projekten zusammen regelmäßig 1–2 Sekunden einsparen:
1. Bildformat und Größe
Ein 5 MB großes Hero-Bild, das als 200 KB WebP funktionieren würde, ist der häufigste LCP-Killer. Die Lösung:
<img
src="/hero.webp"
alt="Beschreibung"
width="1200"
height="630"
fetchpriority="high"
loading="eager"
/>- WebP/AVIF statt PNG/JPG — 30–50 % kleiner bei gleicher Qualität
fetchpriority="high"signalisiert dem Browser: dieses Bild hat Vorrang- Explizite
width/height— verhindert Layout-Shifts und ermöglicht dem Browser, Platz zu reservieren
2. Render-blockierende Ressourcen eliminieren
Jede CSS- oder JS-Datei im <head> ohne async oder defer blockiert das Rendering. Moderne Frameworks wie Astro lösen das automatisch — bei WordPress mit 15+ Plugins lohnt ein Blick in den Netzwerk-Tab.
Schnelltest: Öffnen Sie Chrome DevTools → Network → filtern Sie nach „Render-blocking”. Alles, was dort rot markiert ist, verzögert Ihren LCP.
3. Server-Antwortzeit (TTFB) unter 200 ms bringen
Ein CDN wie Cloudflare kann die TTFB auf unter 50 ms drücken — bei statischen Websites der einfachste und wirkungsvollste Hebel. Für WordPress-Seiten: Server-seitiges Caching (WP Super Cache, WP Rocket) bringt ähnliche Ergebnisse.
INP verbessern: Das Problem heißt JavaScript
INP ist die am häufigsten versagte Core-Web-Vital-Metrik: 43 % aller Websites liegen über dem 200-ms-Schwellenwert. Der Grund: zu viel JavaScript im Main Thread.
Drei Maßnahmen, die den größten Unterschied machen:
Third-Party-Scripts auditieren. Analytics, Chat-Widgets, Tag-Manager und Social-Media-Embeds sind die üblichen Verdächtigen. In einem kürzlichen Projekt hat das Entfernen eines ungenutzten Intercom-Widgets den INP von 380 ms auf 120 ms gesenkt — eine einzelne Zeile Code.
Event-Handler schlank halten. Aufwendige Berechnungen gehören nicht in Click-Handler. Lagern Sie rechenintensive Arbeit in requestIdleCallback oder Web Worker aus.
content-visibility: auto auf langen Seiten. Diese CSS-Eigenschaft sagt dem Browser: Rendere nur, was sichtbar ist. Bei Seiten mit 20+ Abschnitten kann das den INP halbieren.
.section-below-fold {
content-visibility: auto;
contain-intrinsic-size: 0 500px;
}CLS vermeiden: Meistens einfach zu beheben
CLS-Probleme sind die am einfachsten zu behebenden — weil die Ursachen fast immer dieselben sind:
Bilder und Videos ohne Dimensionen. Das Element lädt, alles verschiebt sich. Fix: Immer width und height im HTML setzen. Der Browser reserviert den Platz, bevor das Bild da ist.
Webfonts ohne Fallback-Strategie. Text springt, wenn der Custom Font den System-Font ersetzt. Fix:
@font-face {
font-family: "Inter";
font-display: swap;
src: url("/fonts/inter.woff2") format("woff2");
}Noch besser: font-display: optional — der Custom Font wird nur gezeigt, wenn er rechtzeitig geladen ist. Kein Sprung, kein Flash.
Dynamisch eingefügte Inhalte. Cookie-Banner, Sticky-Header und Werbebanner sind CLS-Klassiker. Reservieren Sie den Platz vorab mit fester Höhe oder verwenden Sie position: fixed / position: sticky, um den Dokumentenfluss nicht zu stören.
Messen: Zwei Tools reichen
Für den Anfang brauchen Sie nur zwei Tools:
- PageSpeed Insights — zeigt Felddaten (echte Nutzer) und Labordaten in einem Report. Die Felddaten-Sektion oben ist das, was Google tatsächlich für Rankings nutzt.
- Chrome DevTools → Performance — für frame-genaue Analyse einzelner Interaktionen. Unverzichtbar für INP-Debugging.
Praxisbeispiel
4× 100 bei PageSpeed Insights
So sieht das Ergebnis der Maßnahmen aus diesem Artikel in der Praxis aus — ein aktueller Report von paulmill.com.
Statische Auslieferung über Cloudflare, optimierte Bildformate, kein render-blockierendes JavaScript und explizite Dimensionen auf allen Medien-Elementen.
- LCP 1,4 s
- CLS 0
- TBT 0 ms
- Speed Index 1,2 s
Optimieren Sie für echte Nutzer, nicht für Lighthouse-Scores. Ein Score von 95 mit schlechten Felddaten hilft nicht beim Ranking. Felddaten aus dem Chrome UX Report sind aussagekräftiger als jeder Lab-Test.
Häufige Fragen zu Core Web Vitals
Reichen gute Core Web Vitals allein für ein Top-Ranking?
Nein. Content-Relevanz und Domain-Autorität wiegen schwerer. Googles John Mueller hat das mehrfach bestätigt: „Relevance is still by far much more important.” Aber bei gleichwertigen Inhalten entscheiden Core Web Vitals über Position 3 vs. Position 8 — und das ist ein enormer Traffic-Unterschied.
Wie schnell wirken sich Verbesserungen aus?
Felddaten im Chrome UX Report werden über 28 Tage gerollt. Nach einem Fix dauert es also 4–6 Wochen, bis Google die Verbesserung sieht. Keine Panik, wenn sich nach zwei Wochen noch nichts tut.
Gelten Core Web Vitals auch für Desktop?
Ja, aber Google nutzt seit 2024 primär Mobile-Felddaten als Ranking-Signal — auch für Desktop-Ergebnisse. Optimieren Sie zuerst für Mobile.
Was bleibt
Core Web Vitals sind kein Mysterium und kein Fulltime-Job. Mit den richtigen Bildformaten, schlankem JavaScript und sauberem Layout-Handling sind grüne Werte in den meisten Fällen innerhalb weniger Stunden erreichbar.
Die Kurzformel: schnell laden (LCP ≤ 2,5 s), schnell reagieren (INP ≤ 200 ms), nicht springen (CLS ≤ 0,1). Wenn Sie wissen wollen, wie viel Umsatz eine schnellere Website für Ihr Geschäft bedeutet, testen Sie den Performance-Rechner auf meiner Leistungsseite.