Core Web Vitals in echt: Die 10 häufigsten Bremsen (und schnelle Fixes)

Core Web Vitals sind kein Meme. Sie sind ein ziemlich ehrlicher Reality-Check: Lädt’s schnell (LCP), reagiert’s fix (INP) und bleibt’s stabil (CLS)?

Das Problem: Viele optimieren „für den Screenshot“. Lab-Tools sehen gut aus, aber in der echten Welt (Mobile, langsames Netz, Third-Party-Wildwuchs) bricht’s ein.

In diesem Artikel bekommst du: typische Ursachen, schnelle Fixes, einen Tool-Guide (was misst was?) und eine Checkliste, wie du das Ganze sauber durchziehst.

Core Web Vitals: was zählt wirklich?

Core Web Vitals bestehen aus drei Metriken: LCP (Loading), INP (Interaktivität) und CLS (Stabilität). INP hat dabei FID als Core Web Vital ersetzt (seit März 2024). Wenn du noch irgendwo FID siehst: Das ist historisch, nicht mehr der aktuelle Kern.

Wichtig: Google und die Search Console sprechen bei CWV primär über echte Nutzerdaten (Field Data). Lab-Tools (Lighthouse) sind super zum Reproduzieren und Fixen – aber sie sind nicht die Wahrheit in Stein gemeißelt.

Richtwerte, die du im Kopf haben willst

• LCP: gut ≤ 2,5 s (danach „needs improvement“, schlecht ab 4,0 s)
• INP: gut ≤ 200 ms (danach „needs improvement“, schlecht ab 500 ms)
• CLS: gut ≤ 0,1 (danach „needs improvement“, schlecht ab 0,25)

Lab vs. Field: warum du beides brauchst

• Field (CrUX / Search Console / PageSpeed Insights Field): zeigt, wie echte Nutzer deine Seite erleben (über Zeit, Geräte, Netze).
• Lab (Lighthouse): zeigt, wo es hakt und hilft beim Debuggen in einer kontrollierten Umgebung.

Tool-Realität: Wer misst was – und wann glaubst du wem?

Die 10 häufigsten Bremsen (und schnelle Fixes)

1) Render-blocking CSS/JS im Head (LCP leidet sofort)

Wenn der Browser erst mal eine halbe Bibliothek parsen muss, bevor irgendwas sichtbar wird, ist dein LCP praktisch schon verloren.

• Fix: Unnötiges CSS aus dem kritischen Pfad raus (splitten), nur wirklich kritisches CSS früh laden.
• Fix: Nicht-kritisches JS später laden oder auf echte Notwendigkeit prüfen.
• Fix: Komponenten-/Page-Splitting, damit nicht jede Seite alles lädt.

2) Hero-Image ist riesig, falsch priorisiert oder „aus Versehen lazy“ (LCP-Killer #1)

Das größte Element im Viewport ist häufig ein Bild. Wenn das zu spät kommt: LCP ist spät. Punkt.

• Fix: Hero-Asset komprimieren und in modernen Formaten ausliefern (sofern möglich).
• Fix: Hero nicht lazy-loaden. Lazy ist super – aber nicht fürs wichtigste Element.
• Fix: CDN/Cache nutzen, damit das Bild schnell aus der Nähe kommt.

3) Hoher TTFB (Server, Hosting, Cache) zieht LCP mit runter

Wenn der erste Byte ewig braucht, kann vorne einfach nichts schnell sein. LCP hängt dann oft an Backend/Cache statt an „Frontend-Tweaks“.

• Fix: Vollseiten-Cache für öffentliche Seiten (wo möglich).
• Fix: Datenbank-/API-Hotspots identifizieren (langsame Queries, zu viele Calls).
• Fix: CDN + Caching-Header sauber setzen (auch für HTML, wenn’s passt).

4) Zu viel Third-Party (Tag Manager, Consent, Chat, A/B, Widgets) macht alles zäh (LCP + INP)

Third-Party ist oft „einfach reingeklickt“. Aber jede zusätzliche Script-Kette frisst CPU, blockiert Main Thread und verschiebt Rendering.

• Fix: Inventur: Was bringt wirklich Geld/Value? Was ist nur „nice to have“?
• Fix: Laden nach Zustimmung/Interaktion/Timeout (je nach Consent-Konzept).
• Fix: Self-hosting prüfen (z.B. Fonts/Skripte), wenn das Setup es erlaubt.

5) Zu viel JavaScript auf dem Main Thread (INP explodiert)

INP misst, wie schnell nach einer Interaktion etwas sichtbar passiert. Wenn dein Main Thread gerade mit Parsing, Hydration oder Long Tasks beschäftigt ist: Game over.

• Fix: JS-Bundles kleiner machen (Dependencies raus, tree-shaking, splitting).
• Fix: Long Tasks reduzieren (heavy work chunking, weniger Re-Renders).
• Fix: Interaktionen priorisieren: Click/Type muss sofort feedback geben, nicht „nach 800ms“.

6) Hydration-/Framework-Overhead (INP & gefühlte Speed)

Viele Seiten rendern erst mal HTML, dann kommt die Hydration und plötzlich ruckelt alles. Das fühlt sich wie „kaputt“ an – und INP kann darunter leiden.

• Fix: Interaktive Inseln statt „alles ist interaktiv“ (weniger Hydration-Fläche).
• Fix: Komponenten ausmisten: weniger Client-State, weniger unnötige Effekte.
• Fix: Prüfen, ob bestimmte Widgets wirklich clientseitig sein müssen.

7) Layout Shifts durch fehlende Größen (Bilder, Ads, Embeds) (CLS)

CLS entsteht oft nicht durch „Mystery“, sondern durch fehlenden reservierten Platz. Der Content rutscht, Nutzer klicken daneben. Hass.

• Fix: Für Bilder/Embeds immer feste Abmessungen bzw. Platz reservieren.
• Fix: Ads nur in Container mit stabiler Höhe (oder mit klaren Slots) ausspielen.
• Fix: UI-Elemente nicht „oben reinschieben“ (Banner/Consent), sondern überlagern oder Platz einkalkulieren.

8) Fonts verursachen Sprünge oder blockieren Rendering (CLS + LCP)

Webfonts sind oft unterschätzt: Sie können Rendering verzögern oder Layout ändern, wenn die Fallback-Schrift andere Maße hat.

• Fix: Fonts minimieren (weniger Schnitte/Weights), nur wirklich genutzte Glyphen/Styles.
• Fix: Fallbacks so wählen, dass Layout möglichst ähnlich bleibt.
• Fix: Selbst hosten kann helfen (weniger externe Roundtrips), wenn’s bei dir sauber gecacht ist.

9) „Lazy alles“: falsches Lazy-Loading verschlimmert LCP

Lazy-Loading ist super – bis du das LCP-Element lazy machst oder Above-the-Fold Assets „versteckst“.

• Fix: Lazy nur für Below-the-Fold. Above-the-Fold: priorisieren.
• Fix: Auf mobilen Viewports prüfen (anderer Above-the-Fold als Desktop!).
• Fix: Nicht blind optimieren: erst LCP-Element identifizieren, dann entscheiden.

10) Mess-Setup ist falsch (du optimierst am Problem vorbei)

Wenn du nur Lab misst oder nur eine einzelne URL anschaust, optimierst du gern die falsche Ecke. CWV sind am Ende Statistik über echte Nutzer.

• Fix: Field-Daten als Kompass (Search Console/CrUX), Lab als Werkzeugkasten.
• Fix: Nach Seitentypen clustern (Startseite, Kategorie, Artikel, Produkt, Checkout).
• Fix: Änderungen kontrolliert ausrollen und Regressionen tracken (z.B. per Lighthouse CI).

So setzt du’s um: Quick-Wins in 60–120 Minuten

Schritt-für-Schritt (Mini-Use-Case: „Artikel-Seite ist langsam“)

1. Field-Check: Search Console → Core Web Vitals: Welche URL-Gruppe ist „poor“ (LCP/INP/CLS)?
2. LCP-Element finden: PageSpeed Insights/Lighthouse: Was ist das LCP-Element (oft Hero-Bild oder Headline-Block)?
3. Quick Fix 1: Hero-Asset: Komprimieren, richtig ausliefern, nicht lazy-loaden.
4. Quick Fix 2: Third-Party Inventur: Alles, was nicht muss, später oder raus.
5. Quick Fix 3: CLS-Stopper: Platz reservieren (Bilder/Embeds/Ads) + Banner/Consent ohne Layout-Schub.
6. Verifizieren: Lighthouse im Incognito/Throttle als Lab-Indikator – und danach Field-Verlauf beobachten (nicht nach 10 Minuten nervös werden).

Checkliste (kurz, brutal ehrlich)

• Ist das LCP-Element wirklich priorisiert (und nicht lazy)?
• Wie viele Third-Party Skripte laufen vor der ersten Interaktion?
• Gibt’s Layout Shifts durch Images/Embeds/Ads/Consent?
• Ist Server/Cache so aufgestellt, dass TTFB nicht der Flaschenhals ist?
• Messe ich Field und Lab – und verwechsel das nicht?

Typische Fehler & wie du sie vermeidest

• Fehler: Nur Lighthouse-Score jagen. Fix: Field-Daten als Ziel, Lighthouse als Debug.
• Fehler: „Lazy-Loading überall“. Fix: Above-the-Fold priorisieren, Below-the-Fold lazy.
• Fehler: Third-Party wächst unkontrolliert. Fix: Tag-Inventur + Regeln (wer darf was rein?)
• Fehler: CLS „kommt halt“. Fix: Platz reservieren, Banner/Ads sauber einhegen.
• Fehler: Mobile wird nicht ernst genommen. Fix: Mobile Viewport prüfen: anderes LCP-Element, andere Netz-/CPU-Realität.

Fazit: Was du als Nächstes tun solltest

Wenn du schnell Wirkung willst: Hero/LCP priorisieren + Third-Party reduzieren + CLS durch Platzreservierung stoppen. Das sind die drei Hebel, die in der Praxis am häufigsten sofort was bringen.

Nächster Schritt: Nimm dir 30 Minuten, schau in die Search Console (CWV Report), wähle einen Seitentyp als Ziel (z.B. Artikel oder Produkt), und arbeite die Top-3-Bremsen aus diesem Artikel durch. Danach erst der nächste Seitentyp. Nicht alles gleichzeitig, sonst wird’s Chaos.

FAQ