LCP verbessern WordPress: Schritt für Schritt zum guten Wert

Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte sichtbare Element im Viewport vollständig gerendert ist. Google stuft einen Wert bis 2,5 Sekunden als „gut" ein, bis 4,0 Sekunden als „verbesserungswürdig", darüber als „schlecht" (offizielle Schwellenwerte). Was LCP ist und wie es mit INP und CLS zusammenhängt, erklärt der Core-Web-Vitals-Grundlagenartikel — hier geht es direkt in die Praxis: Element finden, Ursache zuordnen, gezielt beheben.

Schritt 1: Das LCP-Element identifizieren

Bevor du irgendetwas optimierst, musst du wissen, welches Element als LCP zählt. Das ist nicht immer das Hero-Bild — es kann auch eine große Überschrift, ein Video-Poster-Frame oder ein Hintergrundbild per CSS sein.

So findest du es:

Unser Speed-Test: Der Lighthouse-Report weist das LCP-Element explizit aus, inklusive Zeitanteilen (TTFB, Ladeverzögerung, Ladedauer, Renderverzögerung).
Chrome DevTools: Performance-Panel aufzeichnen, im Bereich „Timings" erscheint ein LCP-Marker mit Verweis auf das Element.
PageSpeed Insights direkt: Im Diagnose-Abschnitt „Largest Contentful Paint element" aufklappen.

Die Zeitanteile sind der Schlüssel zur richtigen Maßnahme: Dominiert die TTFB-Phase, ist Bildoptimierung zweitrangig — dein Problem sitzt auf dem Server. Dominiert die Ladedauer des Bildes, ist genau das dein Hebel.

Die vier Phasen im Detail

Lighthouse zerlegt die LCP-Zeit in vier Abschnitte (WP-Rocket-Dokumentation zur LCP-Aufschlüsselung, Konzept identisch bei jedem Lighthouse-basierten Tool):

TTFB (Time to First Byte): Zeit bis die erste Antwort vom Server eintrifft. Hosting- und Server-Cache-Thema, siehe Schritt 3.
Ladeverzögerung (Load Delay): Zeit zwischen TTFB und dem Start des Downloads des LCP-Elements. Wird lang, wenn das Element erst spät im HTML entdeckt wird — etwa weil es per JavaScript nachgeladen oder als CSS-Hintergrundbild versteckt ist.
Ladedauer (Load Time): Reine Downloadzeit des Elements. Hier wirken Dateigröße, Format und Kompression.
Renderverzögerung (Render Delay): Zeit zwischen fertigem Download und tatsächlichem Rendern. Wird lang, wenn render-blockendes CSS/JS noch verarbeitet werden muss, bevor der Browser malen darf.

Eine hohe Ladeverzögerung ist der am häufigsten übersehene Fall: Das Bild selbst ist längst optimiert, wird aber erst spät entdeckt, weil es tief im DOM liegt, per Lazy-Loading-Bibliothek eines Page Builders nachgeladen wird oder als background-image in einer CSS-Datei steckt, die der Browser erst parsen muss. Steht dein LCP-Element als CSS-Hintergrundbild fest, prüfe zuerst, ob ein echtes <img>-Tag mit fetchpriority="high" technisch möglich ist — Hintergrundbilder kann der Browser nicht vorab entdecken und priorisieren.

Schritt 2: Hero-Bild-Optimierung

Wenn das LCP-Element ein Bild ist, greifen vier Stellschrauben, in absteigender Wirkung:

Format. AVIF komprimiert im Schnitt 20–30 % kleiner als WebP bei vergleichbarer wahrgenommener Qualität, WebP wiederum 25–35 % kleiner als JPEG (ShortPixel-Formatvergleich). Die Browser-Unterstützung ist 2026 bei beiden Formaten breit genug, dass ein <picture>-Element mit AVIF-Quelle und JPEG-Fallback die richtige Wahl ist. Ausführlich dazu: WordPress Bilder optimieren.

fetchpriority="high" statt Lazy-Loading. Das ist der Punkt, an dem die meisten WordPress-Setups Punkte verschenken: Themes und Page Builder setzen loading="lazy" inzwischen oft pauschal auf alle Bilder — inklusive des Hero-Bildes. Das ist falsch herum. Lazy-Loading verzögert den Ladebeginn bewusst, bis das Bild in den Viewport scrollt; beim LCP-Element ist es aber von Anfang an sichtbar, wird also unnötig ausgebremst (web.dev zu Lazy-Loading). Richtig ist das Gegenteil: dem Bild explizit fetchpriority="high" mitgeben, damit der Browser es bevorzugt lädt. In einem dokumentierten Test von Google Flights verbesserte sich der LCP dadurch von 2,6 s auf 1,9 s (Fetch-Priority-API, web.dev). Die Kombination loading="lazy" und fetchpriority="high" auf demselben Bild ergibt keinen Sinn und wird von manchen Plugins trotzdem erzeugt — prüfe das im Quellcode.

Explizite Bildgröße. width- und height-Attribute (oder aspect-ratio in CSS) verhindern, dass der Browser Platz reservieren muss, sobald das Bild eintrifft — das wirkt zusätzlich auf CLS, nicht nur auf LCP.

Auslieferung. Ob ein Bild-CDN sinnvoll ist oder ob lokale Komprimierung reicht, hängt von Serverstandort und Traffic ab — dazu ausführlich im Bilder-Artikel und im DSGVO-CDN-Artikel.

Für die Komprimierung selbst reicht bei den meisten Seiten ein Plugin, das beim Upload automatisch AVIF/WebP erzeugt — ShortPixel* macht das im Hintergrund inklusive Alt-Format-Fallback. Nötig ist das nicht immer: Wer nur gelegentlich Bilder hochlädt, kann sie auch manuell vorkomprimieren, bevor sie in die Mediathek wandern, und spart sich das Abo.

Preconnect, wenn das Hero-Bild von extern kommt. Lieferst du das Hero-Bild über ein Bild-CDN oder einen externen Hostnamen aus, kostet der zusätzliche DNS-Lookup plus TLS-Handshake wertvolle Millisekunden, bevor der Download überhaupt beginnen kann. Ein <link rel="preconnect" href="https://dein-cdn-host.de"> im <head> baut die Verbindung parallel zum restlichen Seitenaufbau auf. Bei Bildern vom eigenen Server ist das nicht nötig — die Verbindung zum eigenen Host besteht ohnehin bereits.

Sonderfall: Text als LCP-Element. Nicht jede Seite hat ein Bild als größtes Element — bei textlastigen Landingpages ist es oft eine große Überschrift. Dann verschiebt sich der Hebel komplett zu Schritt 4 (Render-Blocking) und zur Web-Font-Ladezeit: Ein extern nachgeladener Font, der den Text erst verzögert rendert (statt mit font-display: swap sofort in einer Systemschrift anzuzeigen), kann in diesem Fall der größte einzelne LCP-Faktor sein.

Schritt 3: Server-Antwortzeit als Unterbau

Kein Bild kann schneller laden als der Server antwortet. Wenn deine TTFB-Phase (siehe LCP-Aufschlüsselung oben) bereits 800 ms oder mehr verschlingt, ist jede Bildoptimierung ein Tropfen auf den heißen Stein — die Decke ist durch den Server vorgegeben. Miss das getrennt und lies bei Bedarf TTFB verbessern WordPress: Dort geht es um Hosting, Server-Cache und die vier echten Ursachen für eine langsame erste Antwort.

Schritt 4: Render-Blocking beseitigen

CSS und JavaScript, die vor dem LCP-Element geladen werden müssen, verzögern dessen Rendering unabhängig vom Bild selbst. Praktisch heißt das:

Kritisches CSS inline, den Rest asynchron nachladen.
JavaScript ohne unmittelbaren Nutzen (Tracking, Chat-Widgets, Slider-Bibliotheken) mit defer laden oder erst nach der ersten Interaktion.
Web-Fonts möglichst lokal einbinden und mit font-display: swap versehen, damit Text nicht auf den Font wartet.

Ein seitenweites Caching-Plugin übernimmt einen Großteil davon automatisch (Minifizierung, CSS-Optimierung, JS-Verzögerung) — welches für deine Serverumgebung passt, steht im Cache-Plugin-Vergleich.

Die Page-Builder-Falle: Elementor und Divi ehrlich benannt

Page Builder sind die häufigste versteckte LCP-Bremse in WordPress, weil sie zusätzliches CSS und JavaScript erzeugen, das mit reiner Handarbeit im Theme nicht anfallen würde. Das ist kein Vorwurf gegen die Tools als solche — beide haben in den letzten Jahren spürbar nachgebessert. Divi wurde in Version 5 laut Hersteller-Angabe grundlegend neu gebaut und reduziert JavaScript um rund 84 % und CSS um rund 94 % gegenüber Divi 4 (SuperbThemes-Vergleich) — eine Herstellerangabe, die du an deiner eigenen Installation per Speed-Test nachprüfen solltest, statt sie blind zu übernehmen. Elementor bietet inzwischen eingebautes Lazy-Loading und Optimierungsoptionen, die aktiviert werden müssen — sie sind nicht immer Standard.

Die ehrliche Aussage: Wenn du mit einem Page Builder arbeitest, wirst du nie den LCP-Wert einer handgeschriebenen, schlanken HTML-Seite erreichen. Das ist der Preis für visuelles Bearbeiten ohne Code. Für die meisten Business-Seiten ist das ein akzeptabler Kompromiss — für eine Landingpage, bei der jede Zehntelsekunde Conversion kostet, lohnt sich eher ein schlankes Block-Theme ohne Page-Builder-Overhead.

Praktisch heißt das bei Elementor: Prüfe unter Einstellungen → Erweitert → Performance, ob „CSS-Print-Methode: Extern" und Lazy-Loading für Hintergrundbilder aktiv sind, und kontrolliere anschließend im Quellcode, ob das Hero-Bild versehentlich mit erfasst wurde. Bei Divi lohnt sich nach einem Update auf Version 5 ein erneuter Speed-Test, weil sich durch die überarbeitete Architektur die LCP-Ausgangslage gegenüber älteren Divi-4-Installationen spürbar verschieben kann — in welche Richtung, hängt vom bisherigen Anpassungsgrad deiner Seite ab und lässt sich nur durch eigene Messung beantworten, nicht durch Herstellerangaben allein.

Häufige Fehler in der Praxis

Hero-Bild wird per Slider-Plugin geladen. Slider-Bibliotheken laden Bilder oft per JavaScript nach dem initialen Rendering — das verlängert die Ladeverzögerung erheblich. Ein statisches Hero-Bild ohne Slider ist für LCP fast immer die bessere Wahl.
fetchpriority="high" auf mehreren Bildern gleichzeitig. Der Browser kann nur ein Element wirklich bevorzugen — wird das Attribut inflationär gesetzt, verpufft der Effekt für das tatsächliche LCP-Element.
CDN-Preconnect für einen Host, der gar nicht mehr genutzt wird. Nach einem Anbieterwechsel bleiben alte preconnect-Hinweise oft im Theme-Code stehen und bauen unnötige Verbindungen zu Diensten auf, die längst nicht mehr eingebunden sind.

Was du nicht brauchst

Du brauchst kein KI-gestütztes „Auto-Optimierungs"-Plugin, das verspricht, alle vier Phasen automatisch zu lösen. Diese Tools greifen meist nur die Ladedauer-Phase an (Kompression, Format), rühren TTFB und Renderverzögerung kaum an — und erzeugen dabei mitunter eigene Render-Blockaden durch zusätzliches JavaScript zur Laufzeit-Optimierung. Die vier Phasen oben sind kein Geheimnis, das ein einzelnes Plugin lösen kann; sie liegen auf vier unterschiedlichen Baustellen (Server, HTML-Struktur, Bildgröße, CSS/JS), und mindestens eine davon — Hosting — kann kein Plugin der Welt beheben.

Kurz-Checkliste

LCP-Element per Speed-Test oder DevTools identifizieren.
Zeitanteile prüfen: TTFB-lastig → Hosting-Thema. Ladedauer-lastig → Bildthema.
Bild in AVIF/WebP, mit fetchpriority="high", ohne loading="lazy", mit width/height.
Render-blockendes CSS/JS über ein Cache-Plugin entschärfen.
Bei Page-Builder-Sites: Erwartungen an den erreichbaren Bestwert anpassen.

Weiterführend: WordPress schneller machen für die komplette Reihenfolge aller Maßnahmen, oder direkt Speed-Test starten, um dein eigenes LCP-Element zu sehen.