Core Web Vitals WordPress: LCP, INP, CLS erklärt
Core Web Vitals für WordPress-Betreiber: LCP, INP, CLS verständlich erklärt, Labor- vs. Felddaten und welche WP-Stellschraube welchen Wert bewegt.
Core Web Vitals sind drei Messwerte, mit denen Google die gefühlte Ladeerfahrung einer Seite quantifiziert: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Für WordPress-Betreiber sind sie relevant, weil Google Search Console und PageSpeed Insights sie direkt an dir zurückmelden — und weil sie tatsächlich mit Absprungrate und Conversion korrelieren, nicht nur mit SEO.
Dieser Artikel ordnet ein, was jede Metrik misst, was ein guter Wert ist, warum Labordaten und Felddaten auseinanderfallen können und welche konkrete WordPress-Maßnahme welchen Wert bewegt. Wenn du zuerst wissen willst, warum deine Seite überhaupt langsam wirkt, lies vorher WordPress langsam — Ursachen finden.
Warum das überhaupt zählt — jenseits von SEO
Core Web Vitals werden meist als SEO-Thema verkauft, sind aber in erster Linie ein Geschäftsthema. Google dokumentiert dazu mehrere Fallstudien mit belastbaren Zahlen: Als Vodafone Italien den LCP-Wert um 31 % verbesserte, stieg der Umsatz um 8 %, es kamen 15 % mehr Leads herein und die Cart-to-Visit-Rate verbesserte sich um 11 % (web.dev — Business Impact von Core Web Vitals). Renault wertete zehn Millionen Besuche auf seinen Landingpages aus und fand eine klare Korrelation zwischen LCP und Conversion-Rate (web.dev — Renault-Fallstudie). Diese Zahlen stammen von großen Marken mit entsprechendem Traffic — sie lassen sich nicht 1:1 auf eine kleine deutsche Business-Seite übertragen, aber die Richtung ist eindeutig: Ladeerfahrung wirkt auf das Verhalten von Menschen, nicht nur auf einen Score.
Die drei Metriken im Detail
LCP — Largest Contentful Paint
LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport gerendert ist — meist ein Hero-Bild, ein Video-Poster oder ein großer Textblock. Es ist die Metrik, die am stärksten mit „fühlt sich schnell an" korreliert, weil sie den Moment erfasst, in dem der Nutzer zum ersten Mal etwas Substanzielles sieht.
Typische WordPress-Ursachen: langsame Serverantwort (TTFB), unkomprimierte Hero-Bilder, Lazy-Loading auf dem falschen Element, render-blockendes CSS/JS vor dem LCP-Element. Ausführlich dazu: LCP verbessern WordPress.
INP — Interaction to Next Paint
INP ersetzt seit dem 12. März 2024 die frühere Metrik First Input Delay (FID) als dritten Core Web Vital (web.dev-Ankündigung). Der Unterschied ist wichtig: FID maß nur die erste Interaktion, INP misst die Reaktionszeit über die gesamte Sitzung — von Klick oder Tap bis zum nächsten sichtbaren Frame.
Das macht INP unbequemer, aber ehrlicher. Eine Seite kann beim ersten Klick blitzschnell reagieren und trotzdem bei jedem weiteren Klick hakeln, wenn im Hintergrund viel JavaScript läuft. Bei WordPress sind die üblichen Verdächtigen: Drittanbieter-Skripte, aufgeblähte Page-Builder-JS-Bundles (Elementor, Divi) und — häufig unterschätzt — Cookie-Consent-Banner. Deren Zustimmungs-Skripte verarbeiten den Klick auf „Akzeptieren" oft synchron und blockieren dabei den Hauptthread, was messbar schlechte INP-Werte erzeugt (DebugBear-Analyse zu Consent-Bannern, SpeedCurve zu Cookie-Consent-Performance). Das ist ein Kapitel, das in deutschen Ratgebern fast nie vorkommt, obwohl Consent-Banner hierzulande praktisch Pflicht sind — und ein Grund mehr, das eigene Banner so schlank wie möglich zu halten, statt ein schweres Consent-Management-Skript eines Drittanbieters nachzuladen.
CLS — Cumulative Layout Shift
CLS misst, wie stark sich sichtbare Elemente unerwartet verschieben, während die Seite lädt — der Effekt, wenn du auf einen Button tippen willst und stattdessen auf eine nachträglich eingeblendete Werbung klickst, weil sich das Layout verschoben hat. Typische WordPress-Ursachen: Bilder ohne width/height-Attribute, nachladende Webfonts ohne reservierten Platz, spät eingeblendete Cookie-Banner oder Werbe-Slots.
Die Schwellenwerte
Google definiert für jede Metrik drei Bänder — „gut", „verbesserungswürdig" und „schlecht" — bewertet am 75. Perzentil aller Seitenaufrufe (offizielle Herleitung der Schwellenwerte):
| Metrik | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | ≤ 0,25 | > 0,25 |
Wichtig ist das „75. Perzentil": Es reicht nicht, dass deine Seite im Test einmal gut abschneidet. Mindestens drei von vier echten Seitenaufrufen müssen im grünen Bereich liegen, damit Google die Seite insgesamt als „gut" einstuft.
Labordaten vs. Felddaten — und warum deine Seite oft keine Felddaten hat
Hier trennen sich zwei völlig unterschiedliche Datenquellen, die ständig verwechselt werden:
Labordaten entstehen bei einem einzelnen, kontrollierten Testlauf — so, wie es unser Speed-Test-Tool oder Lighthouse in den Chrome-DevTools macht. Simulierte Netzwerkbedingungen, ein Durchlauf, ein Ergebnis. Reproduzierbar, aber nicht identisch mit dem, was echte Besucher auf echten Geräten und echten Leitungen erleben.
Felddaten stammen aus dem Chrome User Experience Report (CrUX) — echten, anonymisierten Messwerten von Chrome-Nutzern, die deine Seite tatsächlich besucht haben. Das ist die Datenbasis, die Google Search Console in ihrem Core-Web-Vitals-Bericht anzeigt und die für die Rankingbewertung herangezogen wird.
Die ehrliche Einordnung: CrUX nimmt nur Seiten und Domains auf, die eine Mindest-Popularität erreichen — die genaue Zahl veröffentlicht Google nicht, geschätzt bewegt sie sich im Bereich weniger Tausend Chrome-Sitzungen pro Monat (CrUX-Methodik). Für die überwiegende Mehrheit kleiner und mittlerer WordPress-Seiten in Deutschland heißt das: Es gibt schlicht keine Felddaten. Das ist kein Fehler, kein Zeichen einer kaputten Messung und keine schlechte Nachricht — es bedeutet nur, dass zu wenige Chrome-Nutzer die Seite in einem repräsentativen Zeitraum besucht haben. Wer PageSpeed Insights aufruft und dort „Es sind keine Daten für diese Seite verfügbar" liest, sollte sich stattdessen auf die Labordaten und den eigenen Hausverstand verlassen: Fühlt sich die Seite beim Klicken schnell an? Das ist am Ende die Metrik, die zählt.
Wie du misst: PSI, Lighthouse und unser Speed-Test im Vergleich
Für Labordaten stehen dir drei praktisch gleichwertige Werkzeuge zur Verfügung, die alle auf derselben Lighthouse-Engine basieren:
- PageSpeed Insights (PSI) von Google selbst — kombiniert Labordaten mit Felddaten, sofern letztere vorhanden sind.
- Chrome DevTools (Lighthouse-Tab) — dieselbe Engine, lokal in deinem Browser, ohne Wartezeit auf einen externen Server.
- Unser Speed-Test — führt Lighthouse lokal auf unseren eigenen Servern in Deutschland aus und liefert das Ergebnis direkt mit WordPress-Einordnung: welche Auffälligkeit vermutlich welche WP-Ursache hat, ohne dass du Rohdaten selbst interpretieren musst. Ergebnis ohne E-Mail-Eingabe und ohne Übermittlung deiner URL an Dritte.
Da alle drei Werkzeuge letztlich auf Lighthouse aufsetzen, sind unterschiedliche Werte zwischen ihnen normal — Labormessungen schwanken von Durchlauf zu Durchlauf um mehrere Punkte, abhängig von Serverauslastung im Messmoment, Netzwerkbedingungen der Simulation und sogar der Tageszeit. Eine einzelne Messung ist eine Momentaufnahme, kein Urteil. Miss bei wichtigen Entscheidungen (z. B. vor/nach einem Hosting-Wechsel) mehrfach und zu unterschiedlichen Zeiten.
Realistische Erwartungen je nach Website-Typ
Nicht jede Seite muss auf dieselbe Weise optimiert werden, weil die Ausgangslage unterschiedlich ist:
- Reiner Blog/Content-Seite: Meist die einfachste Ausgangslage — wenig Interaktivität bedeutet meist unproblematisches INP, der Fokus liegt auf LCP (Hero-Bild, Hosting) und CLS (Bilder, Werbeanzeigen).
- WooCommerce-Shop: Deutlich anspruchsvoller — Produktfilter, Warenkorb-Updates und Zahlungs-Widgets belasten INP zusätzlich, viele Produktbilder belasten LCP der Kategorieseiten. Hier lohnt sich oft ein performance-fokussierter Hoster mehr als bei einer reinen Content-Seite.
- Seite mit vielen eingebetteten Drittanbieter-Widgets (Buchungssysteme, Kartenintegrationen, Bewertungs-Widgets): INP wird hier fast immer zur Hauptbaustelle, weil du auf fremden Code angewiesen bist, den du nur verzögert, aber nicht optimieren kannst.
Was du nicht brauchst: Du musst nicht für jede Unterseite denselben perfekten Wert anstreben. Priorisiere die Seiten mit dem meisten Traffic und der größten Geschäftsrelevanz (Startseite, Kategorieseiten, Landingpages) — eine selten besuchte Unterseite mit mittelmäßigem CLS-Wert ist keine dringende Baustelle.
Welche WP-Stellschraube welchen Wert bewegt
| Maßnahme | Wirkt primär auf | Artikel |
|---|---|---|
| Hosting-Wechsel / Server-Cache | LCP (über TTFB) | TTFB verbessern |
| Hero-Bild optimieren, kein Lazy-Load beim LCP | LCP | LCP verbessern |
| Seitenweites Caching-Plugin | LCP, teils INP | Cache-Plugin-Vergleich |
Bilder komprimieren, width/height setzen | LCP, CLS | Bilder optimieren |
| JavaScript verzögern/aufteilen (Page-Builder-Skripte) | INP | — |
| Schlankes, selbst gehostetes Consent-Banner | INP | — |
| Google Fonts lokal statt von Google-Servern | CLS (Font-Swap), zusätzlich DSGVO-relevant | DSGVO-CDN |
| Reservierte Platzhalter für Bilder/Embeds | CLS | — |
Google-Ranking-Einordnung — ohne Übertreibung
Google selbst formuliert das zurückhaltend: „There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience" — und weiter: „Google Search always seeks to show the most relevant content, even if the page experience is sub-par" (Google Search Central — Page Experience). Core Web Vitals sind also ein Signal unter vielen, kein Hebel, der eine inhaltlich schwache Seite an schwächeren Wettbewerbern vorbeischießen lässt. In der Praxis wirken sie am ehesten als Tie-Breaker zwischen inhaltlich ähnlich starken Seiten.
Die ehrliche Aussage, die hier hingehört: Wenn dein Content im Vergleich zur Konkurrenz schwächer ist, rettet dich ein perfekter Lighthouse-Score von 100 nicht. Umgekehrt gilt aber auch: Nutzer verzeihen eine ruckelnde, langsame Seite nicht, egal wie gut der Text ist. Core Web Vitals lohnen sich wegen der Nutzererfahrung — die Ranking-Wirkung ist ein netter Nebeneffekt, kein Wundermittel.
FAQ
Muss ich alle drei Metriken gleichzeitig „gut" haben? Für die Google-Gesamtbewertung „gute URL-Erfahrung" ja — alle drei müssen im grünen Bereich liegen. Für die praktische Priorität reicht es, mit der schlechtesten Metrik anzufangen. Miss zuerst mit unserem Speed-Test, welche das bei dir ist.
Warum zeigt Google Search Console andere Werte als mein Lighthouse-Test? Search Console nutzt Felddaten (CrUX, echte Nutzer über 28 Tage), Lighthouse liefert Labordaten (ein simulierter Durchlauf). Beide sind korrekt — sie messen nur unterschiedliche Dinge.
Meine Seite hat keine Felddaten. Ist das ein Problem? Nein. Das ist bei kleinen und mittleren Seiten der Normalfall, weil die Mindest-Traffic-Schwelle von CrUX nicht erreicht wird. Verlass dich in diesem Fall auf Labordaten und wiederholte eigene Messungen.
Ist INP schwerer zu beheben als LCP? Meistens ja, weil INP an JavaScript-Ausführung hängt und nicht an Bildkompression. Der schnellste Hebel ist häufig, Drittanbieter-Skripte (Tracking, schwere Consent-Banner, Chat-Widgets) zu reduzieren statt eigenen Code zu optimieren.
Reicht ein gutes Theme, um alle drei Werte zu erfüllen? Nein. Ein schlankes Theme hilft, ersetzt aber nicht Hosting, Bildoptimierung und Caching. Die Stellschrauben-Tabelle oben zeigt, dass die drei Metriken an unterschiedlichen Baustellen hängen — ein Theme-Wechsel allein löst höchstens eine davon.
Weiterführend: Die komplette Roadmap in sinnvoller Reihenfolge findest du unter WordPress schneller machen. Für den direkten Test deiner eigenen Seite: Speed-Test starten — ohne E-Mail-Eingabe, Ergebnis in 20–60 Sekunden.