Core Web Vitals für WordPress: Optimierungsleitfaden (2026)

WordPress und Core Web Vitals: Der aktuelle Stand

WordPress hat ein Performance-Problem. Laut dem Core Web Vitals Technology Report (basierend auf CrUX-Daten) liegt WordPress bei den Bestehensquoten der mobilen Core Web Vitals durchgehend hinter Shopify, Wix und Squarespace. Ende 2025 bestanden nur rund 44 % der mobilen WordPress-Websites alle drei Core Web Vitals. Bei Shopify sind es rund 65 % und bei Wix über 60 %.

Das liegt nicht daran, dass WordPress von Natur aus langsam wäre. Der WordPress-Core ist schlank. Das Problem ist das, was darauf aufbaut: überladene Themes, aufgeblähte Page-Builder, dutzende Plugins, die jeweils eigenes JavaScript und CSS einbinden, unoptimierte Bilder und billiges Shared-Hosting mit langsamen Server-Antwortzeiten.

Der Vorteil: WordPress gibt dir die volle Kontrolle über deinen Code, das Hosting und deine Optimierungsstrategie. Genau deshalb bewirkt gezielte Optimierung hier am meisten. Die Websites, die ich betreue, bestehen die Core Web Vitals auf jeder einzelnen Seite. Entscheidend ist, die WordPress-spezifischen Faktoren für jede Metrik zu verstehen und sie systematisch anzugehen.

WordPress Core Web Vitals in Zahlen

Der CrUX Technology Report und das HTTP Archive erfassen die CWV-Bestehensquoten aller großen CMS. Hier steht WordPress Ende 2025:

Quelle: CrUX Technology Report via HTTP Archive, Juni 2025. INP-Rankings aus einer Analyse von SearchEngineJournal.

Die wichtigste Erkenntnis aus diesen Daten: Das Problem von WordPress ist nicht der INP (85,9 % Bestehensquote, nur knapp unter dem Durchschnitt). Das Problem von WordPress ist der LCP, verursacht durch eine langsame TTFB. Laut CrUX-Daten haben nur 32 % der WordPress-Websites eine gute TTFB. Bei voll gehosteten Plattformen wie Shopify wird die TTFB hingegen auf Infrastrukturebene gelöst. Das ist ein Problem der Hosting-Qualität, kein Problem der Plattform.

Bei den von CoreDash überwachten WordPress-Websites zeigt sich durchgehend dasselbe Muster: Vor der Optimierung liegt der mediane mobile LCP zwischen 3,5 und 4,5 Sekunden. Nach den in diesem Leitfaden beschriebenen Optimierungen an Hosting, Caching und Bildern fällt der Median auf 1,6 bis 2,1 Sekunden. Die wirkungsvollste Einzelmaßnahme ist fast immer der Wechsel von Shared-Hosting ohne Page-Caching zu Managed-Hosting mit serverseitigem Caching und einem CDN. Das allein senkt die TTFB typischerweise von über 800 ms auf unter 200 ms.

Warum sich WordPress mit den Core Web Vitals schwertut

Bevor wir zu den Lösungen kommen, musst du die fünf Hauptursachen verstehen, warum WordPress-Websites bei den Core Web Vitals durchfallen. Jedes Problem, das mir in meiner Beratungspraxis begegnet, lässt sich auf mindestens eine davon zurückführen:

1. Überladene Page-Builder

Page-Builder wie Elementor, Divi und WPBakery blähen jede Seite mit gewaltigen Mengen an zusätzlichem HTML, CSS und JavaScript auf. Elementor allein kann eine WordPress-Installation um über 21 MB entpackten Code vergrößern. Jedes Widget, jede Animation und jede Styling-Option vergrößert das DOM und erhöht die Menge an Render-Blocking-Ressourcen.

Das Ergebnis: überladene Seiten mit hunderten überflüssigen <div>-Wrapper-Elementen, mehrere CSS-Dateien auf jeder Seite – unabhängig davon, ob deren Widgets genutzt werden – und JavaScript, das beim Laden den Main Thread blockiert. Das schadet direkt dem LCP (mehr Render-Blocking-Ressourcen), dem INP (mehr JavaScript konkurriert um den Main Thread) und dem CLS (Layout-Neuberechnungen beim Laden des Builder-CSS).

Gutenberg (der native Block-Editor von WordPress) erzeugt deutlich saubereres HTML mit wesentlich kleinerem DOM-Footprint. Wenn du eine neue WordPress-Website aufbaust, nimm lieber Gutenberg mit einem schlanken Theme wie GeneratePress, Astra oder Kadence statt eines schweren Page-Builders.

2. Plugin-Overload

Die durchschnittliche WordPress-Website nutzt 20 bis 30 aktive Plugins. Jedes Plugin kann auf jeder Seite eigenes CSS und JavaScript einbinden – selbst dort, wo das Plugin gar nicht gebraucht wird: Ein Kontaktformular-Plugin lädt seine Skripte auf der Startseite. WooCommerce-Skripte laufen in Blogbeiträgen. Ein Slider-Plugin lädt überall, obwohl du es nur auf einer einzigen Seite nutzt.

In meinen Audits von WordPress-Websites hat das Entfernen ungenutzter Plugin-Skripte das gesamte JavaScript oft um über 40 % reduziert. Die Lösung ist nicht zwingend, Plugins komplett zu löschen. Es geht um Conditional Loading: Stelle sicher, dass die Assets eines Plugins nur auf den Seiten laden, auf denen sie wirklich gebraucht werden. Plugins wie Perfmatters und Asset CleanUp geben dir für jede Seite die genaue Kontrolle darüber, welche Skripte und Styles laden.

3. Unoptimierte Bilder

WordPress erzwingt standardmäßig keine Bildoptimierung. Redakteure laden Fotos mit 3000 × 2000 Pixeln direkt aus der Kamera hoch. WordPress liefert sie in voller Auflösung aus – selbst wenn das Theme sie nur 800 Pixel breit anzeigt. Auf den meisten WordPress-Seiten ist das LCP-Element ein Bild. Ein unoptimiertes Hero-Bild ist die häufigste Ursache für ein Durchfallen beim LCP.

WordPress 5.8+ brachte native WebP-Unterstützung und WordPress 5.5+ natives lazy loading. Beide Features müssen jedoch sauber konfiguriert sein. Viele Themes und Plugins überschreiben sie oder bringen eigene – oft schlechtere – Varianten mit. Die vollständige Strategie findest du in unserem Leitfaden zur Bildoptimierung für Core Web Vitals.

4. Langsames Hosting und Server-Antwortzeiten

Die Time to First Byte (TTFB) deines Servers definiert die Untergrenze für deinen LCP. Keine Frontend-Optimierung kann einen Server ausgleichen, der 800 ms für eine Antwort braucht. Billiges Shared-Hosting, bei dem sich hunderte Websites einen einzigen Server teilen, ist die häufigste Ursache für eine schlechte TTFB bei WordPress.

WordPress ist ein dynamisches CMS: Bei jedem Seitenaufruf wird PHP ausgeführt und eine MySQL-Datenbank abgefragt – es sei denn, Caching ist aktiv. Ohne Page-Caching ist WordPress prinzipbedingt langsamer als statische Seiten. Mit sauberem Caching und einem guten Hoster liegt die TTFB unter 200 ms. Ohne Caching sind 500 ms bis 1500 ms die Regel. Mehr dazu erfährst du in unserem Leitfaden zur Optimierung der Time to First Byte.

5. Probleme beim Font-Loading

Viele WordPress-Themes laden Google Fonts von Google-Servern. Das erfordert einen DNS-Lookup und den Verbindungsaufbau zu einer externen Domain, bevor Schriften überhaupt heruntergeladen werden können. Das verzögert das Rendering von Text (was den LCP bei textbasierten LCP-Elementen verschlechtert) und kann zu einem Flash of Unstyled Text (FOUT) führen: Sobald der Webfont nachlädt und den Fallback ersetzt, entsteht CLS.

Die Lösung: Hoste deine Fonts selbst und nutze font-display: swap oder font-display: optional zusammen mit einem exakt abgestimmten Fallback-Font, um Layout-Shifts zu minimieren.

LCP bei WordPress optimieren

Der Largest Contentful Paint misst, wie schnell dein Hauptinhalt sichtbar wird. Bei WordPress lassen sich LCP-Probleme fast immer auf Bilder, Render-Blocking-Ressourcen oder langsame Server-Antwortzeiten zurückführen. Das ist die Prioritätenliste, um den LCP zu beheben:

Finde dein LCP-Element

Teste deine Seite mit PageSpeed Insights und schaue unter „Diagnose“ nach dem Eintrag „Largest Contentful Paint-Element“. Auf den meisten WordPress-Seiten ist das das Hero-Bild, das Beitragsbild (Featured Image) oder der erste große Textblock. Erst wenn du dein LCP-Element kennst, kannst du die richtige Optimierungsstrategie wählen.

LCP-Bild per Preload laden

Ist dein LCP-Element ein Bild, setze einen Preload-Hint in den <head> deines Themes. In WordPress fügst du das über die functions.php deines Themes ein:

// Preload the hero image on the homepage
function preload_lcp_image() {
    if ( is_front_page() ) {
        echo '<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">';
    }
}
add_action( 'wp_head', 'preload_lcp_image', 1 );

Setze außerdem fetchpriority="high" direkt in das <img>-Tag deines LCP-Bildes. WordPress 6.3+ erledigt das für das erste Bild im Content automatisch. Prüfe aber nach, ob dein Theme das auch wirklich umsetzt. Die vollständige Anleitung findest du unter LCP-Bild per Preload laden.

Render-Blocking-Ressourcen beseitigen

WordPress-Themes und -Plugins binden oft CSS und JavaScript im <head> ein, die das Rendering blockieren. Nutze ein Performance-Plugin, um unkritisches JavaScript per Defer zu laden und unkritisches CSS asynchron bereitzustellen. Die wirksamsten Optionen:

• WP Rocket: verzögert die JavaScript-Ausführung bis zur Nutzerinteraktion, generiert Critical CSS automatisch
• FlyingPress: schlanke Alternative mit ähnlichen Funktionen für Defer und Critical CSS
• Perfmatters: detaillierte Skriptverwaltung pro Seite, deaktiviert ungenutzte Funktionen
• Unser WP-Core-Web-Vitals-Plugin: speziell für die CWV-Optimierung entwickelt, mit LCP-Erkennung und optimiertem Bild-Timing

Wenn du die manuelle Kontrolle bevorzugst, siehe 14 Methoden, um JavaScript verzögert zu laden und Critical CSS generieren und einbinden.

Page-Caching aktivieren

Page-Caching speichert das fertig gerenderte HTML jeder Seite. So muss WordPress nicht bei jedem Aufruf PHP ausführen und die Datenbank abfragen. Das senkt die TTFB drastisch und verbessert den LCP direkt. Die meisten guten Managed-WordPress-Hoster (Kinsta, SiteGround, WP Engine, Cloudways) bieten serverseitiges Caching ab Werk. Fehlt das bei deinem Hoster, installiere ein Caching-Plugin.

Richte zusätzlich ein CDN ein, um gecachte Seiten von Edge-Standorten nahe an deinen Besuchern auszuliefern. Siehe dazu: Cloudflare für maximale Performance konfigurieren.

INP bei WordPress optimieren

Der Interaction to Next Paint misst, wie schnell deine Website auf Klicks, Taps und Tastendrücke reagiert. WordPress-Websites fallen beim INP durch, wenn zu viel JavaScript den Main Thread belegt. Das sind die Hauptursachen:

Das JavaScript-Problem durch Plugins

Jedes installierte Plugin kann JavaScript mitbringen, das bei jedem Seitenaufruf ausgeführt wird. Selbst wenn ein Besucher eine Funktion nie nutzt, konkurriert deren JavaScript trotzdem um Rechenzeit auf dem Main Thread. Klickt der Besucher dann auf einen Button, kann der Browser erst reagieren, wenn der Main Thread wieder frei ist.

Miste deine Plugins schonungslos aus. Frage dich bei jedem einzelnen: Muss das auf diesem Seitentyp wirklich laden? Prüfe mit dem Coverage-Tab in den Chrome DevTools, wie viel JavaScript auf den einzelnen Seiten ungenutzt bleibt. Schalte über ein Script-Manager-Plugin gezielt Skripte auf Seiten ab, auf denen sie überflüssig sind.

WooCommerce-Skripte gezielt steuern

WooCommerce gehört bei WordPress zu den größten Verursachern von INP-Problemen. Standardmäßig lädt WooCommerce sein JavaScript und CSS auf jeder einzelnen Seite – auch in Blogbeiträgen und auf statischen Seiten ohne jede Shop-Funktion. Nutze ein Plugin wie Disable WooCommerce Bloat oder Perfmatters, damit WooCommerce-Assets außerhalb des Shops gar nicht erst geladen werden.

Drittanbieter-Skripte per Defer und Delay laden

Google Analytics, Facebook-Pixel, Google Tag Manager, Chat-Widgets und Marketing-Tools bringen allesamt JavaScript mit, das den Main Thread blockiert. Die effektivste Strategie: Verzögere (delay) diese Skripte bis zur ersten Interaktion des Nutzers (Scrollen, Klick oder Tastendruck). So beeinträchtigen Drittanbieter-Skripte die Reaktionszeit der Seite beim Laden überhaupt nicht.

Die Funktion „Delay JavaScript Execution“ von WP Rocket erledigt das automatisch. Alternativ kannst du das auch manuell umsetzen – siehe unseren Leitfaden zu Methoden zum Verzögern von JavaScript.

CLS bei WordPress beheben

Der Cumulative Layout Shift misst unerwartete Layout-Verschiebungen. WordPress-Websites fallen beim CLS vor allem wegen fehlender Bildabmessungen, nachladender Schriften und dynamisch eingefügter Inhalte durch.

Bildabmessungen festlegen

Jedes <img>-Tag braucht feste Attribute für width und height, damit der Browser den Platz vor dem Laden des Bildes reservieren kann. WordPress setzt diese seit Version 5.5 automatisch. Viele Themes überschreiben dieses Verhalten jedoch oder nutzen eigenes Bild-Markup ohne Abmessungen. Kontrolliere die Bild-Templates deines Themes und stelle sicher, dass die Maße vorhanden sind.

Platz für Anzeigen und dynamische Inhalte reservieren

Werbeplätze, Cookie-Banner, Newsletter-Popups und Hinweisleisten, die nach dem Laden Inhalte einfügen, sind bei WordPress die häufigsten Auslöser für CLS. Reserviere für diese Elemente festen Platz per CSS über min-height, damit der umgebende Inhalt beim Einblenden nicht springt.

Layout-Shifts durch Schriften beheben

Wenn ein Webfont lädt und den Fallback-Font ersetzt, kann der Text neu umbrechen und umliegende Elemente verschieben. Die Lösung besteht aus zwei Schritten: Hoste deine Fonts selbst (das spart den externen DNS-Lookup) und konfiguriere dein CSS mit font-display: optional oder einem sauber angepassten Fallback über die CSS-Eigenschaft size-adjust. So springt der Text selbst dann nicht, wenn der Webfont spät lädt. Eine ausführliche Anleitung findest du in unserem Leitfaden zur CLS-Optimierung.

WordPress-Hosting und Core Web Vitals

Dein Hosting-Anbieter setzt das Performance-Limit für deine WordPress-Website. So wirken sich die gängigen Hosting-Typen auf die Core Web Vitals aus:

Liegt deine TTFB dauerhaft über 400 ms, bringt dich keine Frontend-Optimierung auf einen guten LCP-Wert. Upgrade zuerst dein Hosting. Managed-WordPress-Hoster wie SiteGround, Kinsta und Cloudways bieten serverseitiges Caching, PHP 8.x und CDN-Anbindung, was die TTFB drastisch reduziert.

Die CrUX-Daten bestätigen, dass hier das größte Problem von WordPress liegt: Nur 32 % der WordPress-Websites haben eine gute TTFB. Auf voll gehosteten Plattformen wie Shopify und Wix wird die Infrastruktur hingegen komplett gemanagt. Field Data von CoreDash zeigt dasselbe Bild: WordPress-Websites auf Shared-Hosting erreichen im Schnitt eine p75-TTFB von 900 ms bis 1400 ms. Zieht dieselbe Seite auf ein Managed-Hosting mit serverseitigem Caching um, fällt der Wert auf 120 ms bis 250 ms. Dieser eine Schritt bringt den LCP oft von „schlecht“ auf „gut“ – ganz ohne weitere Optimierungen.

Page-Builder im Performance-Vergleich

Die Wahl des Page-Builders (oder der Verzicht darauf) ist die folgenschwerste Architekturentscheidung für die Core Web Vitals bei WordPress. Das zeigt sich in meinen Audits immer wieder:

Wenn du bereits Elementor oder Divi nutzt und nicht migrieren kannst: Aktiviere die Funktionen „Optimized DOM Output“ und „Optimized Asset Loading“, entferne ungenutzte Widgets und Animationen und fange den zusätzlichen Overhead mit einem Caching-Plugin wie WP Rocket ab.

Field Data von CoreDash aus WordPress-Websites zeigt dasselbe Bild. Mit Gutenberg und schlanken Themes erstellte Seiten erreichen durchgehend einen medianen mobilen LCP unter 2,0 Sekunden. Elementor-Websites vor der Optimierung zeigen typischerweise einen medianen mobilen LCP von 3,8 bis 5,2 Sekunden. Diese Lücke geht fast vollständig auf zusätzliches render blocking CSS und JavaScript zurück. Nach der Optimierung (Critical CSS, verzögertes JS, reduziertes DOM) können Elementor-Websites 2,0 bis 2,8 Sekunden erreichen. Sie erfordern jedoch ständige Wartung, da Updates von Plugins und dem Builder den Bloat oft wieder zurückbringen.

Checkliste zur Optimierung der Core Web Vitals für WordPress

Hier ist die systematische Vorgehensweise, die ich bei der Optimierung von WordPress-Websites für die Core Web Vitals anwende. Arbeite die Punkte der Reihe nach ab:

Infrastruktur (zuerst erledigen)

• Wechsle zu Managed-WordPress-Hosting mit serverseitigem Caching und PHP 8.x
• Richte ein CDN ein (Cloudflare-Setup-Anleitung)
• Aktiviere Page-Caching (serverseitig oder über WP Rocket / LiteSpeed Cache)
• Aktiviere GZIP- oder Brotli-Komprimierung

Theme und Builder

• Wechsle nach Möglichkeit zu einem schlanken Theme (GeneratePress, Astra, Kadence)
• Falls du einen Page-Builder nutzt: Aktiviere die optimierte DOM-Ausgabe und optimiertes Asset-Loading
• Entferne ungenutzte Theme-Funktionen, Widgets und Animationen
• Aktualisiere den WordPress-Core, dein Theme und alle Plugins auf die neuesten Versionen

Bilder

• Lade das LCP-Bild per Preload mit fetchpriority="high" vor
• Konvertiere Bilder mit ShortPixel, Imagify oder Smush nach WebP oder AVIF
• Liefere responsive Bilder mit sauberen srcset- und sizes-Attributen aus
• Ergänze alle <img>-Tags um feste Angaben für width und height
• Nutze KEIN lazy loading für Bilder Above the Fold (das verschlechtert den LCP)

JavaScript und CSS

• Lade unkritisches JavaScript per Defer
• Verzögere Drittanbieter-Skripte bis zur Nutzerinteraktion
• Generiere und binde Critical CSS inline ein
• Entferne ungenutzte Plugin-Skripte pro Seite mit Perfmatters oder Asset CleanUp
• Deaktiviere WooCommerce-Assets auf Seiten außerhalb des Shops

Fonts

• Hoste Google Fonts selbst
• Lade kritische Font-Dateien per Preload vor
• Nutze font-display: swap oder optional
• Beschränke dich auf maximal 2 Schriftfamilien

Monitoring

• Richte CoreDash Real User Monitoring ein, um kontinuierlich field data zu erfassen
• Prüfe den Core-Web-Vitals-Bericht in der Google Search Console wöchentlich
• Teste nach jedem Theme-Update, Plugin-Wechsel oder Content-Update erneut

Die vollständige, plattformübergreifende Checkliste für alle Optimierungsbereiche findest du in unserer ultimativen Core-Web-Vitals-Checkliste.

Core Web Vitals bei WordPress messen

WordPress hat kein integriertes Reporting für die Core Web Vitals. Du brauchst externe Tools, um deine Performance zu messen:

• Google Search Console: zeigt auf Basis echter CrUX-field data, welche Seiten deiner gesamten Website bestehen oder durchfallen. Prüfe den Bericht „Core Web Vitals“ unter „Erfahrung“.
• PageSpeed Insights: testet einzelne URLs sowohl mit field data (CrUX) als auch mit lab data (Lighthouse). Nutze das Tool zur Diagnose konkreter Einzelseiten.
• CoreDash: Real User Monitoring, das dir field data in Echtzeit liefert – aufgeschlüsselt nach Seite, Gerät, Land und einzelnen Elementen. Anders als das rollierende 28-Tage-Fenster von CrUX zeigt CoreDash die direkten Auswirkungen deiner Optimierungen sofort.
• Chrome DevTools: Nutze das Performance-Panel, um Long Tasks zu finden, die den INP blockieren, und den Coverage-Tab, um ungenutztes JavaScript und CSS aufzuspüren.

Einen vollständigen Vergleich dieser Tools samt Vergleichstabelle findest du in unserer Übersicht zu den Core Web Vitals.

Typische Fehler bei den Core Web Vitals in WordPress

Aus meiner Erfahrung bei Audits hunderter WordPress-Websites sind das die häufigsten Fehler:

• Lazy loading auf dem LCP-Bild. WordPress versieht Bilder standardmäßig mit loading="lazy". Ist dein Hero-Bild das LCP-Element, verzögert lazy loading den Abruf. Stelle sicher, dass das LCP-Bild vom lazy loading ausgenommen ist und fetchpriority="high" besitzt.
• Zu viele Optimierungs-Plugins. Werden WP Rocket, Autoptimize, LiteSpeed Cache und W3 Total Cache gleichzeitig installiert, führt das zu Konflikten. Entscheide dich für ein einziges Caching- bzw. Optimierungs-Plugin und konfiguriere es sauber.
• Field data ignorieren. Ein Lighthouse-Score von 95 bedeutet nicht, dass du die Core Web Vitals bestehst. Google bewertet die field data echter Besucher. Und deine echten Besucher auf ihren realen Geräten erleben oft etwas ganz anderes. Prüfe immer die Search Console oder nutze RUM.
• Keine Tests nach Updates. Ein Theme- oder Plugin-Update kann die Core Web Vitals unbemerkt verschlechtern. Führe ein kontinuierliches Monitoring durch – nicht nur einmalig nach der Optimierung.