Core Web Vitals in WordPress verbessern: LCP, CLS und INP gezielt senken

Die Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite beschreibt: Wie schnell erscheint der wichtigste Inhalt (LCP), wie ruhig bleibt das Layout beim Laden (CLS) und wie schnell reagiert die Seite auf Klicks und Eingaben (INP). Diese Anleitung zeigt, wie Sie die Werte richtig messen, welche Optimierungen WordPress bereits selbst vornimmt und wo Sie gezielt nachhelfen. Die WordPress-Mechanismen wurden im Labor mit WordPress 7.1.2 nachgeprüft.

Voraussetzungen

• WordPress: aktuelle Version, hier 7.1.2. Die automatische Bildpriorisierung gibt es seit WordPress 6.3, spekulatives Laden seit 6.8.
• PHP: mindestens 7.4 laut WordPress-API, besser eine aktuelle, unterstützte Version wie PHP 8.4 (im Labor verwendet).
• Rolle: Administrator im WordPress-Backend, um Plugins zu installieren und Einstellungen zu ändern.
• Zugriff: FTP oder SSH, falls Sie ein kleines Must-Use-Plugin anlegen möchten (Schritt 6). Alle anderen Schritte gehen im Backend.
• Werkzeuge: ein aktueller Chrome oder Edge mit Entwicklerwerkzeugen und Zugang zu PageSpeed Insights, idealerweise auch zur Google Search Console Ihrer Domain.
• Backup: eine aktuelle Sicherung von Dateien und Datenbank, bevor Sie Plugins installieren oder das Theme ändern. Größere Umbauten testen Sie auf einer Staging-Umgebung.

Schritt 1: Ausgangswerte mit Felddaten erfassen

Bevor Sie etwas ändern, brauchen Sie belastbare Ausgangswerte. Google unterscheidet zwei Arten von Daten: Felddaten stammen von echten Chrome-Nutzern und beschreiben laut Google-Dokumentation die vergangenen 28 Tage. Labordaten entstehen bei einem simulierten Seitenaufruf auf einem einzelnen Gerät mit festen Netzbedingungen. Die bekannte Punktzahl von 0 bis 100 in PageSpeed Insights ist ein Laborwert.

Die Grenzwerte für „gut“ legt web.dev so fest:

Messwert	Misst	Gut
LCP (Largest Contentful Paint)	Ladezeit des größten sichtbaren Elements	bis 2,5 Sekunden
INP (Interaction to Next Paint)	Reaktionszeit auf Klicks, Tippen, Tasten	bis 200 Millisekunden
CLS (Cumulative Layout Shift)	unerwartete Layoutverschiebungen	bis 0,1

Maßgeblich ist das 75. Perzentil, getrennt nach Mobilgeräten und Desktop. Drei Viertel Ihrer Seitenaufrufe müssen also den Grenzwert einhalten. Prüfen Sie in PageSpeed Insights die Startseite und zwei typische Unterseiten. Hat Ihre Website zu wenig Besucher, zeigt PageSpeed Insights keine Felddaten. Dann arbeiten Sie mit Labordaten und achten auf Tendenzen statt auf einzelne Zahlen, denn die Punktzahl schwankt von Messung zu Messung.

Notieren Sie für jede Seite LCP, INP und CLS mobil und am Desktop sowie das Element, das PageSpeed Insights als LCP-Element nennt.

Verifizieren: Sie haben eine kleine Tabelle mit Ausgangswerten je Seite und wissen, welcher der drei Werte am weitesten vom Ziel entfernt ist. Dort setzen Sie zuerst an.

Schritt 2: Verstehen, was WordPress bereits optimiert

Im Labor haben wir eine Seite mit sechs Bildern aus der Mediathek im Standard-Theme Twenty Twenty-Five angelegt und den ausgelieferten HTML-Code untersucht. Das Ergebnis:

• Das erste große Bild erhielt fetchpriority="high". Laut WordPress-Entwicklerhinweis zu Version 6.3 lädt der Browser dieses mutmaßliche LCP-Bild damit bevorzugt, was den LCP typischerweise um 5 bis 10 Prozent verbessert.
• Die ersten drei Bilder blieben ohne Lazy Loading, alle weiteren erhielten loading="lazy". Die Grenze von drei Elementen liefert die Funktion wp_omit_loading_attr_threshold(), im Labor mit dem Rückgabewert 3.
• Jedes Bild erhielt width, height und ein srcset mit mehreren Größen, der Browser lädt also passend zur Bildschirmbreite.

Daraus folgt: Laden Sie Bilder über die Mediathek hoch und fügen Sie sie mit dem Bild-Block ein. Dann greifen diese Automatismen.

Verifizieren: Öffnen Sie eine Seite, rufen Sie mit Rechtsklick „Seitenquelltext anzeigen“ auf und suchen Sie nach fetchpriority. Das Attribut sollte genau an Ihrem großen Bild im oberen Bereich stehen, nicht an einem Logo oder Symbol.

Schritt 3: LCP verbessern

Der LCP hängt an drei Dingen: wie schnell der Server die Seite liefert, wie schnell das LCP-Element geladen wird und ob etwas das Anzeigen blockiert.

Server-Antwortzeit: PageSpeed Insights zeigt den Wert „Time to First Byte“ (TTFB). Ist er hoch, hilft keine Bildoptimierung. Typische Ursachen sind fehlendes Page-Caching, eine veraltete PHP-Version oder ein überlasteter Tarif. Wie Sie PHP sicher aktualisieren, beschreibt die Anleitung PHP-Version für WordPress aktualisieren.

LCP-Bild: Laden Sie das Kopfbild nicht größer hoch als nötig und über die Mediathek. Im Labor zeigte sich eine Falle: Ein Bild aus der Mediathek, das per HTML-Block mit der Klasse wp-image-ID eingebunden war, bekam von WordPress noch width, height, srcset und fetchpriority. Ein Bild von einer fremden Adresse ohne diese Klasse bekam dagegen nur decoding="async", keine Maße und keine Priorität. Bilder als CSS-Hintergrund, etwa in manchen Slidern und Page-Buildern, erkennt WordPress ebenfalls nicht.

Blockierende Ressourcen: Jedes Plugin, das eigene CSS- und JavaScript-Dateien auf jeder Seite einbindet, verlängert den Weg bis zur ersten Anzeige. Prüfen Sie, welche Plugins Sie wirklich brauchen.

Verifizieren: Nach jeder Änderung messen Sie die betroffene Seite erneut in PageSpeed Insights. Der Labor-LCP sollte sinken, und in den Diagnosen zum LCP-Element sollte das Bild mit hoher Priorität und ohne Lazy Loading erscheinen.

Schritt 4: CLS verhindern

Layoutverschiebungen entstehen, wenn der Browser für ein Element keinen Platz reserviert und es später nachschiebt.

• Bilder: web.dev empfiehlt, immer width und height anzugeben oder den Platz per CSS aspect-ratio zu reservieren. Bei Mediathek-Bildern macht WordPress das selbst (Schritt 2). Kontrollieren Sie Bilder in HTML-Blöcken, Widgets und Theme-Vorlagen.
• Einbettungen: Videos, Karten und Social-Media-Beiträge laden oft verzögert und schieben den Text nach unten. Geben Sie dem umgebenden Block eine feste Höhe oder ein Seitenverhältnis. Das Plugin „Embed Optimizer“ aus dem Performance-Lab-Paket reserviert laut Beschreibung Platz für Einbettungen.
• Banner und Hinweise: Ein Cookie-Banner, das den Inhalt nach unten drückt, erzeugt CLS. Banner, die über dem Inhalt liegen, verschieben nichts. Prüfen Sie die Einstellungen Ihres Consent-Plugins.
• Schriften: Wechselt die Schrift nach dem Laden, verschiebt sich der Text. Twenty Twenty-Five bindet seine Schriften lokal mit font-display:fallback ein, das zeigte der Quelltext im Labor.

Verifizieren: In Chrome öffnen Sie die Entwicklerwerkzeuge mit F12, wechseln zum Bereich „Performance“ und laden die Seite neu. Verschiebungen erscheinen als „Layout shift“ in der Zeitleiste. In PageSpeed Insights sollte die Diagnose zu Layoutverschiebungen keine Elemente mehr nennen.

Schritt 5: INP senken

INP misst die Zeit von einer Interaktion bis zur nächsten sichtbaren Reaktion. Laut web.dev besteht sie aus Eingabeverzögerung, Verarbeitungsdauer und Darstellungsverzögerung. Auf WordPress-Seiten ist die Hauptursache fast immer JavaScript, das den Hauptthread blockiert: Tracking, Chat-Widgets, Slider, Page-Builder-Effekte und Pop-ups.

1. Listen Sie in PageSpeed Insights in den Diagnosen zur JavaScript-Ausführungszeit die Skripte mit der längsten Laufzeit auf und ordnen Sie sie Plugins oder externen Diensten zu.
2. Entfernen Sie Skripte ohne klaren Nutzen.
3. Laden Sie Werkzeuge nur dort, wo sie gebraucht werden. Viele Formular- und Slider-Plugins bieten eine Einstellung, ihre Dateien nur auf Seiten mit dem jeweiligen Element auszugeben.
4. Testen Sie Klicks auf Menü, Suchfeld und Formularfelder mit dem Bereich „Performance“ der Entwicklerwerkzeuge. Lange Aufgaben erscheinen dort rot markiert.

Ein schlankes Block-Theme ohne Page-Builder hat hier einen strukturellen Vorteil. Wer ein bestehendes Theme anpasst, sollte das in einem Child-Theme tun, siehe Child-Theme anlegen.

Verifizieren: Klicken Sie mit geöffneter Performance-Aufzeichnung auf das Menü. Die Interaktion sollte in der Zeitleiste unter 200 Millisekunden bleiben. Die Felddaten in PageSpeed Insights reagieren erst über die folgenden Wochen, weil sie 28 Tage abbilden.

Schritt 6: Performance Lab und spekulatives Laden gezielt nutzen

Das Plugin Performance Lab stammt vom WordPress-Performance-Team und bündelt Funktionen, die später teils in WordPress selbst übernommen werden. Im Labor installierten wir Version 4.2.0. Nach der Aktivierung finden Sie unter „Einstellungen > Performance“ die einzelnen Funktionen, jede mit eigenem Button „Aktivieren“: unter anderem „Image Prioritizer“, „Embed Optimizer“, „Image Placeholders“, „Modern Image Formats“, „Instant Back/Forward“ und „Speculative Loading“. Aktivieren Sie nur eine Funktion auf einmal und messen Sie danach, sonst wissen Sie nicht, welche Änderung gewirkt hat.

Spekulatives Laden ist seit WordPress 6.8 aktiv. Im Labor enthielt jede Seite einen Block <script type="speculationrules"> mit prefetch und "eagerness":"conservative": Der Browser lädt eine verlinkte Seite vor, sobald der Besucher zu klicken beginnt. Für angemeldete Benutzer und ohne sprechende Permalinks ist die Funktion laut Entwicklerhinweis abgeschaltet, im Labor lieferte die Konfiguration für den Administrator den Wert NULL. Mit dem Filter wp_speculation_rules_configuration können Sie früher vorladen und die Seite vollständig vorberechnen lassen. Legen Sie dazu eine Datei in wp-content/mu-plugins/ an:

<?php
// wp-content/mu-plugins/speculative-loading.php
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

Im Labor stand danach "prerender" mit "eagerness":"moderate" im Quelltext. Der Trade-off: Vorberechnete Seiten führen JavaScript aus, auch wenn der Besucher die Seite nie öffnet. Zählt Ihr Analysewerkzeug dann Aufrufe, die nie stattfanden, oder startet ein Pop-up vorzeitig, bleiben Sie beim Standard.

Performance ist keine einmalige Aufgabe. Jedes Plugin-Update, jedes neue Tracking-Skript und jede Theme-Änderung kann die Werte wieder verschlechtern. Wer die laufende Pflege nicht selbst übernehmen möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und eine einmalige Homepage-Analyse, bei der solche Schwachstellen auffallen.

Verifizieren: Suchen Sie im Seitenquelltext einer öffentlich aufgerufenen Seite, im privaten Fenster ohne Anmeldung, nach speculationrules. Sie sehen den gewünschten Modus.

Typische Fehler

• Nur auf die Punktzahl geschaut: Eine Laborpunktzahl von 95 bedeutet laut Google-Dokumentation nicht, dass echte Besucher gute Werte haben. Entscheidend sind die Felddaten.
• LCP-Bild lazy geladen: Ein Optimierungs-Plugin setzt loading="lazy" auch am Kopfbild. Schalten Sie im Plugin die pauschale Lazy-Load-Funktion ab oder schließen Sie das Bild aus. WordPress erledigt das selbst korrekt.
• Kein fetchpriority am Kopfbild: Das Bild kommt als CSS-Hintergrund oder von einer fremden Adresse. Im Labor bekam ein solches Bild keine Maße und keine Priorität. Binden Sie es aus der Mediathek als Bild-Block ein.
• Spekulatives Laden nicht sichtbar: Sie sind angemeldet oder die Permalinks stehen auf „Einfach“. Prüfen Sie im privaten Fenster und unter „Einstellungen > Permalinks“.
• Filter ohne Prüfung auf null: Für angemeldete Benutzer übergibt WordPress null statt eines Arrays. Das Beispiel prüft deshalb mit is_array( $config ), damit der Filter diese bewusst abgeschaltete Konfiguration unverändert lässt.

Häufige Fragen

Wie schnell sehe ich Verbesserungen in der Search Console?

Felddaten bilden die vergangenen 28 Tage ab. Verbesserungen werden deshalb erst nach und nach sichtbar. Labordaten ändern sich sofort.

Brauche ich ein Caching-Plugin für gute Core Web Vitals?

Page-Caching senkt vor allem die Server-Antwortzeit und damit den LCP. Viele Hoster bringen eigenes Caching mit. Prüfen Sie zuerst, was Ihr Tarif bereits bietet, bevor Sie ein Plugin ergänzen.

Warum sind die mobilen Werte so viel schlechter?

PageSpeed Insights simuliert mobil ein langsameres Gerät und eine langsamere Verbindung. Echte Smartphones haben weniger Rechenleistung, deshalb fällt zu viel JavaScript dort besonders bei INP ins Gewicht.

Ist Performance Lab für den produktiven Einsatz geeignet?

Das Plugin wird vom WordPress-Performance-Team gepflegt und hat laut wordpress.org mehr als 100.000 aktive Installationen. Einzelne Funktionen sind als experimentell gekennzeichnet, etwa „View Transitions“. Aktivieren Sie solche Funktionen nur nach einem Test auf Staging.

Testumfang

Wir haben das mit WordPress 7.1.2 in einer lokalen Testinstallation ausprobiert. Das erste große Bild erhielt fetchpriority="high", Lazy Loading griff erst ab dem vierten Bild. Auffällig war, dass fremde Bilder ohne Breiten- und Höhenangaben blieben.

Echte LCP-, CLS- und INP-Werte konnten wir nicht messen, weil die Instanz nur lokal lief und keine Felddaten hatte. Prüfen Sie diese Werte deshalb auf Ihrer eigenen Seite, am besten zuerst auf einer Kopie.

Fazit

Gute Core Web Vitals entstehen weniger durch Zusatz-Plugins als durch saubere Grundlagen: Bilder aus der Mediathek, reservierter Platz für alles, was nachlädt, und so wenig JavaScript wie möglich. WordPress nimmt Ihnen bei Bildern und beim Vorladen bereits viel ab, solange Sie seine Mechanismen nicht umgehen. Messen Sie mit Felddaten, ändern Sie eine Sache nach der anderen und prüfen Sie nach jedem größeren Update erneut. Wenn Sie die regelmäßigen Updates und Kontrollen abgeben möchten, finden Sie diese Pflege in der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• PHP-Version für WordPress aktualisieren und Kompatibilität prüfen
• Staging-Umgebung für WordPress einrichten
• Child-Theme anlegen und Anpassungen bei Updates behalten
• web.dev: Web Vitals
• web.dev: Optimize Cumulative Layout Shift
• web.dev: Optimize Interaction to Next Paint
• make.wordpress.org: Image performance enhancements in WordPress 6.3
• make.wordpress.org: Speculative Loading in 6.8
• Google: Über PageSpeed Insights