Core Web Vitals bei WordPress verbessern

In der Search Console steht unter „Core Web Vitals“ eine rote Zahl, und PageSpeed Insights zeigt dir drei Abkürzungen mit Ampelfarben. Was heißt das für deine Website, und was musst du jetzt tun?

Fürs Ranking sind die Werte ein Signal unter vielen. Deine Besucher spüren sie aber bei jedem Aufruf, vor allem am Smartphone. Bei WordPress-Websites hakt es laut HTTP Archive (Chrome-Felddaten, mobil, August 2026) am häufigsten beim LCP: Das große Element ganz oben erscheint zu spät.

Ich bin Stephan Berg, Webentwickler seit 2001. Bei huhu.media kümmere ich mich um Performance und Wartung von Websites, viele davon laufen mit WordPress. Mein Maßstab bei Kundenseiten: alle drei Werte grün in den Felddaten echter Besucher, mobil und am Desktop. Eine schöne Punktzahl im Test allein reicht mir nicht.

Was sind Core Web Vitals?

Core Web Vitals sind drei Messwerte von Google: LCP misst, wie schnell der wichtigste Inhalt sichtbar ist, INP, wie schnell die Seite auf Klicks reagiert, und CLS, wie stark das Layout beim Laden verrutscht. Erfasst werden sie bei echten Besuchern im Browser Chrome.

Grenzwerte: Was sind gute Core Web Vitals?

Metrik	Was sie misst	Gut	Verbesserungswürdig	Schlecht
LCP (Largest Contentful Paint)	Wie lange es dauert, bis das größte Element im ersten Bildschirm steht, etwa ein Bild oder die Überschrift	bis 2,5 s	über 2,5 s bis 4 s	über 4 s
INP (Interaction to Next Paint)	Wie schnell nach einem Klick, Tippen oder Tastendruck sichtbar etwas passiert	bis 200 ms	über 200 ms bis 500 ms	über 500 ms
CLS (Cumulative Layout Shift)	Wie stark Inhalte beim Laden verrutschen	bis 0,1	über 0,1 bis 0,25	über 0,25

Google bewertet das 75. Perzentil. Mindestens drei von vier Seitenaufrufen müssen den Grenzwert also schaffen. Smartphone und Desktop werden getrennt bewertet, und mobil bestehen weniger Websites. INP hat am 12. März 2024 den älteren Wert FID (First Input Delay) abgelöst. Neue Metriken oder geänderte Grenzwerte gibt es Stand Oktober 2026 nicht.

Core Web Vitals prüfen: Wo siehst du deine Werte?

Deine Core Web Vitals prüfst du kostenlos mit PageSpeed Insights für einzelne Seiten und im Core-Web-Vitals-Bericht der Search Console für die ganze Website.

Für Google zählen die Felddaten echter Chrome-Nutzer aus den letzten 28 Tagen. PageSpeed Insights zeigt sie oben, darunter steht ein einzelner Labortest mit Lighthouse samt der bekannten Punktzahl. Die Search Console trennt nach Mobil und Desktop und fasst ähnliche Seiten zu URL-Gruppen zusammen.

Wichtig in der Search Console: Der Status einer Gruppe richtet sich nach ihrer schlechtesten Metrik. Ist der LCP gut und der CLS schlecht, gilt die ganze Gruppe als schlecht. Klickst du nach einer Korrektur auf „Fix überprüfen“, beobachtet Google die Gruppe 28 Tage lang.

Den INP misst der Labortest in PageSpeed Insights nicht, weil dabei niemand klickt. Wie du Schritt für Schritt misst, steht in meiner Anleitung zum Messen der Ladezeit.

So liest du den Core-Web-Vitals-Bericht in der Search Console

Ein ausgedachtes Beispiel mit runden Zahlen: Angenommen, in deiner Search Console stehen unter Mobil 38 URLs als schlecht, 12 als verbesserungswürdig und 50 als gut. Unter Desktop ist alles grün. Als Problem nennt der Bericht für die 38 URLs einen zu hohen LCP, die Gruppe liegt bei 4,6 Sekunden. So liest du das:

Mobil zählt für sich. Der grüne Desktop gleicht nichts aus.
4,6 Sekunden sind das 75. Perzentil. Bis zu ein Viertel der mobilen Aufrufe dieser Gruppe dauert sogar länger.
38 URLs sind selten 38 Baustellen. Nutzen die Seiten dieselbe Vorlage, etwa deine Leistungsseiten mit großem Titelbild, lohnt es sich, zuerst an der gemeinsamen Vorlage im Theme zu suchen.
Jede gemeldete Metrik muss grün werden. Stünde neben dem LCP auch CLS in der Liste, bliebe die Gruppe rot, bis beide behoben sind.
Nach der Korrektur brauchst du Geduld. Die Validierung läuft ab dem Klick auf „Fix überprüfen“ 28 Tage. Ob die Korrektur gereicht hat, steht erst danach fest. Taucht das Problem vorher wieder auf, scheitert sie früher.

Sieht dein Bericht ähnlich aus? Schick mir den Link zu deiner Seite, und ich schreibe dir, welcher Wert hakt und wo der größte Hebel liegt.

Wo WordPress-Seiten bei den Core Web Vitals hängen

Das HTTP Archive schlüsselt die Chrome-Felddaten nach Content-Management-System auf. Für Smartphones sieht das mit den Daten aus dem August 2026 so aus:

Mobil, Anteil der Websites mit gutem Wert	WordPress	Alle Websites
Alle drei Core Web Vitals bestanden	48,7 %	53,0 %
LCP gut	55,8 %	65,8 %
INP gut	90,8 %	80,1 %
CLS gut	87,2 %	83,1 %
Server-Antwortzeit gut (TTFB, kein Core Web Vital)	23,5 %	45,8 %

Am Desktop bestehen 53,3 Prozent der WordPress-Websites alle drei Werte.

WordPress-Seiten hängen also beim LCP und bei der Server-Antwortzeit. Die Server-Antwortzeit (Time to First Byte) steckt im LCP: Solange der Server nicht geantwortet hat, kann der Browser nichts anzeigen.

Websites mit Elementor oder Divi bestehen mobil seltener, Elementor-Seiten zu 36,8 Prozent, Divi-Seiten zu 41,7 Prozent. Ob der Builder allein schuld ist oder Hosting und Bilder mitspielen, verraten die Zahlen nicht. Gut gebaut ist WordPress schnell genug für grüne Werte. Wie ich dabei vorgehe, steht auf der Seite über WordPress-Seiten, die ich baue.

Was die Core Web Vitals verschlechtert

Die Ursachen ähneln denen jeder langsamen Website: große Bilder, fehlender Cache, schwere Plugins und fremde Skripte. Die vollständige Liste steht im Artikel über Websites, die mit der Zeit langsamer werden. Hier geht es darum, welche Ursache welchen Wert trifft.

LCP verbessern: Wie wird das große Element oben schneller sichtbar?

Beim LCP helfen vor allem drei Dinge: ein Bild oben, das sofort und in passender Größe lädt, ein Seiten-Cache und ein Server, der schnell antwortet.

Das LCP-Element kann ein Bild, ein Video, ein Hintergrundbild aus dem CSS oder ein Textblock sein. In meinen Projekten ist es bei WordPress-Seiten meistens das Titelbild oder das erste Bild eines Sliders.

Das Bild oben

Kein Lazy Loading am Bild oben. Verzögertes Laden gehört an Bilder weiter unten. Seit WordPress 6.3 lässt WordPress das wahrscheinliche LCP-Bild davon aus und markiert es mit fetchpriority="high" als „zuerst laden“. Gibt dein Theme oder Page Builder das Bild auf eigenem Weg aus, greift das nicht zwingend.
Bild im HTML statt im CSS. Ein Bild, das nicht im HTML steht, findet der Browser erst später.
Passende Größe, modernes Format. WordPress kann WebP und AVIF, sofern die Bildbibliothek auf deinem Server mitspielt.

Server und Cache

Mobil hat nicht einmal ein Viertel der WordPress-Websites eine gute Server-Antwortzeit. WordPress bringt keinen Seiten-Cache mit. Ohne ihn baut der Server jede Seite bei jedem Aufruf neu zusammen. Im WordPress-Backend unter „Werkzeuge → Website-Zustand“ siehst du, ob ein Seiten-Cache aktiv ist und ob der Server schneller als 600 Millisekunden antwortet. Diese Schwelle hat WordPress festgelegt, von Google stammt sie nicht. Wie du einen Cache einrichtest, steht im Ratgeber für langsame WordPress-Seiten.

Blockierendes CSS und Schriften

Bevor der Browser etwas darstellt, lädt er die Stylesheets im Kopf der Seite. Ein Schrift-Stylesheet von einem fremden Server ist eines mehr, auf das er wartet. Schriften vom eigenen Server zu laden spart diesen Umweg.

Das prüfst du selbst: PageSpeed Insights zeigt dir im Labortest unter „LCP-Aufschlüsselung“, welches Element den LCP bestimmt. Ist es ein Bild, prüf Größe und Format. Unter „Website-Zustand“ siehst du, was WordPress zu Cache und Server-Antwortzeit meldet.

Das ist Entwicklerarbeit: Im Theme gebe ich dem Titelbild Vorrang und hole ein Hintergrundbild ins HTML. Ich speck das blockierende CSS ab und lade die Schriften vom eigenen Server. Für Cache und Server-Antwort braucht es oft auch den Hoster.

Hast du niemanden, der das übernimmt, oder hat es beim letzten Versuch nicht gereicht? Genau diese Arbeit mache ich, mehr dazu bei der WordPress-Wartung. Der Theme-Code meiner Projekte liegt offen auf dem Webspace des Kunden. Du bleibst also nicht an mich gebunden.

INP verbessern: Warum reagiert die Seite verzögert?

Den INP verbesserst du, indem du weniger JavaScript lädst, fremde Skripte aufräumst und die Seite schlanker aufbaust.

Der INP bewertet Klicks, Tippen und Tastendrücke, Scrollen und Zoomen zählen nicht. Der Browser erledigt vieles nacheinander. Rechnet er gerade an JavaScript, wartet dein Klick. Google nennt als Hauptursachen viel JavaScript, Skripte von Drittanbietern und einen großen DOM, also sehr viele HTML-Elemente auf einer Seite. Bei WordPress ist der INP selten das Hauptproblem: Mobil haben 90,8 Prozent der WordPress-Websites einen guten Wert. Trifft es deine Seite trotzdem, schau dir diese drei Stellen an.

Page Builder und DOM-Größe

Was ich in Projekten oft sehe: Mit Page Buildern gebaute Seiten erzeugen deutlich mehr HTML-Elemente, weil jeder Abschnitt in mehrere Container verschachtelt ist. Ältere Lighthouse-Versionen warnten ab etwa 800 Elementen und meldeten ab etwa 1.400 einen Fehler. Wie eine Seite ohne diesen Ballast aussieht, zeige ich im Vergleich Baukasten oder WordPress mit eigenem Theme.

Tracking und Tag Manager

Analyse-Tools, Chat-Bausteine und Werbe-Pixel bringen eigenes JavaScript mit. Google rät, solche Skripte mit async oder defer zu laden, Einbettungen erst bei Bedarf nachzuladen und den Tag Manager auszumisten. Dort finde ich regelmäßig Tags, die keiner mehr auswertet. Auch deshalb installiere ich kein Plugin für etwas, das sich mit wenigen Zeilen eigenem Code lösen lässt: Jedes Plugin kann eigene Skripte mitbringen.

Der Klick auf den Cookie-Banner

Was viele übersehen, ist der Klick auf „Akzeptieren“. Danach starten die freigegebenen Skripte, oft mehrere gleichzeitig. Laut Google reagiert die Seite genau dann häufig verzögert.

Das prüfst du selbst: Streich aus deiner Liste an Tracking-Tools und Einbettungen, was du nicht auswertest. Öffne deine Seite am Smartphone im privaten Fenster, tippe auf „Akzeptieren“ und achte darauf, ob die Seite danach hängt.

Das ist Entwicklerarbeit: Ich suche lange JavaScript-Aufgaben und teile sie auf. Skripte lade ich mit defer oder async. WordPress bietet das seit Version 6.3 an, Theme oder Plugin müssen es aber nutzen. Nach der Einwilligung starte ich fremde Skripte gestaffelt und sorge dafür, dass das Theme weniger HTML-Elemente erzeugt.

CLS verbessern: Warum springt der Inhalt?

Gegen springende Inhalte und einen hohen CLS helfen feste Maße für jedes Bild und jede Einbettung, vorab reservierter Platz für Banner und ein Schriftwechsel ohne Sprung.

Google sammelt Verschiebungen in Zeitfenstern von höchstens fünf Sekunden und wertet das schlimmste. Die häufigsten Auslöser laut Google:

Bilder und Videos ohne Maße. Fehlen Breite und Höhe, weiß der Browser nicht, wie viel Platz er freihalten soll.
Nachträglich eingefügte Elemente. Cookie-Hinweise, Ankündigungsbanner, Werbung, Karten und Videos ohne reservierten Platz drücken den Inhalt weg. Cookie-Hinweise zählt Google zu den sehr häufigen Quellen.
Webfonts. Wechselt der Browser von der Ersatzschrift zur eigentlichen Schrift, ändern sich die Zeilenumbrüche und der Text springt.
Animationen, die das Layout bewegen. Elemente, die per Position statt per Transformation wandern, schieben alles darunter mit.

Das prüfst du selbst: Lade deine Seite am Smartphone im privaten Fenster, damit der Cookie-Hinweis erscheint, und achte auf alles, was springt: Banner, die sich oben hineinschieben, Karten oder Videos, die erst nach dem Text auftauchen.

Das ist Entwicklerarbeit: Ich gebe Bildern und Einbettungen width und height oder ein aspect-ratio mit und reserviere Platz für Banner oder lege sie über den Inhalt. Für die Schrift helfen font-display: optional und eine per size-adjust angepasste Ersatzschrift. Animationen stelle ich auf transform um.

Brauchst du 100 Punkte bei PageSpeed Insights?

Nein. Die Punktzahl ist ein Laborwert, für Google zählen die Felddaten echter Besucher. Google schreibt selbst in seiner Doku zur Page Experience (Stand September 2026): Die Rankingsysteme nutzen die Core Web Vitals, ein einzelnes Page-Experience-Signal gibt es aber nicht. Der relevanteste Inhalt soll auch dann erscheinen, wenn seine Page Experience unterdurchschnittlich ist. Einem perfekten Wert nur fürs Ranking hinterherzulaufen, lohnt sich laut Google womöglich nicht.

Den Labortest nutze ich, um zu sehen, wo es hakt. Meine eigene Website huhu-media.de kam am 2. Oktober 2026 im Labortest mit Lighthouse 13 mobil auf 99 bis 100 Punkte, einen LCP von 1,2 bis 1,6 Sekunden und einen CLS von höchstens 0,021. Das sind Labordaten. Sie zeigen, was technisch geht. Ob Besucher es spüren, zeigen erst die Felddaten, und bei Kundenseiten schaue ich dort zuerst hin.

Dass Tempo für Besucher zählt, zeigt eine Fallstudie von Vodafone auf web.dev (2021): In einem A/B-Test ging ein um 31 Prozent besserer LCP mit 8 Prozent mehr Verkäufen einher. Das ist allerdings ein Einzelfall bei einem Großunternehmen.

Häufige Fragen zu Core Web Vitals

01 Was sind Core Web Vitals?

Core Web Vitals sind drei Messwerte von Google, die erfassen, wie schnell eine Website für echte Besucher sichtbar wird (LCP), wie schnell sie auf Eingaben reagiert (INP) und wie ruhig das Layout beim Laden bleibt (CLS). Gut sind ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1.

02 Wie kann ich meine Core Web Vitals prüfen?

Am einfachsten mit PageSpeed Insights: Oben stehen die Felddaten echter Besucher, darunter der Labortest. Für die ganze Website zeigt der Core-Web-Vitals-Bericht der Search Console, welche Seitengruppen gut oder schlecht abschneiden.

03 Wie kann ich die Core Web Vitals verbessern?

Fang mit dem schlechtesten Wert in den Felddaten an, bei WordPress ist das meist der LCP. Dort helfen ein Titelbild ohne Lazy Loading, ein Seiten-Cache und eine schnelle Server-Antwort. Den CLS senken feste Bildmaße und reservierter Platz für Banner, den INP weniger JavaScript und weniger fremde Skripte.

04 Wie wichtig sind Core Web Vitals fürs Ranking?

Googles Rankingsysteme nutzen die Core Web Vitals, aber nur als eines von vielen Signalen. Laut Google versucht die Suche, den relevantesten Inhalt zu zeigen, auch wenn seine Page Experience unterdurchschnittlich ist. Gute Werte garantieren also keine Top-Platzierung. Deine Besucher spüren eine langsame Seite trotzdem bei jedem Aufruf.

05 Warum zeigt die Search Console keine Daten zu den Core Web Vitals?

Die Search Console zeigt keine Daten, wenn die Property neu ist oder für deine Seiten zu wenige Felddaten aus Chrome vorliegen. Erfasst werden nur Chrome-Nutzer mit aktivierter Nutzungsstatistik und Verlaufs-Synchronisierung, auf dem Desktop und unter Android, nicht auf dem iPhone. Eine feste Mindestzahl an Besuchen nennt Google nicht. Solange Felddaten fehlen, hilft dir der Labortest in PageSpeed Insights.

06 Warum ist mein PageSpeed-Score gut, die Search Console meldet aber Probleme?

Der PageSpeed-Score stammt aus einem einzelnen Labortest, die Search Console zeigt Felddaten echter Besucher. Die nutzen unterschiedliche Geräte und Verbindungen, auch langsamere als im Test, und rufen Unterseiten auf, die du nicht getestet hast.

Wo fängst du an?

Öffne die Felddaten, zuerst für Mobil, und such die schlechteste Metrik. Bei WordPress ist das am häufigsten der LCP, dann führt der Weg über das Bild oben und die Server-Antwort. Halte WordPress außerdem aktuell, denn viele Tempo-Verbesserungen kommen mit den Updates. Die gehören deshalb fest zur Wartung deiner WordPress-Seite.

Zeigt sich, dass Theme oder Page Builder selbst die Bremse sind, ist ein Neuaufbau der Website manchmal der sauberere Weg. Das klären wir aber erst nach dem Blick auf die Daten, am besten in einem kostenlosen Erstgespräch.

Core Web Vitals bei WordPress: LCP, INP und CLS verstehen und verbessern