Ihr Ziel ist ein LCP von höchstens 2,5 Sekunden, wie Google es als „gut“ einstuft. Wer bei Conversion und SEO wirklich vorne mitspielen will, zielt auf unter 2,0 Sekunden. Die drei wichtigsten Hebel sind unter anderem, die Serverantwortzeit durch Caching und besseres Hosting zu senken, das LCP-Element zu identifizieren und mit fetchpriority oder Preload zu priorisieren, sowie Above-the-fold-Inhalte nicht lazyloaden. Öffnen Sie jetzt DevTools oder PageSpeed Insights und schauen Sie nach, welches Element bei Ihnen aktuell den LCP auslöst.

Kurz gesagt:

  • Ein TTFB von über 800 Millisekunden verhindert oft eine Untergrenze beim LCP von 2,5 Sekunden, daher ist schnelles Server-Hosting essenziell.
  • Lazyload für Above-the-fold-Bilder verzögert das Laden und verschlechtert den LCP, während fetchpriority=“high” und Preload-Tags die Ladezeit deutlich verbessern.
  • Große unkomprimierte Bilder, fehlende moderne Formate und fehlendes CDN treiben die Ladezeiten erheblich in die Höhe, was die Bildoptimierung priorisieren lässt.
  • Render-blockierende CSS- und JavaScript-Dateien sowie Web Fonts mit font-display: swap verzögern das erste sichtbare Rendering deutlich.
  • Felddaten des Chrome User Experience Reports zeigen realistische LCP-Werte erst nach mehreren Wochen, Labordaten liefern sofort Ergebnisse.
Neomarketing
Mehr aus Ihren Marketingdaten machen
Neomarketing verbindet Google Ads, GA4, Merchant Center und Data Layer für datenbasierte Entscheidungen im E-Commerce.

Neomarketing kennenlernen

Inhaltsverzeichnis

Was ist LCP und wie finden Sie das entscheidende Element?

Der Largest Contentful Paint misst, wie lange es dauert, bis das größte sichtbare Element im Sichtbereich fertig gerendert ist. Laut Web gilt ein Wert bis 2,5 Sekunden als gut, ab 4,0 Sekunden als schlecht. Der Bereich dazwischen heißt „verbesserungswürdig“. In der Praxis reicht „gut“ oft nicht: Wer bei Google Shopping-Kampagnen oder organischen Rankings vorne mitspielen will, plant mit einem Puffer und zielt auf unter 2 Sekunden.

Das LCP-Element herauszufinden, ist keine Raterei. Drei Wege führen zum Ziel:

  • Chrome DevTools: Reiter „Performance“ öffnen, Seite neu laden, im Bereich „Timings“ erscheint ein LCP-Marker mit direktem Link zum Element.
  • PageSpeed Insights: Der Abschnitt „Diagnose“ nennt das LCP-Element explizit und zeigt ein Vorschaubild.
  • Lighthouse in DevTools: Der Audit „Largest Contentful Paint element“ listet den genauen Selektor.

Wichtig ist die Unterscheidung: Handelt es sich um ein Hero-Bild, einen Textblock in großer Schrift oder das Poster-Bild eines Videos? Jede Variante braucht eine andere Fix-Strategie, die Sie in den folgenden Abschnitten finden.

Die vier Phasen des LCP verstehen und gezielt beheben

Wer LCP verbessern will, ohne den Timer in seine Bestandteile zu zerlegen, optimiert oft am falschen Ende. Google unterteilt die Zeit bis zum größten sichtbaren Element in vier Phasen, und jede davon hat eigene Ursachen und eigene Werkzeuge zur Diagnose.

1. TTFB (Time to First Byte)

Die Zeit vom Klick bis zur ersten Antwort des Servers. Ein Ziel von 200 bis 800 Millisekunden gilt als realistisch. Alles darüber ist ein klares Signal, dass Server-Maßnahmen Vorrang haben. Sichtbar wird diese Phase im Network-Tab der DevTools oder im Waterfall-Diagramm von WebPageTest.

2. Resource Load Delay

Die Verzögerung zwischen dem ersten Byte und dem Start des Downloads der LCP-Ressource, meist ein Bild. Diese Phase entsteht häufig, weil das Bild erst nach dem Parsen von CSS oder JavaScript entdeckt wird. Ein fehlendes Preload-Tag ist die häufigste Ursache. WebPageTest zeigt diese Lücke im Request-Waterfall besonders deutlich, weil sie als weißer Balken zwischen HTML-Antwort und Bild-Request erscheint.

3. Resource Load Duration

Die tatsächliche Downloadzeit der Ressource selbst. Große, unkomprimierte Bilder, fehlende moderne Formate wie AVIF oder WebP und ein Server ohne Content Delivery Network treiben diese Phase in die Höhe. Wer hier Zeit verliert, sieht es direkt an der Dateigröße im Network-Tab.

4. Element Render Delay

Die Zeit zwischen fertigem Download und dem tatsächlichen Rendern auf dem Bildschirm. Render-blockierendes CSS oder JavaScript, das den Hauptthread blockiert, ist der Hauptverursacher. Auch aufwendige Web Fonts ohne font-display: swap gehören hierher.

Die Reihenfolge der Fehlerbehebung sollte sich an der Größe des Hebels orientieren, nicht an der Reihenfolge im Code. TTFB zuerst, weil ein langsamer Server jede Frontend-Optimierung im wahrsten Sinne ausbremst. web.dev weist ausdrücklich darauf hin, dass viele Frontend-Maßnahmen wenig bringen, wenn das Backend selbst zu langsam antwortet. Erst danach folgen Resource Load Delay durch Preload-Strategien, dann Resource Load Duration durch Bildoptimierung, und zum Schluss Element Render Delay durch Critical CSS und JS-Optimierung.

Die vier LCP-Phasen im zeitlichen Ladeprozess

Ein Praxisbeispiel: Ein Onlineshop mit TTFB von 1,2 Sekunden wird kaum unter 2,5 Sekunden LCP kommen, egal wie gut das Hero-Bild komprimiert ist. Die Mathematik ist unbestechlich. Erst wenn TTFB unter 500 Millisekunden liegt, lohnt sich der Feinschliff an Bildern und Fonts überhaupt in vollem Umfang.

Wichtig ist auch: Diese vier Phasen sind kein reines Theoriekonstrukt. OpenReplay beschreibt, dass die häufigste Ursache für schlechte LCP-Werte eine Kette aus mehreren kleinen Verzögerungen ist, nicht ein einzelner großer Fehler. Genau deshalb lohnt sich die Phasenanalyse: Sie zeigt, wo die Kette reißt, statt pauschal „irgendwas mit Bildern“ zu vermuten.

Bildoptimierung: fetchpriority, Preload und die richtigen Formate

Bilder sind in den meisten Fällen das LCP-Element, und genau hier passieren die teuersten Fehler. Der wichtigste Grundsatz zuerst: Above-the-fold-Bilder dürfen niemals loading="lazy" bekommen. Lazy Loading verzögert die Ressourcenerkennung bewusst, und genau das killt Ihren LCP-Wert.

Priorität setzen statt hoffen

Browser laden Ressourcen standardmäßig nach eigenen Heuristiken, die das eigentliche LCP-Bild oft zu spät entdecken. Das Attribut fetchpriority="high" am <img>-Tag korrigiert das direkt. Laut web.dev können in Fallstudien durch diese eine Zeile deutliche LCP-Verbesserungen erzielt werden. Der Code sieht so aus:

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="Hero-Bild">

Reicht fetchpriority allein nicht, weil das Bild trotzdem zu spät im HTML entdeckt wird (etwa bei dynamisch generiertem Markup), hilft ein Preload im <head>:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Bei responsiven Bildern mit srcset reicht dieser einfache Preload nicht aus. Sie müssen imagesrcset und imagesizes direkt im Preload-Tag angeben, sonst lädt der Browser die falsche Größe oder sogar mehrere Varianten gleichzeitig, Html-einfach detailliert beschreibt:

<link rel="preload" as="image" 
      imagesrcset="hero-480.webp 480w, hero-800.webp 800w, hero-1200.webp 1200w"
      imagesizes="100vw"
      fetchpriority="high">

Die Attribute, die niemals fehlen dürfen

  • width und height immer setzen, sonst reserviert der Browser keinen Platz und es drohen Layout-Shifts, die zusätzlich den Core-Web-Vitals-Wert Cumulative Layout Shift verschlechtern.
  • decoding="async" am LCP-Bild reduziert Blockierzeiten beim Rendern, weil die Bilddekodierung nicht den Hauptthread aufhält.
  • srcset mit mehreren Breakpoints liefert dem Browser die passende Bildgröße für das jeweilige Gerät, statt immer die größte Variante zu laden.
  • AVIF oder WebP statt JPEG oder PNG verwenden. AVIF erreicht bei vergleichbarer Qualität häufig kleinere Dateigrößen als WebP, wird aber nicht von jedem älteren Browser unterstützt, weshalb ein Fallback über <picture> sinnvoll ist.
  • Bild-CDNs mit automatischer Formatumwandlung nehmen Ihnen die manuelle Konvertierung ab und liefern gleich die passende Auflösung pro Gerät.

Ein oft übersehener Punkt: Das LCP-Element sollte laut html-einfach.de im HTML als echtes <img>-Tag stehen, nicht als CSS-Hintergrundbild und nicht per JavaScript nachträglich eingefügt. Der Browser kann CSS-Hintergründe erst nach dem Parsen der Stylesheets entdecken, und JavaScript-generierte Bilder tauchen im Preload-Scanner gar nicht auf. Beides verzögert die Ressourcenerkennung unnötig.

Profi-Tipp: Prüfen Sie mit dem „Coverage“-Tab in Chrome DevTools, wie viel Prozent des geladenen Bildes tatsächlich im sichtbaren Bereich verwendet wird. Häufig laden Shops ein 2400 Pixel breites Originalbild für einen 400 Pixel breiten Slot auf Mobilgeräten, und genau das kostet oft eine ganze Sekunde LCP-Zeit, ohne dass es irgendjemand merkt.

Zur Qualität: Bei JPEG und WebP liefert eine Kompressionsstufe zwischen 70 und 80 meist ein gutes Verhältnis zwischen Dateigröße und visueller Qualität. Bei Hero-Bildern über 200 Kilobyte lohnt sich fast immer eine zweite Kompressionsrunde, bevor Sie an anderen Stellen weitersuchen. Wer wissen will, wie Lazy Loading für alle anderen Bilder unterhalb des sichtbaren Bereichs korrekt eingesetzt wird, ohne das LCP-Element versehentlich mit einzuschließen, findet dazu eine ausführliche Anleitung zu Lazy Loading.

Wie senken Sie Render-Blocking durch Fonts, CSS und JavaScript?

Text-basierte LCP-Elemente hängen stark von Web Fonts und dem Rendering-Pfad ab. Ein einzelnes blockierendes Stylesheet kann den kompletten Seitenaufbau um mehrere hundert Millisekunden verzögern.

Bei Schriftarten gilt: font-display: swap verhindert, dass Text unsichtbar bleibt, bis die Webfont-Datei geladen ist. Ein Preload der wichtigsten Font-Datei im <head> beschleunigt zusätzlich:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Wer Fonts lokal hostet statt über ein externes CDN einzubinden, spart einen zusätzlichen DNS-Lookup und eine zusätzliche Verbindung, was besonders auf Mobilverbindungen spürbar ist. Und: Laden Sie nur die Schriftschnitte, die Sie wirklich nutzen. Vier Gewichte plus Kursivvarianten „für alle Fälle“ einzubinden, kostet unnötig Ladezeit.

Bei CSS und JavaScript helfen folgende Maßnahmen konkret:

  • Critical CSS extrahieren: Die Stile, die für den sichtbaren Bereich beim ersten Rendern nötig sind, direkt inline im <head> einbetten, den Rest asynchron nachladen.
  • JavaScript mit defer oder async laden, damit Skripte das Parsen des HTML nicht blockieren.
  • Nicht-kritische Skripte lazy laden, etwa Chat-Widgets oder Tracking-Pixel, die erst nach dem ersten Rendern benötigt werden.
  • Rechenintensive Aufgaben in Web Workers auslagern, damit der Hauptthread frei bleibt für das eigentliche Rendern.
  • Ungenutztes Theme- oder Plugin-CSS entfernen, denn viele CMS-Templates laden Stylesheets für Funktionen, die auf der jeweiligen Seite gar nicht vorkommen.

Diese Maßnahmen wirken laut OpenReplay besonders stark in Kombination. Ein einzelner Fix bringt selten den großen Sprung, die Summe aus Preload, Bildoptimierung, Critical CSS und JS-Defer schon.

Server, Caching und CDN: den TTFB wirklich senken

TTFB ist meist der größte einzelne Hebel, und genau deshalb sollte er zuerst angegangen werden, bevor Sie sich in Detailarbeit an Bildern verlieren.

Drei Backend-Maßnahmen liefern die größte Wirkung:

  • Full-Page-Cache aktivieren, damit statischer HTML-Output nicht bei jedem Aufruf neu generiert wird. Bei WordPress erledigen das Plugins wie WP Super Cache zuverlässig.
  • Object Cache über Redis oder Memcached einsetzen, um wiederholte Datenbankabfragen abzufangen, besonders bei dynamischen Shop- oder Blogseiten mit vielen Abfragen pro Aufruf.
  • Datenbank-Indizes und langsame Abfragen prüfen, denn ein einzelner unoptimierter Query kann den TTFB um mehrere hundert Millisekunden aufblähen.

Als Zielwert gelten 200 bis 800 Millisekunden TTFB. Alles darüber verdient sofortige Aufmerksamkeit, nicht irgendwann.

Ein CDN bringt gleich mehrere Vorteile zusammen: Edge-Caching bringt Inhalte geografisch näher an den Nutzer, viele Anbieter bieten Bildoptimierung direkt am Edge, und moderne Protokolle wie HTTP/3 sowie Brotli-Kompression reduzieren zusätzlich die Übertragungszeit. Wer sich mit der Hosting-Seite dieser Fragen tiefer beschäftigen will, findet bei Partnern wie BasicBS ergänzende Perspektiven zu Infrastruktur und Hosting-Setups.

Ein letzter, oft unterschätzter Punkt: Redirect-Ketten minimieren. Jede zusätzliche Weiterleitung kostet eine komplette Serverrunde, bevor überhaupt das erste Byte der eigentlichen Seite ankommt. Auch Same-Origin-Überlegungen zählen: Ressourcen von zu vielen unterschiedlichen Domains erzeugen zusätzliche DNS-Lookups und Verbindungsaufbauten, die sich direkt in der Resource-Load-Delay-Phase niederschlagen.

Warum zeigen Labordaten und Felddaten unterschiedliche LCP-Werte?

Lighthouse und PageSpeed Insights liefern Labordaten: einmalige Messungen unter kontrollierten Bedingungen. Die echte Nutzererfahrung zeigt sich erst im Chrome User Experience Report (CrUX) oder im eigenen Real User Monitoring. Beide Datenquellen können deutlich voneinander abweichen, weil echte Nutzer mit unterschiedlichen Geräten, Netzverbindungen und Standorten unterwegs sind.

Felddaten sollten bei der Bewertung immer Vorrang haben, weil sie die tatsächliche Erfahrung abbilden statt eine synthetische Momentaufnahme. Corewebvitals betont, dass Labortests Unterschiede zwischen Gerätetypen und Verbindungsqualitäten grundsätzlich nicht abbilden können.

Wichtige Praxispunkte für die Segmentierung:

  • Mobil- und Desktop-Daten getrennt betrachten, denn Mobilgeräte zeigen fast immer schlechtere Werte.
  • Verbindungstyp berücksichtigen: 4G- und WLAN-Nutzer erleben eine völlig andere Ladezeit als Nutzer mit langsamer 3G-Anbindung.
  • Das 75. Perzentil ist die relevante Kennzahl, nicht der Durchschnitt. Google bewertet Core Web Vitals danach, wie schnell die Seite für 75 % aller Aufrufe war und nicht nach dem Mittelwert.

Zur Einordnung: Ein einzelner schneller Testaufruf in PageSpeed Insights sagt wenig darüber aus, ob 75 % Ihrer echten Besucher tatsächlich unter 2,5 Sekunden liegen. Erst die CrUX-Daten in der Google Search Console oder ein eigenes RUM-Setup zeigen das ehrlich.

Für die Werkzeugauswahl empfiehlt sich eine Kombination: DevTools für die schnelle Einzelanalyse, WebPageTest für detaillierte Wasserfalldiagramme über mehrere Standorte und Geräte hinweg, und ein RUM-Setup für die kontinuierliche Feldbeobachtung. Wer tiefer in die Interpretation des 75. Perzentils einsteigen will, findet dazu einen ausführlichen Leitfaden zu Core Web Vitals mit RUM.

Ein Zeitfaktor, den viele unterschätzen: Labordaten reagieren sofort auf jede Änderung. Felddaten dagegen brauchen laut OpenReplay oft rund vier Wochen, bis eine Verbesserung stabil im CrUX-Datensatz sichtbar wird, weil Google dort einen rollierenden 28-Tage-Zeitraum zugrunde legt.

Template-Optimierungen: der größte Hebel für viele Seiten gleichzeitig

Eine einzelne URL zu optimieren, bringt eine einzelne URL nach vorn. Eine Template-Optimierung bringt oft Hunderte Seiten gleichzeitig voran, weil das LCP-Element häufig direkt im Seitentemplate definiert ist, wie html-einfach.de beschreibt. Genau das macht Template-Fixes zum effizientesten Einsatz Ihrer Entwicklerzeit.

Konkrete Stellen, die sich lohnen zu prüfen:

  • Das Hero-Markup der Produkt- oder Kategorieseiten-Vorlage, denn dort sitzt bei Shops meist das eigentliche LCP-Bild.
  • Preload-Tags im <head>-Bereich des globalen Templates statt einzeln pro Seite gesetzt.
  • Globale Skript-Includes, die auf jeder Seite geladen werden, auch wenn sie nur auf wenigen Unterseiten wirklich benötigt werden.

Beim Ausrollen einer Template-Änderung hilft ein vorsichtiges Vorgehen: Canary-Rollouts auf einem kleinen Prozentsatz des Traffics zuerst, Feature Flags zum schnellen Zurückrollen bei Problemen, und eine Kombination aus Labor-Check direkt nach dem Deployment plus Feld-Validierung über die folgenden Wochen.

Profi-Tipp: Binden Sie einen Lighthouse-CI-Check in Ihre Deployment-Pipeline ein, der bei jedem Pull Request automatisch den LCP-Wert der wichtigsten Templates misst. So verhindern Sie, dass ein neues Feature den mühsam erreichten Fortschritt in einem Release wieder zunichtemacht.

Wer eine Webdesign-Vorlage von Grund auf performanceorientiert aufbauen will statt bestehende Templates zu patchen, findet dazu passende Unterstützung bei performanceoptimiertem Webdesign.

Ihre Checkliste: LCP-Aufgaben nach Priorität sortiert

Für Entwickler und Produktteams zählt am Ende, was ins Ticketsystem wandert. Diese Reihenfolge hat sich bewährt:

  1. Sofort: LCP-Element mit DevTools identifizieren, loading="lazy" vom Above-the-fold-Element entfernen, fetchpriority="high" setzen und bei Bedarf ein Preload-Tag ergänzen.
  2. Diese Woche: TTFB messen und bei Werten über 800 Millisekunden Full-Page-Cache und Object-Cache prüfen.
  3. Mittelfristig: Critical CSS extrahieren, Bilder auf AVIF oder WebP konvertieren, CDN-Einsatz prüfen.
  4. Laufend: Vorher/Nachher-Werte dokumentieren, sowohl Labormessung als auch das 75. Perzentil der Felddaten.

Für Tickets hilft ein festes Format: Reproduktionsschritte, betroffene URL oder Template, gemessener LCP-Wert vor der Änderung, und die konkrete Erwartung nach dem Fix. Eine allgemeine Zusammenstellung typischer Performance-Aufgaben liefert die Checkliste für bessere Sichtbarkeit als ergänzende Referenz.

Was Sie bei LCP-Projekten wirklich erwarten sollten

Die häufigste Fehldiagnose, die man in der Praxis sieht: Teams stürzen sich auf Bildkompression, während der eigentliche Engpass im Backend liegt. Ein TTFB von über einer Sekunde macht jede Preload-Strategie wirkungslos, ganz gleich wie sauber der Code sonst ist. Bei einem technischen Audit sollte zuerst die Serverantwortzeit geprüft werden, bevor über Bildformate gesprochen wird.

Realistisch erwarten Sie sichtbare Verbesserungen in den Labordaten sofort, in den Felddaten aber erst nach mehreren Wochen, weil Google mit einem rollierenden Zeitraum arbeitet. Wer schnelle Wunder in der Search Console erwartet, wird enttäuscht. Wer strukturiert an TTFB, Template und Bildstrategie arbeitet, sieht die Kurve zuverlässig nach unten wandern.

— Patrick

Technisches LCP-Tuning ohne eigenes Entwicklerteam

Ein technisches Audit deckt in wenigen Tagen auf, wo Ihr LCP wirklich hängt, statt monatelang an Symptomen zu basteln. Ein technisches Audit bietet einen Erst-Check als Einstieg an: Hosting-Audit, Template-Analyse und, falls sinnvoll, ein RUM-Setup zur laufenden Kontrolle der echten Nutzerdaten.

Neomarketing

Anders als eine reine Checkliste zum Selbstumsetzen übernimmt die Dienstleistung auch die konkrete Implementierung: von Preload-Tags im Template über Caching-Konfiguration bis zur Bildpipeline. Das Leistungspaket NEO SEO deckt genau diesen Bereich ab, technische SEO- und Performance-Arbeit auf Templateebene, nicht URL für URL von Hand. Wer zusätzlich eine performanceoptimierte Seitenstruktur von Grund auf braucht, findet das passende Gegenstück bei NEO Webdesign. Die aktuellen Konditionen für alle Pakete stehen auf der Angebotsseite im Detail. Ein Erstgespräch ermöglicht, die aktuellen LCP-Werte aus DevTools und Search Console gemeinsam zu analysieren und die wichtigsten Hebel für die konkrete Seite zu benennen.

Quellen

Für die praktische Arbeit an LCP lohnt sich der direkte Blick in die Primärquellen: der LCP-Leitfaden von web.dev für die offizielle Google-Definition und Zielwerte, WebPageTest für detaillierte Wasserfall-Diagnosen über mehrere Standorte, und PageSpeed Insights für den schnellen Alltagscheck. Bei WordPress-Installationen erledigen Plugins wie WP Super Cache und Autoptimize einen guten Teil der Caching- und Asset-Arbeit automatisch.

FAQ

Was ist LCP genau?

Der Largest Contentful Paint misst die Zeit bis zum Rendern des größten sichtbaren Elements im Sichtbereich, meist ein Bild, ein Textblock oder ein Video-Poster. Google bewertet einen Wert bis 2,5 Sekunden als gut, ab 4,0 Sekunden als schlecht.

Wie kann ich die PageSpeed meiner Webseite verbessern?

Der größte Hebel liegt fast immer beim Server: Full-Page-Cache und Object-Cache senken den TTFB spürbar. Danach folgen Bildoptimierung mit fetchpriority und modernen Formaten sowie das Reduzieren von render-blockierendem CSS und JavaScript.

Wie kann ich meine Website schneller machen?

Beginnen Sie mit der Phase, die am meisten Zeit kostet: meist der Server. Ein TTFB von 200 bis 800 Millisekunden gilt als guter Zielwert, danach lohnt sich die Arbeit an Bildern, Fonts und Skripten. Ein technisches Audit von Neomarketing zeigt binnen kurzer Zeit, welcher Hebel bei Ihrer Seite am meisten bringt.

Wie lange dauert es, bis eine LCP-Verbesserung in den Google-Daten sichtbar wird?

Labordaten aus Lighthouse oder PageSpeed Insights zeigen Änderungen sofort. Felddaten im Chrome User Experience Report brauchen oft rund vier Wochen, bis sich eine Verbesserung stabil zeigt, weil Google einen rollierenden 28-Tage-Zeitraum verwendet.

Was kostet ein technisches LCP-Audit bei Neomarketing?

Die genauen Preise für Pakete wie NEO SEO stehen nicht öffentlich fest, sondern richten sich nach Umfang und Zustand der jeweiligen Seite. Aktuelle Konditionen finden Sie auf der Angebotsseite.

Empfehlungen