Optimiere das Bild für den Largest Contentful Paint

Optimiere das Largest Contentful Paint-Bild

Dieser Leitfaden ist Teil des Largest Contentful Paint (LCP)-Hubs. Auf den meisten Websites ist das LCP-Element ein Bild. Machst du beim Bild einen Fehler, leidet dein LCP-Wert. Dieser Artikel behandelt jede Technik, um es schnell zu machen.

Laut Google haben nur 65 % aller Seitenaufrufe im Internet (Desktop und Mobile) einen guten Largest Contentful Paint-Wert. Das bedeutet, 35 % der Seitenaufrufe fallen durch. Das liegt teilweise an Fehlern bei Bildern. Dieser Artikel schlüsselt gängige Best Practices und Fehler auf, wenn Bilder zum Largest Contentful Paint-Element werden.

All diese Faktoren sind wichtig. Wenn dein LCP-Element jedoch ein Bild ist (was oft der Fall ist!), gibt es einfache Schritte, um es so schnell wie möglich zu laden.

Experimente mit dem Largest Contentful Paint

Ich sage immer: Zuhören und lernen, aber vertraue niemandem blind. Es gibt zu viele „Gurus“, die falsche Informationen predigen. Deshalb habe ich ein vollautomatisches LCP-Experiment entwickelt. Dort kannst du selbst prüfen, was passiert, wenn das LCP-Element nicht optimal geladen wird. Sieh dir meinen LCP-Test auf Github an oder probiere die Live-Demo aus!

Es testet automatisch mehrere LCP-Szenarien für dich und zeigt dir die Ergebnisse. Ich diskutiere diese Szenarien unten. Ich erkläre, wie und warum sie das LCP-Bild-Element beschleunigen oder verlangsamen.

1. Kontrolliere den LCP-Kandidaten: Die Text-First-Strategie

Der schnellste Weg, deinen bildbasierten Largest Contentful Paint zu verbessern? Nutze kein Bild! Moment, was? Ja, richtig gehört. Lass mich das erklären.

Warum Text schneller ist als ein Bild. Der Performance-Unterschied liegt in der Request-Pipeline. Ein Textknoten (wie ein <h1> oder <p>) ist Teil des HTML-Hauptdokuments. Er hat keinen separaten Ressourcen-Request. Sein Rendering wird nur durch CSS blockiert. Ein Bild ist dagegen eine externe Ressource. Es erfordert einen eigenen HTTP-Request. Das bringt Netzwerklatenz (DNS, TCP, TLS und Downloadzeit) mit sich. Zusätzlich wird es von CSS blockiert. Dieser Unterschied ist der Hauptgrund für den Performance-Unterschied. Deshalb ist die Kontrolle des LCP-Kandidaten eine mächtige Strategie auf Expertenniveau.

Was spricht also für Bilder im Vergleich zu Text? Bilder sind wichtig. Sie machen deine Seite optisch ansprechend. Den Core Web Vitals ist es aber egal, welches Element das LCP wird. Wenn das LCP-Element ein textbasiertes Element ist, tritt es normalerweise gleichzeitig mit dem First Contentful Paint auf.

Solltest du also auf ein textbasiertes Largest Contentful Paint-Element umsteigen? Das kommt darauf an! Bilder sind wichtig und machen deine Seite optisch ansprechend. Ich plädiere also nicht dafür, zu alten, langweiligen Textelementen zu wechseln. Aber Fehler passieren! Ich wünschte, ich bekäme einen Dollar für jede Kategorieseite, die dem Anti-Pattern „Accidental LCP“ zum Opfer gefallen ist. Dabei „vergisst“ eine Seite, einen beschreibenden Kategorietext above the fold einzufügen. Dadurch wird ein per lazy loading geladenes Produktbild zum LCP. Das verzögert die Ladezeit um Sekunden. Dies passiert oft, wenn Designer einen großen Hero-Banner ganz oben im DOM platzieren, noch vor wichtigen Überschriften. Das lässt dem Browser keine andere Wahl, als einen langsameren LCP-Kandidaten auszuwählen.

2. Nutze das schnellste verfügbare Bildformat

Ohne eine hitzige Debatte darüber zu führen, wie man das letzte Byte herausquetscht oder welche Einstellungen für WebP vs. AVIF perfekt sind: Lass uns auf eine Sache einigen. Ältere Formate wie JPEG und PNG sind größer und langsamer als moderne Formate wie WebP oder AVIF. Einen vollständigen Überblick über Bildoptimierungstechniken findest du in unserem Leitfaden zur Bildoptimierung.

Als allgemeine Regel solltest du eine verlustbehaftete WebP- oder AVIF-Version deines LCP-Bildes ausliefern. Noch besser: Nutze diese Formate für alle deine Bilder. Hier konzentrieren wir uns aber auf das LCP. Bei einer WebP-Unterstützung von etwa 95 % und einer AVIF-Unterstützung von 92 % macht es immer noch Sinn, ältere Fallback-Bilder auszuliefern. Nutze dafür „Progressive Enhancement“. Dabei liefern wir diese modernen Formate nur an Browser aus, die sie unterstützen.

Kompromiss zwischen Decodierungsgeschwindigkeit und Komprimierung

AVIF bietet die beste Komprimierung (kleinste Dateigröße). Seine komplexen Algorithmen können jedoch mehr CPU-Leistung erfordern als WebP, um es in ein renderbares Bild zu decodieren. Dies ist eine CPU-gebundene Aufgabe. Sie findet in den Rasterizer-Threads des Browsers statt. Sie erhöht direkt das Element Render Delay. Ein kleineres AVIF lädt vielleicht schneller herunter. Seine längere Decodierungszeit könnte diesen Vorteil jedoch zunichtemachen, besonders auf Mobilgeräten. Du kannst dies im Performance-Panel der Chrome DevTools diagnostizieren. Suche nach lang laufenden „Decode Image“-Tasks, die mit deinem LCP-Element verknüpft sind. Wenn du das siehst, ist es ein klares Signal. Deine Decodierungsgeschwindigkeit ist der Engpass, nicht nur die Downloadzeit.

Experteneinblick: Der Fall von JPEG-XL. Ein echter Expertenleitfaden muss JPEG XL ansprechen. Es ist ein technisch bemerkenswertes Format. Das gilt besonders für seine Fähigkeit, bestehende JPEGs verlustfrei neu zu komprimieren (ein riesiger Gewinn für Legacy-Websites). Es unterstützt zudem progressives Decodieren, was AVIF fehlt. Sein entscheidender Nachteil ist jedoch die fehlende breite Browser-Unterstützung, nachdem Chrome es fallen gelassen hat. Das macht es derzeit für den allgemeinen Webgebrauch nicht praktikabel. Behalte es für die Zukunft trotzdem im Auge.

Nutzung des <picture>-Elements: Das <picture>-Element erlaubt es Browsern, nicht unterstützte Bildformate zu überspringen. Sie wählen das erste Format aus, das sie verarbeiten können. So machst du das:

<picture>
<source srcset="img.avif" type="image/avif">
<source srcset="img.webp" type="image/webp">
<img src="img.jpg" alt="Image" width="123" height="123">
</picture>

Kombination von Formataushandlung mit responsiven Größen

Für maximale Performance solltest du Formatauswahl mit responsiven Bildgrößen in einem einzigen <picture>-Element kombinieren. Das stellt sicher, dass jeder Nutzer das optimale Format und die optimale Größe für sein Gerät erhält. Der Browser wertet <source>-Elemente von oben nach unten aus. Er wählt das erste unterstützte Format. Dann nutzt er die Attribute srcset und sizes, um die richtige Auflösung auszuwählen.

<picture>
  <source
    type="image/avif"
    srcset="hero-400w.avif 400w, hero-800w.avif 800w, hero-1200w.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <source
    type="image/webp"
    srcset="hero-400w.webp 400w, hero-800w.webp 800w, hero-1200w.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px">
  <img
    src="hero-800w.jpg"
    srcset="hero-400w.jpg 400w, hero-800w.jpg 800w, hero-1200w.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 800px, 1200px"
    alt="Descriptive alt text for hero image"
    width="1200" height="675"
    fetchpriority="high">
</picture>

Dieses Muster gibt dem Browser völlige Freiheit. Er kann die beste Kombination aus Format und Auflösung wählen. Ein mobiler Nutzer mit einem unterstützten Browser erhält eine kleine AVIF-Datei. Ein älterer Desktop-Browser greift auf ein korrekt dimensioniertes JPEG als Fallback zurück.

Nutzung von Content Negotiation

Content Negotiation lässt deinen Server verschiedene Bildformate basierend auf der Browser-Unterstützung ausliefern. Browser geben unterstützte Formate über den Accept-Header an. In Chrome sieht der Accept-Header für Bilder zum Beispiel so aus:

Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8

Lies dann serverseitig den Accept-Header aus. Liefere basierend auf dem Header das beste Format aus.

3. Nutze responsive Bilder

Wenn es um die Optimierung von LCP-Bildern geht, ist die Größe wirklich wichtig. Einer der einfachsten Gewinne ist die Auslieferung von Bildern mit den kleinstmöglichen Dimensionen. Sie müssen auf den Bildschirmen deiner Nutzer aber immer noch gut aussehen. Große Bilder haben keinen Nutzen. Sie verschwenden Bandbreite und verlangsamen die Ladezeit, besonders bei Nutzern mit langsamen Verbindungen oder auf Mobilgeräten.

Um sicherzustellen, dass du keine Pixel verschwendest, folge diesen Schritten:

Responsive Bilder:

Nutze das srcset-Attribut, um je nach Gerät des Nutzers verschiedene Bildgrößen auszuliefern. So erhalten kleinere Geräte kleinere Bilder. Das hilft, das LCP zu beschleunigen.

Warum das sizes-Attribut kritisch ist

Die Nutzung von srcset mit w-Deskriptoren ohne das sizes-Attribut ist ein häufiger und teurer Fehler. Ohne das sizes-Attribut muss der Browser einen Standardwert von 100vw (100 % der Viewport-Breite) annehmen. Auf einem großen Desktop-Bildschirm lädt der Browser also ein riesiges Bild aus deiner srcset-Liste herunter, selbst wenn das Bild nur in einer kleinen 500px-Spalte angezeigt wird. Du hast die richtigen Zutaten (srcset) geliefert, aber das Rezept (sizes) weggelassen. Das führt zu verschwendeter Bandbreite und einem langsameren LCP. Das sizes-Attribut liefert den nötigen Layout-Kontext. Es sagt dem Browser, wie breit das Bild bei verschiedenen Viewport-Breakpoints tatsächlich sein wird. Das ermöglicht ihm eine intelligente Download-Entscheidung.

Verständnis von w- vs. x-Deskriptoren

Das srcset-Attribut unterstützt zwei Arten von Deskriptoren. Für responsives Design, bei dem sich die Bildgröße mit dem Viewport ändert, ist der w-Deskriptor (Width) die überlegene und notwendige Wahl. Er wird mit dem sizes-Attribut verwendet. So kann der Browser das beste Bild basierend auf seiner gerenderten Größe im Layout auswählen. Der einfachere x-Deskriptor (Device-Pixel-Ratio) berücksichtigt nur die Pixeldichte des Bildschirms. Er ignoriert, wie groß das Bild im Layout tatsächlich ist. Das macht ihn nur für Bilder mit fester Größe wie Icons geeignet.

<img
  src="img.jpg"
  srcset="img-400px.jpg 400w, img-800px.jpg 800w, img-1200px.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Image" width="123" height="123">

4. Skaliere deine Bilder auf die Bildschirmgröße!

Vermeide es, Bilder auszuliefern, die größer als nötig sind. Wenn das LCP-Element im Viewport nur 600px breit ist, stelle sicher, dass das Bild nicht größer ist. Vertrau mir, ich sehe das jeden Tag! Um das zu prüfen, mach Folgendes: Untersuche das Bild. Klicke mit der rechten Maustaste auf das Bild und wähle „Element untersuchen“. Du siehst nun die DevTools. Das Bild-HTML ist mit blauem Hintergrund hervorgehoben. Du kannst nun sehen, dass die gerenderte Bildgröße (443 x 139px) viel kleiner ist als die intrinsische Bildbreite (1090x343px). Das ist fast dreimal so groß. Eine Größenanpassung des Bildes hätte mindestens 50 % der Dateigröße gespart.

5. Nutze Eager Loaded LCP-Bilder

Um die beste Performance aus deinem LCP herauszuholen, solltest du das sichtbare LCP-Element per Eager Loading laden. Lade Bilder, die nicht sofort sichtbar sind, per lazy loading. Das ist einer der häufigsten Fehler bei der LCP-Optimierung. Wir behandeln ihn im Detail in unserem Artikel über das Beheben von per lazy loading geladenen LCP-Bildern.

Eager Loading: Das LCP-Element (meistens Content above the fold) sollte immer per Eager Loading geladen werden. Das stellt sicher, dass es so schnell wie möglich erscheint. Es reduziert die Zeit, die dein Largest Contentful Paint zum Rendern braucht. Standardmäßig laden Bilder per Eager Loading, sofern nicht anders angegeben. Überprüfe trotzdem, dass du nicht loading="lazy" beim LCP-Bild gesetzt hast. Das kann das LCP erheblich verzögern und deinen Core Web Vitals-Wert verschlechtern. Es ist wichtig zu verstehen, dass loading="eager" das Standardverhalten des Browsers ist. Das Weglassen des Attributs hat also denselben Effekt. Die kritische Maßnahme ist sicherzustellen, dass loading="lazy" nicht vorhanden ist.

Geek-Alarm: Lazy Images werden vom Preload Scanner nicht eingereiht. Der Preload Scanner ist ein superschneller sekundärer HTML-Scanner. Er reiht wichtige Ressourcen sofort ein. Wenn der Preload Scanner umgangen wird, muss der Browser warten, bis die Rendering-Engine fertig ist. Erst dann reiht er sichtbare Bilder ein. Damit der Browser natives loading="lazy" auswerten kann, muss er zuerst alles render-blocking CSS herunterladen und parsen. So konstruiert er den Render-Tree. Erst nach der Layout-Berechnung kann der Browser bestimmen, ob sich das Bild im Viewport befindet. Das bedeutet, dass dein gesamtes CSS zu einer blockierenden Abhängigkeit für den LCP-Bild-Download wird. Das ist ein Performance-Desaster.

<img src="lcp-image.jpg" alt="Main image" width="800" height="400">

Für Bilder, die below the fold erscheinen (die beim ersten Laden der Seite nicht sichtbar sind), ist lazy loading der richtige Weg. Indem du das Laden dieser Bilder verzögerst, bis der Nutzer in ihre Nähe scrollt, gibst du Bandbreite frei. Diese steht für wichtigere Inhalte wie dein LCP-Element zur Verfügung. In dieser Hinsicht ist lazy loading ein zweischneidiges Schwert. Richtig angewendet, beschleunigt es deinen LCP-Inhalt. Falsch angewendet, verlangsamt es ihn!

<img src="non-visible-image.jpg"
     alt="Secondary image"
     
     width="800" height="400">

Die Balance? Lade die kritischen Inhalte (wie dein LCP-Bild) per Eager Loading. Lade weniger kritische Ressourcen und Bilder below the fold per lazy loading!

6. Preloade das LCP-Bild

Das Preloading des LCP-Bildes weist den Browser an, es sofort abzurufen. Das passiert, bevor er es auf natürliche Weise im HTML entdeckt. Einen vollständigen Leitfaden zum Preloading findest du in unserem speziellen Artikel über das Preloaden des LCP-Bildes.

Warum das LCP-Bild preloaden?

Wenn der Browser eine Seite lädt, verarbeitet er HTML, Stylesheets und Skripte in einer bestimmten Reihenfolge. Manchmal wird das LCP-Bild weiter unten in der Kette referenziert. Das bedeutet, dass der Browser es später erreicht, als er sollte. Das Preloading des LCP-Bildes teilt dem Browser im Voraus mit, dass dieses Bild kritisch ist und sofort geladen werden sollte. Das reduziert die Verzögerung beim Rendern deines größten Elements.

Wie man das LCP-Bild preloadet

Mit dem <link rel="preload">-Tag kannst du sicherstellen, dass der Browser so früh wie möglich im Ladeprozess beginnt, das LCP-Bild abzurufen.

<link rel="preload" href="lcp-image.jpg" as="image" type="image/jpeg">

Dies stellt sicher, dass sich das LCP-Bild von Anfang an in der Warteschlange des Browsers befindet. Es vermeidet die Wartezeit, die oft entsteht, wenn das Bild in CSS oder Skripten vergraben ist.

<!-- Im <head> -->
<link rel="preload" as="image"
      href="lcp-image-800w.jpg"
      imagesrcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
      imagesizes="(max-width: 600px) 400px, 800px">

<!-- Im <body> -->
<img src="lcp-image-800w.jpg"
     srcset="lcp-image-400w.jpg 400w, lcp-image-800w.jpg 800w"
     sizes="(max-width: 600px) 400px, 800px"
     alt="..." width="800" height="450" fetchpriority="high">

Denk daran: Preloade nur das LCP-Bild. Das Preloaden zu vieler Ressourcen kann den Browser überlasten und die Performance verschlechtern. Halte dich an das, was für deine Core Web Vitals am wichtigsten ist.

7. Entferne Fade-In-Animationen vom LCP-Bild

Fade-In-Animationen können optisch ansprechend sein, aber sie sind ein versteckter LCP-Engpass. Wenn das LCP-Element (oft ein Bild) einen Fade-In-Effekt verwendet, wertet der Browser das LCP erst, wenn die Animation endet. Das verzögert das LCP-Timing und kann deine Performance-Metriken erheblich verschlechtern.

Das LCP-Timing erfolgt nach Ende der Animation: Der Browser betrachtet das LCP erst als abgeschlossen, wenn das Element vollständig sichtbar ist. Wenn du eine Fade-In-Animation hast, läuft der Timer weiter, bis das Bild oder der Inhalt vollständig eingeblendet ist. Das kann deinem LCP-Wert leicht zusätzliche Sekunden hinzufügen.

Halte es einfach: Um sicherzustellen, dass das LCP-Element so schnell wie möglich erscheint, vermeide Fade-In-Effekte. Lass das Bild sofort laden und anzeigen, ganz ohne Übergang oder Animation.

Verzichte auf Fade-Ins beim LCP-Bild. Der visuelle Effekt ist die Performance-Kosten nicht wert.

8. Hoste das LCP-Element selbst

Hoste dein LCP-Bild selbst. Sich auf Server von Drittanbietern zu verlassen, führt zu Verzögerungen, die komplett außerhalb deiner Kontrolle liegen. Das kann dein LCP und die allgemeine Seiten-Performance verschlechtern.

Stell dir das so vor: Dein LCP-Element nicht selbst zu hosten ist so, als würdest du dir ständig Zucker von deinem Nachbarn leihen. Jedes Mal musst du rübergehen, an der Tür warten und hoffen, dass er zu Hause ist. Verlässt du dich für dein LCP auf einen Drittanbieter-Server, muss deine Website auf diese externe Ressource warten. Das verlangsamt die Ladezeit. Selbst-Hosting ist so, als hättest du den Zucker in deiner eigenen Küche: schnell, direkt und zuverlässig.

Reduziere externe Abhängigkeiten: Wenn dein LCP-Element (wie ein Bild) auf einem Server von Drittanbietern gehostet wird, bist du der Geschwindigkeit, Verfügbarkeit und zusätzlichen Round-Trip-Times (RTT) dieses Servers ausgeliefert. Selbst-Hosting beseitigt diese Unsicherheit. Es erlaubt dir, das Bild direkt von deinem eigenen Server auszuliefern. Das stellt eine schnellere und zuverlässigere Auslieferung sicher.

Nutze Caching und Optimierungen: Durch Selbst-Hosting kannst du Caching-Strategien voll ausnutzen. Du kannst das Bild vom nächstgelegenen Server zum Nutzer ausliefern, besonders wenn du ein CDN verwendest. Das reduziert die Zeit, die zum Laden des LCP-Elements benötigt wird. Das Ergebnis ist ein schnelleres Rendering.

Kontrolle über Bildoptimierung: Selbst-Hosting gibt dir die Kontrolle darüber, wie das Bild optimiert wird. Egal ob Komprimierung, Größenänderung oder Formatauswahl, du musst dich nicht auf die Verarbeitung durch Dritte verlassen. So kannst du sicherstellen, dass das Bild perfekt auf schnelles Laden zugeschnitten ist.

9. Vermeide Client-Side Rendering für das LCP-Element

Client-Side Rendering (CSR) ist eines der schlimmsten Dinge, die du deinem LCP antun kannst. Wenn dein LCP-Element (meistens ein großes Bild, ein Textblock oder ein Video) clientseitig via JavaScript gerendert wird, führt das oft zu langsameren LCP-Zeiten. Der Browser muss auf das Herunterladen, Parsen und Ausführen von Skripten warten, bevor er den kritischen Inhalt anzeigt.

Verzögerungen beim Rendern: Bei CSR wird das LCP-Element erst angezeigt, nachdem der Browser JavaScript verarbeitet hat. Das kann sein Erscheinen erheblich verzögern. Je länger das dauert, desto schlechter wird dein LCP-Wert. Jede zusätzliche Sekunde für die Skriptverarbeitung bedeutet eine längere Wartezeit für deine Nutzer, bis sie den wichtigsten Inhalt sehen.

Wechsle zu Server-Side Rendering (SSR) oder Static Rendering: Indem du das LCP-Element serverseitig oder als Teil einer statischen HTML-Antwort renderst, erlaubst du dem Browser, es sofort zu laden und anzuzeigen. Er muss nicht warten, bis JavaScript greift. Das verbessert das LCP-Timing drastisch. Der Browser kann das LCP-Element sofort rendern, wenn er mit dem Laden des HTML beginnt.

Minimiere JavaScript auf dem Critical Path: Wenn du einige clientseitige Skripte nicht vermeiden kannst, stelle sicher, dass sie das Rendern des LCP-Elements nicht blockieren. Nutze Defer oder Async für nicht kritische Skripte. So verhinderst du, dass sie das Erscheinen deines LCP verzögern.

10. Reserviere Platz, um Layout Shifts zu verhindern

Füge immer explizite width- und height-Attribute zu deinen <img>-Tags hinzu. Dies ist eine kritische Anweisung an den Browser. Sie erlaubt es ihm, das Seitenverhältnis des Bildes zu berechnen und den richtigen Platz im Layout zu reservieren, bevor das Bild heruntergeladen wurde.

Experteneinblick: Modernes Verhalten von width und height

Ein häufiges Missverständnis ist, dass diese Attribute ein Bild nicht-responsiv machen. In modernen Browsern stimmt das nicht mehr. Der Browser nutzt diese HTML-Attribute, um ein Seitenverhältnis zu berechnen und den Platz freizuhalten. Das Bild bleibt trotzdem perfekt responsiv, wenn sein CSS auf width: 100%; height: auto; gesetzt ist. Die Bereitstellung dieser Attribute ist der alleinigen Nutzung der CSS-Eigenschaft aspect-ratio überlegen. Der Browser kann den Platz reservieren, bevor jegliches render-blocking CSS heruntergeladen und geparst wurde. Das verschafft ihm einen entscheidenden Vorsprung.

Umgang mit CSS-Hintergrundbildern

Dieses Prinzip gilt auch für Elemente, die als Container für ein CSS background-image dienen. Eine häufige Quelle für Layout Shifts ist ein <div>, das anfangs auf eine Höhe von null kollabiert und dann auf seine Größe aufspringt, wenn das Hintergrundbild angewendet wird. Um das zu verhindern, nutze die CSS-Eigenschaft aspect-ratio direkt auf dem Container-Element. So reservierst du den nötigen Platz von Anfang an.

11. Prüfe auf Blockierungen des main threads

Selbst wenn dein LCP-Bild perfekt optimiert und priorisiert ist, kann sein finales Rendering verzögert werden, wenn der main thread des Browsers mit der Ausführung von schwerem JavaScript beschäftigt ist. Oft sind die Quelle dieser Blockierung Drittanbieter-Skripte für Analytics, Werbung oder Customer-Support-Widgets. Diese Skripte können die CPU monopolisieren und das Element Render Delay erhöhen. Nutze das Performance-Panel in den Chrome DevTools, um long tasks während des initialen Ladevorgangs zu identifizieren. Ordne sie ihrer Quelle zu. Verzögere oder entferne alle Skripte, die für das initiale Rendern nicht kritisch sind. Mehr zu diesem Thema findest du in unserem Leitfaden zum Element Render Delay.

Schritt-für-Schritt-Anleitung: Diagnostiziere LCP mit dem Chrome DevTools Performance-Panel zeigt, wie man einen gedrosselten Trace aufzeichnet und diese long tasks im Main-Track aufspürt.

Verwandte LCP-Optimierungsleitfäden

Bildoptimierung ist ein Teil des Puzzles. Jede LCP-Phase hat ihren eigenen Leitfaden:

• LCP-Probleme beheben &amp; identifizieren: Die komplette Diagnosemethodik zum Finden und Beheben von LCP-Problemen mithilfe von field data und Lab-Tools.
• Resource Load Delay: Stelle sicher, dass der Browser deine LCP-Ressource so früh wie möglich mit Preload, fetchpriority und optimaler HTML-Struktur entdeckt.
• Resource Load Duration: Reduziere die Downloadzeit durch Komprimierung, CDN-Konfiguration und Netzwerkoptimierung.
• Element Render Delay: Mache den main thread frei, damit der Browser das LCP-Element direkt nach dem Download zeichnen kann.