Wie verbessere ich den LCP in WordPress?

Serverseitiges Caching einrichten, damit die TTFB unter 200 ms fällt, das Hero-Bild mit einem Preload-Link vorladen und auf WebP oder AVIF umstellen. Diese drei Maßnahmen bringen beim LCP erfahrungsgemäß den größten Sprung.

Was ist ein guter Core-Web-Vitals-Wert?

Gut bedeutet: LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1 – jeweils für mindestens 75 % der realen Besucher. Unterhalb dieser Schwellen gilt eine Seite bei Google als bestanden.

Warum besteht meine Seite im Labortest, aber nicht in den Felddaten?

Labortests wie Lighthouse laufen unter idealen Bedingungen mit einem definierten Geräteprofil. Felddaten erfassen echte Besucher – viele davon auf schwachen Smartphones mit mobilem Internet. Ein guter Laborwert bedeutet deshalb nicht automatisch grüne Felddaten.

Wie lange dauert es, bis eine Optimierung in den Felddaten sichtbar ist?

CrUX rollt über ein 28-Tage-Fenster. Eine Verbesserung von heute ist frühestens nach einigen Tagen sichtbar – vollständig erst nach vier Wochen. Deshalb: immer nur eine Änderung auf einmal einbauen und das Fenster abwarten, bevor du die nächste umsetzt.

Core Web Vitals für WordPress: Realistisch unter die Grenzwerte

„WordPress ist langsam” hört man oft – stimmt aber so pauschal nicht. WordPress-Seiten können die Core Web Vitals sauber bestehen, auch mit vielen Funktionen. Es braucht keine Wunderplugins, sondern ein paar disziplinierte Entscheidungen. Dieser Beitrag erklärt die drei Metriken, zeigt anhand echter Felddaten, was möglich ist – und liefert für jede Metrik konkrete Maßnahmen, die wir selbst in der Praxis einsetzen.

Die drei Werte und ihre Grenzen

Core Web Vitals messen die tatsächliche Nutzererfahrung. „Gut” heißt:

Metrik	Was sie misst	Grünbereich
LCP (Largest Contentful Paint)	Wie schnell der größte Inhalt sichtbar ist	≤ 2,5 s
INP (Interaction to Next Paint)	Wie flott die Seite auf Eingaben reagiert	≤ 200 ms
CLS (Cumulative Layout Shift)	Wie ruhig das Layout bleibt	≤ 0,1

INP hat im März 2024 den alten Wert FID abgelöst. Für interaktive WordPress-Seiten – Shops, Suchfilter, Flyout-Menüs – ist er der anspruchsvollste der drei, weil er jeden Interaktionspunkt misst, nicht nur den ersten Klick.

Labordaten ≠ Felddaten

Ein verbreiteter Trugschluss: ein 100/100-Ergebnis in PageSpeed Insights heißt nicht automatisch „bestanden”. Der Labortest (Lighthouse) misst unter idealen, simulierten Bedingungen mit einem definierten Geräteprofil. Was bei Google für das Ranking zählt, sind die Felddaten (CrUX) – echte Messungen echter Besucher über die letzten 28 Tage, auf ihren eigenen Geräten und Verbindungen.

Das erklärt, warum eine Seite im Labor glänzt und im Feld trotzdem scheitert: Viele Besucher kommen mit einem mittelklasse Android-Smartphone und einer 4G-Verbindung – kein Labortest der Welt bildet das exakt nach. Optimiere immer mit Blick auf die Felddaten; der Laborwert ist nur ein Indikator.

LCP verbessern: Der größte Hebel

Der Largest Contentful Paint misst, wann das größte sichtbare Element – meistens das Hero-Bild oder ein großer Textblock – vollständig geladen ist. Über 2,5 Sekunden bedeutet Rot in der Search Console.

Caching zuerst

Caching ist bei WordPress der einfachste und wirkungsvollste LCP-Hebel. Wenn der Server eine fertige HTML-Seite ausliefert, statt sie für jeden Aufruf neu zu bauen, sinkt die Time to First Byte (TTFB) drastisch – und damit der LCP. Serverseitiges Caching (nginx fastcgi_cache, Varnish oder ein Hosting mit eingebautem Full-Page-Cache) schlägt Plugin-Caching allein. Ein gut konfiguriertes Caching-Setup bringt TTFB-Werte unter 200 ms, selbst auf günstigem Managed Hosting. Details dazu findest du im Beitrag → Caching richtig einrichten.

Das Hero-Bild vorladen

Das Bild, das den LCP auslöst, sollte der Browser so früh wie möglich anfordern. Das geht mit einem <link rel="preload" as="image"> im <head>. Noch wichtiger: Das loading-Attribut dieses Elements darf nicht lazy sein – loading="lazy" gehört auf Bilder unterhalb des sichtbaren Bereichs, nicht auf das größte Element im Viewport. Das Attribut fetchpriority="high" signalisiert dem Browser zusätzlich, dass dieses Bild Priorität hat.

Beim Format gilt: WebP oder AVIF statt JPEG oder PNG. Auf einem typischen Artikelbild spart WebP gegenüber JPEG 30–50 % Dateigröße ohne sichtbaren Qualitätsverlust. Die srcset-Attribute sorgen dafür, dass Mobilgeräte nicht ein Desktop-großes Bild herunterladen müssen.

Schriften lokal einbinden

Externe Schriftquellen – darunter Google Fonts – blockieren den Ladevorgang, weil der Browser eine zusätzliche DNS-Abfrage und Verbindung aufbaut. Schriften gehören in den eigenen Server-Ordner, ausgeliefert über die eigene Domain. Dazu font-display: swap in der @font-face-Deklaration: der Browser zeigt zuerst eine Fallback-Schrift und lädt die Webfont nach, statt das Rendering komplett zu blockieren. Ein <link rel="preload" as="font" crossorigin> für die wichtigste Schriftstärke beschleunigt den Ladevorgang weiter.

Render-blocking CSS und JavaScript

Stylesheets im <head> blockieren das Rendering. JavaScript ohne defer oder async macht dasselbe. Im Tab „Performance” der Chrome-Entwicklertools oder in der Diagnose-Sektion von PageSpeed Insights siehst du, welche Ressourcen als render-blocking markiert sind. Ungenutztes CSS eines Page-Builders? Entweder komplett abschalten oder kritisches CSS inline ausliefern. Plugin-JavaScript, das auf jeder Seite lädt, obwohl es nur auf einer Unterseite gebraucht wird? Sichtbarkeit nach Seitentyp einschränken – manuell über wp_dequeue_script oder mit einem Tool wie Asset CleanUp.

INP optimieren: JavaScript im Griff

Interaction to Next Paint misst die Zeit zwischen einer Nutzereingabe – Klick, Tippen, Tastendruck – und dem Moment, in dem der Browser die nächste visuelle Antwort zeigt. Grenzwert: 200 ms. Über 500 ms gilt als schlecht.

Was INP wirklich bremst

Der häufigste Grund für schlechte INP-Werte in WordPress ist zu viel JavaScript auf dem Main-Thread. Jedes Plugin, das beim Laden ein großes JavaScript-Bundle einbettet – Slider, Countdown-Timer, Cookie-Banner, Live-Chat – macht den Main-Thread schwerer. Wenn der Main-Thread beschäftigt ist, verarbeitet der Browser Nutzereingaben erst, wenn er die laufende Aufgabe beendet hat. Das fühlt sich für den Nutzer als Verzögerung an.

WooCommerce ist ein besonderer Fall: Die Warenkorb-Fragmente werden per Ajax bei jedem Seitenaufruf abgefragt, auch bei nicht eingeloggten Besuchern. Das erzeugt Latenz und belastet den Main-Thread unnötig. Wer WooCommerce betreibt, sollte diese Fragmente deaktivieren oder auf statische Warenkorbanzeige umstellen – mehr dazu → WooCommerce schneller machen.

Konkrete Maßnahmen

Jeden Seitentyp im Chrome-DevTools-Tab „Performance” auf Long Tasks prüfen (Aufgaben über 50 ms auf dem Main-Thread).
Plugins nacheinander deaktivieren, um den Verursacher zu isolieren; dann gezielt ersetzen oder konfigurieren.
JavaScript-Dateien, die nicht sofort gebraucht werden, mit defer laden oder in den Footer verschieben.
Prüfen, ob jQuery wirklich nötig ist – viele moderne Themes und Plugins kommen ohne aus, und jQuery gehört zu den häufigsten Main-Thread-Ballast-Quellen.

CLS vermeiden: Stabiles Layout von Anfang an

Cumulative Layout Shift misst, wie stark sich das Layout während des Ladens verschiebt. Ein CLS über 0,1 ist rot – und er nervt echte Nutzer, weil der Klick-Ziel wegläuft oder Text springt.

Bilder ohne Platzhalter

Die häufigste CLS-Ursache in WordPress: Bilder ohne explizite width- und height-Attribute. Wenn diese Attribute fehlen, reserviert der Browser vor dem Laden keinen Platz, und sobald das Bild erscheint, verschiebt sich alles darunter. WordPress setzt seit Version 5.5 diese Attribute automatisch, wenn die Anhangsdaten vollständig sind – ältere Themes oder manuelle <img>-Tags müssen manuell nachgebessert werden. Das Seitenverhältnis lässt sich alternativ per CSS mit aspect-ratio sichern.

Schriften und Layout-Shift

FOUT (Flash of Unstyled Text) erzeugt CLS, wenn die Fallback-Schrift deutlich andere Zeilenhöhen und Abstände hat als die Webfont. font-display: swap ist trotzdem die richtige Wahl – aber die Fallback-Schriften sollten der Webfont metrisch ähnlich sein. Mit der CSS-Eigenschaft size-adjust in der @font-face-Regel lässt sich die Fallback-Schrift so anpassen, dass der Schrift-Umschalter kaum sichtbaren Layout-Shift erzeugt.

Weitere CLS-Fallen in WordPress

Ads und Embeds ohne feste Höhe: Werbebanner oder externe Embeds (YouTube, Karten) brauchen einen Container mit Mindesthöhe oder festem Seitenverhältnis.
Lazy-geladene Bilder im initialen Viewport: Das loading="lazy"-Attribut gehört auf Bilder unterhalb des Falzes, nicht auf das erste sichtbare Bild.
Cookie-Banner: Banner, die als Overlay über dem Inhalt liegen, verschieben nichts. Banner, die in den Dokumentenfluss eingefügt werden und Inhalte nach unten schieben, erzeugen dagegen CLS – oft das einzige Problem, das eine ansonsten saubere Seite über 0,1 bringt.

Was real möglich ist

„WordPress = langsam” stimmt nicht, wenn die Basis stimmt. Wir betreuen funktionsreiche WordPress-Seiten, die die Core Web Vitals sauber im Grünbereich bestehen – mit sauberem Caching, optimierten Bildern und lokal eingebundenen Schriften, nicht mit einem Wunderplugin.

Genauso ehrlich ist der Gegenpunkt aus der Praxis: Oft scheitert eine ansonsten schnelle Seite an einem einzigen Wert – typischerweise am CLS, knapp über der 0,1-Grenze. Nicht die ganze Seite ist dann „langsam”, sondern ein konkretes nachladendes Element ohne reservierten Platz zieht den Wert über die Linie. Genau solche Einzelprobleme lassen sich gezielt lösen, sobald man in den Felddaten sieht, wonach man suchen muss.

Messen, bevor du optimierst

PageSpeed Insights und Lighthouse

PageSpeed Insights zeigt sowohl den Labortest als auch – sofern Felddaten vorhanden sind – die CrUX-Werte für die jeweilige URL. Der Labortest liefert sofortige Diagnosen. Die Felddaten zeigen, wie echte Besucher die Seite erleben. Beide zusammen ergeben ein vollständiges Bild.

Lighthouse direkt im Chrome-Devtool (Tab „Lighthouse”) ist sinnvoll für schnelle Diagnosen während der Entwicklung, weil du ohne Internetverbindung und ohne CrUX-Rauschen testen kannst.

Search Console

Im Bericht „Core Web Vitals” der Google Search Console siehst du, welche URLs als schlecht oder verbesserungswürdig eingestuft sind – gruppiert nach Metrik und Gerätetyp (Mobil / Desktop). Dieser Bericht ist die verlässlichste Quelle für die Priorisierung, weil er auf echten CrUX-Daten basiert und dir sofort zeigt, wo das größte Problem sitzt.

Realistische Erwartungen

CrUX rollt über ein 28-Tage-Fenster. Eine Optimierung von heute ist frühestens nach einigen Tagen in den Felddaten sichtbar – vollständig erst nach vier Wochen. Das bedeutet: Nicht fünf Maßnahmen gleichzeitig einbauen. Wer zu viel auf einmal ändert, weiß danach nicht, was geholfen hat und was nicht.

So gehst du vor

Felddaten in der Search Console (Bericht „Core Web Vitals”) oder in PageSpeed Insights prüfen – nicht nur den Laborwert.
Den schlechtesten der drei Werte zuerst angehen; meistens ist es LCP oder CLS.
Eine Änderung einbauen, dann messen – nicht fünf Plugins gleichzeitig installieren.
Nach 28 Tagen die Felddaten erneut kontrollieren und ggf. den nächsten Wert in Angriff nehmen.