Largest Contentful Paint verbessern: Die wirksamen Hebel

Von Manuel Hack, ihp media · Aktualisiert am 21. Juni 2026

Ein Besucher öffnet Ihre Website. Was er zuerst sieht, entscheidet, ob er bleibt. Genau das misst der Largest Contentful Paint: den Moment, in dem das größte sichtbare Element vollständig im Viewport gerendert ist. Google zählt diesen Wert seit 2021 zu den drei Core Web Vitals und bezieht ihn direkt in die Seitenbewertung ein. Welche Hebel wirklich etwas bringen, in welcher Reihenfolge Sie sie angehen und warum der erste Schritt immer die Diagnose ist, nicht die Maßnahme.

Was LCP ist und wie er gemessen wird

Die Schwellenwerte definiert Google auf web.dev verbindlich: unter 2,5 Sekunden gilt als „gut“, ab 4,0 Sekunden als „schlecht“. Für die Bewertung im Page Experience Signal zählen die Felddaten aus dem Chrome User Experience Report (CrUX), nicht die Laborwerte von Lighthouse. Felddaten bilden echte Nutzererfahrungen ab, also auch ältere Mobilgeräte im Mobilfunknetz. Ein Lighthouse-Score von 90 kann durchaus mit einem schlechten CrUX-Feldwert zusammenfallen, wenn reale Nutzer auf schwächeren Geräten deutlich länger warten.

Als LCP-Element kommen laut der offiziellen LCP-Spezifikation auf web.dev in Frage: <img>-Elemente (inkl. <picture>), Bilder in CSS als background-image: url(), Elemente mit Video-Thumbnail, Block-Textelemente wie <p> oder <h1> und <image>-Elemente im SVG-Namespace (also <image> innerhalb von <svg>; das <svg>-Element selbst zählt laut web.dev nicht). Textknoten allein gelten nicht als LCP-Kandidaten.

Das LCP-Element identifizieren

Dieser Schritt ist nicht optional. Wer das Hero-Bild als AVIF ausliefert, aber der Browser das LCP tatsächlich an einem großen Textblock misst, hat an der falschen Stelle optimiert. In der Praxis ist das LCP-Element in den meisten Fällen ein Bild, bei reinen Textseiten auch ein großer Absatz oder eine Überschrift. Erst nach der Identifikation ist klar, welche Hebel greifen.

TTFB und Serverantwort optimieren

Google definiert auf web.dev/articles/ttfb eine gute TTFB als unter 0,8 Sekunden. Wer dort schon 1,2 Sekunden verliert, hat für alles, was danach kommt, nur noch 1,3 Sekunden übrig. Die drei häufigsten Ursachen für eine schlechte TTFB bei WordPress-Seiten:

Fehlendes serverseitiges Caching

Ohne Full-Page-Cache baut WordPress bei jeder Anfrage die Seite frisch auf: PHP lädt, die Datenbank wird abgefragt, Plugins initialisieren sich. Ein Full-Page-Cache liefert das fertige HTML aus dem Speicher und senkt die TTFB oft von mehreren hundert Millisekunden auf unter 100 ms. WP Rocket, LiteSpeed Cache oder W3 Total Cache mit Opcode-Caching sind etablierte Optionen. Wie Caching im Detail funktioniert, erklärt der Caching-Ratgeber.

Geografische Distanz zum Server

Licht legt in einer Millisekunde rund 200 km zurück. Ein Server in Frankfurt liefert einem Besucher in München schnell, für einen Besucher in New York addieren sich schon durch die physikalische Signallaufzeit über 40 ms. Ein Content Delivery Network wie Cloudflare oder BunnyCDN stellt Kopien statischer Ressourcen an verteilten Standorten bereit und verkürzt den Weg für internationale Besucher.

Unterdimensioniertes Hosting

Günstiges Shared Hosting teilt Rechenkapazität unter vielen Websites. Unter Last steigt die Antwortzeit dann sprunghaft. Ein Virtual Private Server mit reservierten PHP-Prozessen oder gemanagtes WordPress-Hosting (z. B. Kinsta, Raidboxes) sind dann die wirkungsvollere Alternative. Das ist keine Werbung, sondern Erfahrungswert aus Projekten, bei denen ein Hosting-Wechsel die TTFB um den Faktor 5 verbessert hat.

Bild-Priorität: fetchpriority und preload

Standardmäßig entdeckt der Browser das LCP-Bild erst, nachdem er das HTML geparst und zumindest den oberen Teil des CSS verarbeitet hat. Je später er es entdeckt, desto später startet der Download, desto später landet der LCP-Zeitstempel. Zwei Maßnahmen korrigieren das.

fetchpriority=“high“

Dieses Attribut ist laut MDN Web Docs in allen modernen Browsern verfügbar (Chrome ab 101, Firefox ab 132, Safari ab 17.2). Die Wirkung beschreibt web.dev/articles/fetch-priority: In Tests von Google-Ingenieur Patrick Meenan reduzierte fetchpriority="high" den LCP in Fallstudien um 20 bis 30 Prozent. Der Aufwand ist minimal: ein einziges Attribut.

rel=“preload“ im Head

Noch früher als fetchpriority wirkt ein <link rel="preload"> im <head>. Damit teilen Sie dem Browser bereits beim ersten HTML-Scan mit, dass dieses Bild dringend gebraucht wird, bevor er auch nur das erste CSS-File verarbeitet hat. Laut web.dev/articles/preload-critical-assets ist das besonders wirkungsvoll für Bilder, die in CSS-Hintergründen oder per JavaScript geladen werden, weil der HTML-Parser diese sonst erst sehr spät entdecken würde.

Für ein responsives Bild mit srcset nutzen Sie imagesrcset und imagesizes im Preload-Tag, damit der Browser die richtige Variante vorab lädt. Details dazu zeigt das Code-Beispiel weiter unten.

Wichtiger Hinweis: Setzen Sie preload nur auf das tatsächliche LCP-Element. Jedes unnötige Preload konkurriert mit anderen Ressourcen und kann den Download des eigentlichen LCP-Bildes verlangsamen. Mehr als ein bis zwei Preloads im Head sind in der Regel kontraproduktiv.

Kein Lazy Loading auf das LCP-Bild

Das klingt offensichtlich, ist aber ein verbreiteter Fehler. Viele WordPress-Themes und Page-Builder setzen loading="lazy" auf alle Bilder pauschal, einschließlich des Hero-Bildes. Wie web.dev zu Browser-Level Lazy Loading erklärt, ist Lazy Loading für alles unterhalb des sichtbaren Bereichs sinnvoll und spart Bandbreite. Aber für Bilder, die beim ersten Laden sichtbar sind, gilt das Gegenteil.

Konkret: Das Hero-Bild und alles, was beim ersten Seitenaufruf im Viewport liegt, braucht entweder loading="eager" oder gar kein Loading-Attribut (Eager ist der Standardwert). Prüfen Sie Ihr Theme oder Page-Builder-Plugin auf pauschal gesetztes loading="lazy" und überschreiben Sie es gezielt für das LCP-Element.

Den gleichen Fehler macht decoding="async", wenn es auf das LCP-Bild gesetzt wird. Dieses Attribut verschiebt die Dekodierung in einen Hintergrundthread, was für nachgeladene Bilder gut ist, für das LCP-Bild aber Verzögerung bedeutet.

Render-Blocking-Ressourcen reduzieren

CSS- und JavaScript-Dateien im <head> ohne spezielle Attribute blockieren die Darstellung. Der Browser kann nichts rendern, solange er diese Dateien nicht vollständig geladen und verarbeitet hat. Für den LCP bedeutet das: das größte sichtbare Element bleibt unsichtbar, bis alle blockierenden Ressourcen abgearbeitet sind. Der Ratgeber zu Render-Blocking-Ressourcen erklärt das im Detail. Hier die wichtigsten Punkte für den LCP:

Kritisches CSS inline

Das kritische CSS umfasst nur die Stilregeln, die für den sichtbaren Bereich beim ersten Laden nötig sind. Diese Regeln direkt im <head> als <style>-Block zu platzieren, entfernt einen Netzwerkabruf aus dem kritischen Rendering-Pfad. Das restliche CSS lädt nachrangig über media="print" und wird per JavaScript auf media="all" umgeschaltet, sobald es verfügbar ist. Werkzeuge wie Critical oder Penthouse helfen, das kritische CSS automatisch zu extrahieren.

JavaScript mit defer

Ein <script src="..."> ohne Attribut im <head> hält den HTML-Parser vollständig an. defer lädt das Skript parallel, führt es aber erst nach dem vollständigen Parsen aus. Das ist für die meisten Skripte die richtige Wahl. async läuft ebenfalls parallel, führt aber sofort nach dem Download aus, was bei abhängigen Skripten Fehler erzeugen kann. Analyse-Werkzeuge, Chat-Widgets und ähnliche Nebenfunktionen gehören immer auf defer.

Drittanbieter-Skripte ausmisten

Google Tag Manager, Tracking-Pixel, Einwilligungs-Banner und ähnliche Dienste summieren sich schnell auf 300 bis 500 Kilobyte und zehn oder mehr zusätzliche Netzwerkabrufe. Ein Blick in die Network-Ansicht der Chrome DevTools zeigt, was wirklich geladen wird. Jedes Tag, das nicht mehr aktiv genutzt wird, ist ein direkter LCP-Gewinn.

Übersicht: Hebel, Wirkung, Aufwand

Code-Beispiel: preload und fetchpriority korrekt setzen

Das folgende Beispiel zeigt, wie preload und fetchpriority für ein responsives LCP-Bild zusammenspielen. Beide Attribute kumulieren sich: preload startet den Download früh, fetchpriority="high" hebt die Priorität zusätzlich an.

<!-- Im <head>: preload für das LCP-Bild mit srcset-Unterstützung -->
<link rel="preload"
      as="image"
      href="/bilder/hero-800.webp"
      imagesrcset="/bilder/hero-400.webp 400w,
                   /bilder/hero-800.webp 800w,
                   /bilder/hero-1200.webp 1200w"
      imagesizes="(max-width: 600px) 100vw, 50vw">

<!-- Im <body>: das Bild selbst -->
<img src="/bilder/hero-800.webp"
     srcset="/bilder/hero-400.webp 400w,
             /bilder/hero-800.webp 800w,
             /bilder/hero-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 50vw"
     alt="Beschreibender Alt-Text"
     width="800"
     height="533"
     fetchpriority="high">
     <!-- Kein loading="lazy" hier! -->

Auf die width– und height-Attribute sollten Sie nicht verzichten: Der Browser reserviert damit bereits vor dem Download den richtigen Platz im Layout und vermeidet Layoutverschiebungen, die den Cumulative Layout Shift (CLS) verschlechtern würden.

<?php
// fetchpriority="high" am Post-Thumbnail auf Einzelseiten setzen
// Datei: mu-plugins/ihp-lcp-priority.php  (oder functions.php im Child-Theme)
add_filter( 'wp_get_attachment_image_attributes', 'ihp_lcp_fetchpriority', 10, 3 );

function ihp_lcp_fetchpriority( $attr, $attachment, $size ) {
    // Nur auf Einzelseiten (post, page) und nur am Post-Thumbnail
    if ( ! is_singular() ) {
        return $attr;
    }
    if ( (int) $attachment->ID !== (int) get_post_thumbnail_id() ) {
        return $attr;
    }
    // loading="lazy" entfernen, falls Theme es pauschal setzt
    unset( $attr['loading'] );
    // fetchpriority setzen
    $attr['fetchpriority'] = 'high';
    return $attr;
}

Praxisbeispiel

In einem Projekt mit einem regionalen Handwerksbetrieb lag der LCP-Feldwert laut CrUX bei 3,8 Sekunden, also knapp im roten Bereich. PageSpeed Insights identifizierte das Hero-Foto als LCP-Element, ein 1,4 MB großes JPEG, das obendrein mit loading="lazy" verzögert wurde. Gleichzeitig blockte das Theme zwei CSS-Dateien und drei JavaScript-Dateien im Head.

In drei Schritten kam der Wert auf 1,9 Sekunden: Das Bild wurde als WebP in drei Breiten neu exportiert (zusammen 180 KB), loading="lazy" entfernt, fetchpriority="high" gesetzt und ein Preload-Tag in den Head geschrieben. Dann wurden die JavaScript-Dateien auf defer umgestellt. Der Full-Page-Cache lief bereits, die TTFB war also kein Problem. Das Ergebnis nach zwei Wochen CrUX-Sammlung: 78 Prozent der Sitzungen im grünen Bereich, vorher waren es 31 Prozent. Das ist kein Ausreißer, sondern ein Muster, das sich in mehreren Projekten so gezeigt hat.

Schritt für Schritt zum besseren LCP

1. LCP-Element identifizieren. PageSpeed Insights aufrufen, URL eingeben, unter „Diagnose“ das LCP-Element notieren. Typ und URL festhalten.
2. TTFB prüfen. In derselben Ansicht die Time to First Byte ablesen. Liegt sie über 0,8 s: Full-Page-Cache prüfen oder aktivieren, dann Hosting-Leistung bewerten.
3. Lazy Loading prüfen. Im HTML des LCP-Elements nach loading="lazy" suchen. Falls vorhanden: entfernen oder auf loading="eager" setzen.
4. fetchpriority=“high“ setzen. Direkt am <img>-Tag des LCP-Elements hinzufügen.
5. Preload-Tag einfügen. Einen <link rel="preload" as="image"> als erstes Element im <head> platzieren, mit passendem href und, bei responsiven Bildern, imagesrcset und imagesizes.
6. Bild-Format prüfen. Ist das LCP-Element ein Bild in JPEG oder PNG? Dann als WebP oder AVIF neu exportieren und per <picture> einbinden. Mehr dazu im Ratgeber Bilder optimieren.
7. Render-Blocking-Ressourcen prüfen. Chrome DevTools, Tab Network, Filter „Render blocking“ oder Coverage-Tab. JavaScript im Head auf defer umstellen, kritisches CSS inline setzen.
8. Messen und warten. PageSpeed Insights zeigt Labordaten sofort. CrUX-Felddaten aktualisieren sich über 28 Tage rollierend. Erst nach zwei bis vier Wochen ist der Feldwert belastbar.

Sofort-Checkliste

• LCP-Element in PageSpeed Insights oder Chrome DevTools identifiziert und notiert?
• TTFB unter 0,8 Sekunden? Full-Page-Cache aktiv?
• LCP-Element ist ein Bild: kein loading="lazy" gesetzt?
• LCP-Element ist ein Bild: kein decoding="async" gesetzt?
• fetchpriority="high" am LCP-Bild-Tag?
• <link rel="preload" as="image"> im <head> für das LCP-Bild?
• LCP-Bild in WebP oder AVIF konvertiert und mit <picture> eingebunden?
• width und height am LCP-Bild gesetzt (kein Layout Shift)?
• Render-Blocking-Skripte im Head auf defer umgestellt?
• Felddaten in PageSpeed Insights nach 2-4 Wochen erneut geprüft?

Häufige Fragen

Was ist der Unterschied zwischen LCP und FCP?

Der First Contentful Paint (FCP) misst, wann irgendetwas, also der erste Text, das erste Bild oder ein SVG, im Viewport erscheint. Der LCP misst das größte Element. FCP kann bei 0,8 Sekunden liegen, während der LCP wegen eines großen Bildes erst bei 3,5 Sekunden erreicht wird. Für das Google-Ranking zählt der LCP als Core Web Vital, nicht der FCP.

Kann ich preload und fetchpriority gleichzeitig nutzen?

Ja, und das ist sogar empfehlenswert. Die Attribute ergänzen sich: preload startet den Download so früh wie möglich, fetchpriority="high" hebt die Priorität innerhalb der Lade-Warteschlange an. web.dev/articles/fetch-priority erklärt, dass beide Mechanismen unterschiedliche Punkte im Lade-Ablauf beeinflussen und sich nicht gegenseitig ersetzen.

Mein LCP-Element ist kein Bild, sondern ein Textblock. Was dann?

Dann greift die Bild-Optimierung nicht. Stattdessen prüfen Sie: Blockiert eine Webschrift die Darstellung? Setzen Sie font-display: swap oder font-display: optional und hosten Sie Schriften lokal. Liegt die TTFB hoch? Dann ist serverseitiges Caching der wichtigste Hebel. Blockierendes CSS oder JavaScript, das den Textblock erst nach dem Laden rendert, sollte mit defer oder Critical-CSS-Extraktion behoben werden.

Wie lange, bis sich LCP-Verbesserungen in der Google Search Console zeigen?

Die CrUX-Felddaten werden über die jeweils letzten 28 Tage zusammengefasst. Eine Verbesserung schlägt sich deshalb nicht sofort nieder, sondern wird meist nach zwei bis vier Wochen deutlich. Der Laborwert in PageSpeed Insights ändert sich sofort nach der Maßnahme.

Kann ein hoher LCP-Wert das Ranking direkt verschlechtern?

Ja, aber mit Einschränkung. Die Core Web Vitals sind ein Signal unter vielen. Sehr relevante Inhalte ranken trotz schwachem LCP-Wert oft besser als relevanzarme Seiten mit perfekten Werten. Sind zwei Seiten inhaltlich gleichwertig, kann der bessere LCP den Ausschlag geben. Die Core Web Vitals Grundlagen erklären das Zusammenspiel der Signale genauer.

Wie finde ich heraus, ob mein Theme lazy loading pauschal setzt?

Öffnen Sie die Chrome DevTools, Tab Elements, und suchen Sie im HTML nach loading="lazy". Alternativ: Quelltext der Seite mit Strg+U öffnen und nach loading= suchen. Wenn das Attribut am LCP-Bild steht, entfernen Sie es entweder direkt im Theme-Code oder über einen wp_get_attachment_image_attributes-Filter in der functions.php Ihres Child-Themes.