Seit 2021 sind Core Web Vitals ein offizieller Google-Ranking-Faktor. Websites, die diese Performance-Schwellenwerte nicht erfüllen, verlieren sichtbar an Rankings — besonders in umkämpften Märkten wie Essen und dem Ruhrgebiet. Dieser Guide erklärt, was Core Web Vitals sind und wie Sie sie messbar verbessern.
Was sind Core Web Vitals?
Core Web Vitals sind drei messbare Nutzer-Erfahrungs-Metriken, die Google 2020 als Teil seines Page Experience Signals eingeführt hat. Seit 2024 ersetzt INP die ältere FID-Metrik:
| Metrik | Was sie misst | Gut | Verbesserungsbedarf | Schlecht |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | Ladegeschwindigkeit des größten sichtbaren Elements | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP — Interaction to Next Paint | Reaktionsfähigkeit auf Nutzereingaben | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Visuelle Stabilität (kein Layoutsprung) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
LCP: Largest Contentful Paint optimieren
LCP misst, wie schnell das größte sichtbare Element geladen wird — meist das Hero-Bild oder die H1-Überschrift. Ein LCP über 2,5 Sekunden signalisiert Google: Diese Seite ist langsam.
Häufige LCP-Probleme und ihre Lösung
1. Nicht-optimiertes Hero-Bild
Das Hero-Bild ist bei den meisten Websites das LCP-Element. Optimieren Sie es:
- Format: WebP statt JPEG/PNG spart 30–80 % Dateigröße
- Komprimierung: 75–85 % Qualität reicht für Web-Darstellung
- Dimensionen: Laden Sie das Bild in der tatsächlich angezeigten Größe hoch — nicht 4K für eine 1200px-Spalte
fetchpriority="high": Sagen Sie dem Browser explizit, dieses Bild zuerst zu ladenloading="eager": Kein Lazy-Loading für das LCP-Element!
<!-- Richtig: Hero-Bild mit Priorisierung -->
<img
src="/images/hero.webp"
alt="SEO Agentur Essen Team"
width="1200"
height="630"
fetchpriority="high"
loading="eager"
decoding="async"
/>
2. Render-Blocking Resources
CSS- und JavaScript-Dateien, die im <head> geladen werden, blockieren das Rendering. Lösungen:
- CSS: Kritisches CSS inline in
<style>im<head>, restliches CSSasyncladen - JavaScript:
deferoderasyncAttribut nutzen, Scripts ans Ende des<body>verlagern - Fonts:
font-display: swapverhindert unsichtbaren Text während des Ladens
3. Langsamer Server (TTFB)
Time to First Byte (TTFB) über 800 ms verzögert alles nachfolgende. Maßnahmen:
- CDN (Content Delivery Network) nutzen — Netlify und Vercel liefern statische Assets automatisch vom nächstgelegenen Server
- Hosting-Anbieter wechseln wenn nötig — shared Hosting ist oft zu langsam
- Server-Side Caching für dynamische Seiten
4. Fehlende <link rel="preload"> Direktive
Wenn das LCP-Bild tief in einem JavaScript-Bundle oder CSS-Hintergrundimage liegt, findet der Browser es zu spät. Lösung: Explizites Preloading im <head>:
<link
rel="preload"
as="image"
href="/images/hero.webp"
type="image/webp"
/>
INP: Interaction to Next Paint optimieren
INP misst die Reaktionszeit vom Klick/Tippen des Nutzers bis zur sichtbaren Reaktion der Seite. Es löst die alte FID-Metrik ab und ist deutlich strenger.
Was verursacht schlechte INP-Werte?
Hauptverursacher:
- Schwere JavaScript-Bundles: Zu viel JavaScript blockiert den Main Thread
- Long Tasks: JavaScript-Aufgaben über 50 ms blockieren die Reaktionsfähigkeit
- Render-Blocking Third-Party-Scripts: Chat-Widgets, Analytics, Ad-Scripts
- Unnötige Re-Renders in React/Vue: Zu viele State-Updates gleichzeitig
INP verbessern
JavaScript-Bundle minimieren:
- Tree Shaking: Nur genutzter Code wird gebündelt
- Code Splitting: JavaScript wird in kleinere Chunks aufgeteilt, die bei Bedarf geladen werden
- Unnötige Dependencies entfernen
Third-Party-Scripts verzögern:
<!-- Analytics erst nach Seiteninteraktion laden -->
<script>
window.addEventListener('load', () => {
// Analytics-Script hier laden
});
</script>
Long Tasks aufbrechen:
Nutzen Sie scheduler.yield() oder setTimeout(fn, 0), um lange JavaScript-Aufgaben in kleinere Einheiten aufzuteilen.
CLS: Cumulative Layout Shift eliminieren
CLS misst, ob Seitenelemente unerwartet ihre Position ändern während die Seite lädt. Wenn ein Nutzer auf einen Button klickt, der gerade verschoben wurde — das ist CLS.
Häufige CLS-Ursachen
1. Bilder ohne Dimensionen
Das häufigste CLS-Problem: Bilder ohne feste Größenangaben. Der Browser reserviert keinen Platz und fügt ihn erst ein, wenn das Bild geladen ist — alles darunter verschiebt sich.
<!-- Falsch: Kein width/height -->
<img src="/bild.jpg" alt="..." />
<!-- Richtig: Explizite Dimensionen -->
<img src="/bild.jpg" alt="..." width="800" height="450" />
Mit CSS aspect-ratio können Sie den Platz vorhalten, ohne pixelgenaue Angaben zu brauchen:
img {
aspect-ratio: 16/9;
width: 100%;
height: auto;
}
2. Web Fonts laden verzögert
Wenn eine Web-Font spät geladen wird, wechselt der Browser von der Fallback-Schrift zur geladenen Font — das erzeugt Layout-Shifts.
Lösungen:
font-display: optional(Font wird nur genutzt wenn sofort verfügbar)font-display: swapkombiniert mit Font-Preloading- Schriften lokal hosten statt von Google Fonts (CDN-Anbieter = externe Verbindung)
3. Dynamisch injizierter Content
Ads, Newsletter-Banner oder Cookie-Consent-Popups, die nach dem initialen Rendering erscheinen, verschieben das Layout.
Lösung: Platz für dynamischen Content vorher reservieren:
/* Platz für Cookie-Banner reservieren */
.cookie-banner-placeholder {
height: 72px; /* Erwartete Höhe des Banners */
}
4. Animationen mit top/left/width/height
CSS-Animationen, die Layout-Eigenschaften animieren (top, left, width, height, margin), erzeugen Layout-Recalculations und CLS.
Lösung: Nur transform und opacity für Animationen nutzen:
/* Schlecht: Erzeugt CLS */
.btn:hover { margin-top: -2px; }
/* Gut: Kein Layout-Recalculation */
.btn:hover { transform: translateY(-2px); }
Core Web Vitals messen
Google PageSpeed Insights
Das wichtigste Tool: pagespeed.web.dev. Analysiert sowohl Labor-Daten als auch Field Data (echte Nutzerdaten aus dem Chrome UX Report).
Wichtig: Field Data > Lab Data. Googles Ranking basiert auf echten Nutzerdaten, nicht auf Labortests.
Google Search Console
Unter Experience → Core Web Vitals sehen Sie eine URL-Liste mit schlechten Werten aus echten Nutzerdaten. Priorisieren Sie Seiten mit dem meisten Traffic.
Chrome DevTools
Für Entwickler: Performance-Tab → Live-Aufzeichnung zeigt Long Tasks, LCP-Kandidaten und Layout-Shifts mit ihren Ursachen.
Lighthouse (lokal)
# Lighthouse CLI für lokale Tests
npx lighthouse https://ihre-website.de --output html --view
Realistische Verbesserungsstrategie
Verbessern Sie Core Web Vitals nicht alle auf einmal. Priorisieren Sie nach Impact:
-
Quick Wins (1–2 Stunden):
- Alle
<img>mit width/height versehen - Hero-Bild mit
fetchpriority="high"undloading="eager"versehen font-display: swapin allen @font-face Regeln
- Alle
-
Mittel (halber Tag):
- Bilder nach WebP konvertieren
- Third-Party-Scripts verzögern
- Kritisches CSS inline setzen
-
Aufwändig (1–3 Tage):
- JavaScript-Bundle analysieren und reduzieren
- Code Splitting implementieren
- CDN einrichten
Core Web Vitals und SEO: Die Realität
Google betont, dass Core Web Vitals zwar Ranking-Faktoren sind, aber Relevanz und Content immer überwiegen. Eine Seite mit exzellentem Content und schlechtem CWV kann eine Seite mit perfektem CWV und schwachem Content übertrumpfen.
Dennoch: Bei vergleichbarer Content-Qualität — wie es in Essen bei lokalen Suchanfragen häufig der Fall ist — kann die bessere Performance den Ausschlag geben. Und abgesehen vom SEO-Effekt: Schnelle Seiten konvertieren schlicht besser. Jede Sekunde längere Ladezeit kostet durchschnittlich 7 % Conversion-Rate.
Wenn Sie professionelle Hilfe bei der Optimierung Ihrer Core Web Vitals und des technischen SEO benötigen, kontaktieren Sie uns — wir analysieren Ihre Website kostenlos.