Core Web Vitals sind drei Messwerte von Google, die bestimmen, wie gut Ihre Website für Nutzer funktioniert — und seit 2021 fließen sie direkt ins Google-Ranking ein. In diesem Guide zeige ich Ihnen die WordPress-spezifischen Stellschrauben, die in meinen Kundenprojekten den größten Unterschied machen. Keine Theorie, sondern getestete Maßnahmen mit echten Vorher-Nachher-Zahlen.
Was sind Core Web Vitals genau?
Core Web Vitals bestehen aus drei Metriken: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift). Google hat sie eingeführt, um die Nutzererfahrung messbar zu machen. Klingt technisch — ist aber im Kern simpel: Wie schnell sieht der Besucher den Hauptinhalt? Wie schnell reagiert die Seite auf Klicks? Und springt etwas herum beim Laden?
Seit März 2024 hat Google INP (Interaction to Next Paint) als Ablösung von FID (First Input Delay) eingeführt. INP ist strenger: Es misst nicht nur die erste Interaktion, sondern die langsamste während des gesamten Seitenbesuchs. Das hat dazu geführt, dass viele Websites, die vorher „grün“ waren, plötzlich Probleme zeigen.
LCP — Largest Contentful Paint
Zielwert: unter 2,5 Sekunden. LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport geladen ist. Das ist meistens ein Hero-Bild, eine Überschrift oder ein Video-Thumbnail. Laut Google verfehlen 47 % aller mobilen Websites diesen Wert (Chrome UX Report, 2025). Das ist fast die Hälfte.
Bei einem Kundenprojekt (Handwerksbetrieb, 12 Seiten) lag der LCP bei 6,8 Sekunden. Die Ursache: Ein unkomprimiertes Hero-Bild mit 3,2 MB. Nach Konvertierung zu WebP (180 KB) und korrektem Preloading: 1,9 Sekunden. Problem gelöst, kein Plugin nötig.
INP — Interaction to Next Paint
Zielwert: unter 200 Millisekunden. INP misst die Reaktionszeit auf Nutzerinteraktionen — Klicks, Tippen, Tastatureingaben. Wenn Ihre Seite nach einem Klick auf den Warenkorb-Button 500 ms braucht, um zu reagieren, fühlt sich das träge an. Und Google bestraft es.
Die häufigsten INP-Killer bei WordPress: zu viele DOM-Elemente (mehr als 1.500), schlecht geschriebene jQuery-Plugins und Third-Party-Skripte wie Chat-Widgets oder Analytics-Tools, die den Main Thread blockieren.
CLS — Cumulative Layout Shift
Zielwert: unter 0,1. CLS misst, wie stark sich das Layout während des Ladevorgangs verschiebt. Sie kennen das: Sie wollen einen Link klicken, und plötzlich rutscht der Inhalt nach unten, weil eine Werbung oder ein Bild nachgeladen wird. Genau das ist CLS.
Die Lösung ist fast immer dieselbe: Feste Breiten- und Höhenangaben für Bilder und Iframes setzen. WordPress macht das seit Version 5.5 automatisch für Bilder im Content — aber Header-Bilder, Widgets und manuell eingebundene Elemente brauchen Sie weiterhin selbst.
Welche WordPress-Plugins verbessern die Core Web Vitals am meisten?
WP Rocket ist das effektivste Einzeltool für WordPress-Performance. Es kombiniert Page Caching, CSS/JS-Minifizierung, Lazy Loading und Database Cleanup in einem Plugin. Das spart Ihnen die Installation von 4-5 Einzelplugins — und die damit verbundenen Kompatibilitätsprobleme.
Meine Plugin-Empfehlungen nach Erfahrung:
Caching: WP Rocket (49 USD/Jahr) oder LiteSpeed Cache (kostenlos, aber nur auf LiteSpeed-Servern). WP Rocket hat bei 23 von 25 Kundenprojekten die besten Ergebnisse geliefert. LiteSpeed Cache ist technisch gleichwertig, wenn Ihr Hoster LiteSpeed nutzt.
Bildoptimierung: ShortPixel oder Imagify. Konvertieren Sie alle Bilder zu WebP — das spart im Schnitt 30-40 % Dateigröße gegenüber JPEG. Noch besser: AVIF. Aber AVIF wird von Safari erst seit Version 16 (September 2022) unterstützt, und ältere Browser brauchen einen Fallback. In der Praxis fahre ich aktuell mit WebP als Standard am sichersten.
Schriften: OMGF (Fonts lokal hosten) oder manuelles Self-Hosting. Google Fonts extern einzubinden ist seit dem DSGVO-Urteil von Januar 2022 sowieso problematisch. Lokales Hosting löst beides: Datenschutz und Performance. Font-Display: swap nicht vergessen — sonst sehen Besucher kurz gar keinen Text.
Wie messe ich meine Core Web Vitals korrekt?
Nutzen Sie Google PageSpeed Insights mit Felddaten (CrUX), nicht nur Lab-Daten. Der Unterschied ist relevant: Lab-Daten zeigen, wie Ihre Seite unter Idealbedingungen performt (schnelle Verbindung, leistungsstarkes Gerät). Felddaten zeigen, was echte Nutzer erleben — auf ihren 4 Jahre alten Smartphones mit mobilem Datenvolumen.
Mein Workflow bei jedem neuen Projekt:
- Google PageSpeed Insights (pagespeed.web.dev) — Ausgangswert ermitteln, sowohl Mobil als auch Desktop
- Google Search Console → Core Web Vitals Report — Zeigt Probleme auf URL-Gruppen-Ebene
- Chrome DevTools → Performance Tab — Für die technische Detailanalyse (Long Tasks, Layout Shifts)
- WebPageTest.org — Filmstrip-Ansicht zeigt genau, wann welches Element sichtbar wird
Ein Fehler, den ich anfangs selbst gemacht habe: Nur die Startseite testen. Google bewertet jede URL einzeln. Eine Seite mit 95 Punkten nützt nichts, wenn 30 andere Seiten unter 50 liegen.
Welche Optimierungen bringen am meisten?
Die drei wirkungsvollsten Maßnahmen sind (in dieser Reihenfolge): Server-seitiges Caching, Bildoptimierung und kritisches CSS. Alles andere kommt danach.
Hier meine Vorher-Nachher-Ergebnisse aus einem konkreten Projekt — ein Rechtsanwalt mit WordPress, Divi-Theme, 35 Seiten, Shared Hosting bei einem deutschen Anbieter:
| Metrik | Vorher | Nachher | Maßnahme |
|---|---|---|---|
| LCP (Mobil) | 5,4 s | 2,1 s | WebP-Bilder + Preload Hero |
| INP | 380 ms | 140 ms | JS Defer + jQuery Migrate entfernt |
| CLS | 0,28 | 0,04 | Feste Bildmaße + Font-Display: swap |
| Lighthouse Score | 38 | 91 | Alle Maßnahmen kombiniert |
| TTFB | 1,8 s | 0,3 s | WP Rocket Page Cache |
Der Lighthouse-Score stieg von 38 auf 91 — und das ohne Server-Wechsel oder Theme-Änderung. Nur durch Optimierung des Bestands.
Welche WordPress-spezifischen Fehler ruinieren die Performance?
Zu viele Plugins sind der häufigste Grund für langsame WordPress-Seiten. Jedes Plugin lädt eigenes CSS und JavaScript — auf jeder einzelnen Seite, auch wenn es dort gar nicht gebraucht wird. Ein Kontaktformular-Plugin, das sein 80 KB schweres JavaScript auch auf der Startseite lädt? Alltag.
Meine Top-5 der Performance-Killer:
- Slider-Plugins — Revolution Slider lädt 350+ KB JS/CSS. Nutzen Sie stattdessen native CSS-Animationen oder einfache Hero-Bilder.
- Social-Sharing-Plugins — Laden externe Skripte von Facebook, Twitter, Pinterest. Jedes einzelne blockiert den Seitenaufbau. Alternative: Statische SVG-Icons mit einfachen Share-Links.
- Google Fonts über das Theme — Extern geladene Schriften erzeugen Render-Blocking-Requests. Lösung: Fonts lokal hosten.
- Nicht optimierte Bilder — Ein einzelnes 4-MB-PNG kann den LCP auf über 8 Sekunden treiben. Immer komprimieren, immer.
- Zu viele HTTP-Requests — 20 CSS-Dateien und 15 JS-Dateien? Zusammenfassen (WP Rocket macht das automatisch) und nur laden, was auf der aktuellen Seite gebraucht wird.
Wie optimiere ich Lazy Loading richtig?
Lazy Loading beschleunigt den initialen Seitenaufbau, indem Bilder erst geladen werden, wenn sie in den sichtbaren Bereich scrollen. WordPress bringt seit Version 5.5 natives Lazy Loading mit (loading=“lazy“ Attribut). Das funktioniert grundsätzlich gut — mit einer wichtigen Ausnahme.
Das Hero-Bild und die ersten sichtbaren Bilder im Viewport dürfen NICHT lazy geladen werden. Sonst verschlechtert sich Ihr LCP, weil der Browser das wichtigste Bild erst lädt, wenn es zu spät ist. In WordPress müssen Sie dafür das loading-Attribut manuell auf „eager“ setzen oder — eleganter — fetchpriority=“high“ hinzufügen. WP Rocket erledigt das seit Version 3.16 automatisch für das erste Bild.
Wenn Sie tiefer in die technische Seite der Website-Performance einsteigen wollen, empfehle ich meinen Artikel über Website-Performance und Ladezeit. Dort erkläre ich die geschäftlichen Auswirkungen langsamer Websites mit konkreten Conversion-Zahlen.
Lohnt sich die Optimierung wirklich?
Ja, und zwar messbar. Google hat in einer Studie mit 11.000 Websites nachgewiesen, dass eine Verbesserung der Core Web Vitals die Absprungrate um bis zu 24 % senkt (Google Web.dev, 2023). Bei E-Commerce-Seiten steigen die Conversion Rates um durchschnittlich 8 % pro Sekunde schnellerer Ladezeit — das sind Zahlen von Deloitte Digital aus einer Studie mit 37 Marken.
In meiner Agentur sehe ich den Zusammenhang bei praktisch jedem Projekt. Der Rechtsanwalt aus dem Beispiel oben? Seine Kontaktanfragen stiegen um 34 % im Monat nach der Optimierung. War das alles die Performance? Nein, sicher nicht — der Zeitraum ist zu kurz für eine sichere Aussage. Aber die Tendenz ist klar.
Der beste Zeitpunkt, Ihre Core Web Vitals zu prüfen, ist jetzt. Der zweitbeste: vor dem nächsten Google-Update. Und falls Sie sich fragen, ob Ihr CMS dabei eine Rolle spielt — ja, WordPress ist mit dem richtigen Setup konkurrenzfähig. Lesen Sie dazu auch meinen Vergleich von WordPress und Webflow.