Optimiere das Largest Contentful Paint-Bild

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 Fehler, leidet dein LCP-Wert. Dieser Artikel zeigt jede Technik, um es schnell zu machen.

Laut Google haben nur 65 % aller Seitenaufrufe im Internet (das gilt für Desktop wie Mobilgeräte) einen „guten“ Largest Contentful Paint-Wert. Das bedeutet: 35 % der Seitenaufrufe fallen durch. Das liegt teilweise an Fehlern bei den Bildern. Dieser Artikel schlüsselt bewährte Best Practices und typische Fehler auf, wenn Bilder das Largest Contentful Paint-Element sind.

All diese Faktoren sind wichtig. Ist dein LCP-Element jedoch ein Bild (und das ist es oft!), kannst du mit einfachen Schritten dafür sorgen, dass es so schnell wie möglich lädt!

Experimente mit dem Largest Contentful Paint

Ich sage immer: Hör zu und lerne, aber glaube niemandem ungeprüft. Es gibt da draußen zu viele „Gurus“, die falsche Informationen verbreiten. Deshalb habe ich ein vollautomatisches LCP-Experiment erstellt, bei dem du selbst sehen kannst, 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 bespreche diese Szenarien unten und erkläre, wie und warum sie das LCP-Bildelement beschleunigen oder verlangsamen.

1. LCP-Kandidaten steuern: Die Text-First-Strategie

Der schnellste Weg, deinen bildbasierten Largest Contentful Paint zu verbessern? Verwende kein Bild! Warte, was? Ja, du hast richtig gehört. Ich erkläre es.

Warum Text schneller ist als ein Bild. Der Performance-Unterschied liegt an der Request-Pipeline. Ein Textknoten (wie ein <h1> oder <p>) ist Teil des Haupt-HTML-Dokuments. Er hat keinen separaten Ressourcen-Request; sein Rendering wird nur durch CSS blockiert. Ein Bild hingegen ist eine externe Ressource, die einen eigenen HTTP-Request erfordert. Das führt zu Netzwerklatenz (DNS, TCP, TLS und Downloadzeit), zusätzlich zur CSS-Blockierung. Dieser Unterschied ist der Hauptgrund für den Performance-Unterschied. Den LCP-Kandidaten zu steuern, ist eine mächtige Experten-Strategie.

Was spricht also für Bilder versus Text? Bilder sind wichtig; sie machen deine Seite visuell ansprechend. Aber den Core Web Vitals ist es egal, welches Element zum LCP wird. Wenn das LCP-Element ein textbasiertes Element ist, fällt es meistens mit dem First Contentful Paint zusammen.

Solltest du also zu einem textbasierten Largest Contentful Paint-Element wechseln? Das kommt darauf an! Bilder sind wichtig und machen deine Seite visuell ansprechend. Das heißt: Ich werde nicht dafür plädieren, auf alte, langweilige Textelemente umzusteigen. Aber Fehler passieren! Ich wünschte, ich hätte einen Dollar für jede Kategorieseite, die dem „Accidental LCP“-Anti-Pattern zum Opfer fällt. Dabei „vergisst“ eine Seite, einen beschreibenden Kategorietext im sichtbaren Bereich einzufügen. Dadurch wird ein per lazy loading geladenes Produktbild zum LCP und verzögert die Ladezeit um Sekunden. Das passiert oft, wenn Designer einen großen Hero-Banner ganz oben im DOM platzieren, noch vor wichtigen Überschriften. Dem Browser bleibt keine andere Wahl: Er muss einen langsameren LCP-Kandidaten wählen.

2. Nutze das schnellste verfügbare Bildformat

Wir müssen nicht über das letzte Byte oder die perfekten Einstellungen für WebP vs. AVIF streiten. Eines ist klar: Ältere Formate wie JPEG und PNG sind größer und langsamer als moderne Formate wie WebP oder AVIF. Für eine vollständige Übersicht aller Techniken zur Bildoptimierung siehe unseren Leitfaden zur Bildoptimierung.

Als Faustregel gilt: Liefere eine verlustbehaftete WebP- oder AVIF-Version deines LCP-Bildes aus (am besten nutzt du diese Formate für alle Bilder, aber wir konzentrieren uns hier auf den LCP). Da die WebP-Unterstützung bei rund 95 % und die AVIF-Unterstützung bei 92 % liegt, ist es weiterhin sinnvoll, auch ältere Fallback-Bilder auszuliefern. Nutze dafür „Progressive Enhancement“: Liefere diese modernen Formate nur an Browser aus, die sie unterstützen.

Abwägung: Dekodiergeschwindigkeit vs. Kompression

AVIF bietet die beste Kompression (kleinste Dateigröße). Die komplexen Algorithmen benötigen beim Dekodieren in ein darstellbares Bild aber mehr CPU-Leistung als WebP. Dies ist eine CPU-gebundene Aufgabe. Sie läuft auf den Rasterizer-Threads des Browsers und erhöht direkt das Element Render Delay. Ein kleineres AVIF lädt zwar schneller herunter, aber seine längere Dekodierzeit kann diesen Vorteil zunichte machen – besonders auf Mobilgeräten. Du kannst das im Performance-Panel der Chrome DevTools diagnostizieren. Suche nach lang laufenden „Decode Image“-Tasks, die mit deinem LCP-Element verknüpft sind. Wenn du diese siehst, ist es ein klares Signal: Die Dekodiergeschwindigkeit ist dein Flaschenhals, nicht nur die Download-Zeit.

Experten-Wissen: Der Fall JPEG-XL. Ein echter Experten-Leitfaden muss JPEG XL erwähnen. Es ist ein technisch bemerkenswertes Format. Es kann bestehende JPEGs verlustfrei neu komprimieren (ein großer Gewinn für Legacy-Websites) und unterstützt progressives Dekodieren, was AVIF fehlt. Der entscheidende Nachteil ist jedoch die fehlende breite Browser-Unterstützung, nachdem Chrome das Format gestrichen hat. Damit ist es für den allgemeinen Web-Einsatz noch nicht nutzbar. Für die Zukunft solltest du es aber im Auge behalten.

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

<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>

Format-Aushandlung mit responsiven Größen kombinieren

Für maximale Performance solltest du die Format-Auswahl mit responsiven Bildgrößen in einem einzigen <picture>-Element kombinieren. So erhält jeder Nutzer das optimale Format und die optimale Größe für sein Gerät. Der Browser wertet <source>-Elemente von oben nach unten aus und wählt das erste Format, das er unterstützt. Danach wählt er mit den Attributen srcset und sizes die richtige Auflösung.

<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 lässt dem Browser alle Freiheit, die beste Kombination aus Format und Auflösung zu wählen. Ein mobiler Nutzer auf einem unterstützten Browser erhält eine kleine AVIF-Datei. Ein älterer Desktop-Browser nutzt als Fallback ein JPEG in der passenden Größe.

Content Negotiation nutzen

Durch Content Negotiation liefert dein Server je nach Browser-Unterstützung unterschiedliche Bildformate aus. Browser teilen die unterstützten Formate über den Accept-Header mit. In Chrome sieht der Accept-Header für Bilder beispielsweise so aus:

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

Lies dann serverseitig den Accept-Header aus und liefere basierend darauf das „beste Format“ aus.

3. Nutze responsive Bilder

Bei der Optimierung von LCP-Bildern ist die Größe entscheidend. Eine der einfachsten Optimierungen: Liefere Bilder in den kleinstmöglichen Abmessungen aus, die auf den Bildschirmen deiner Nutzer noch gut aussehen. Große Bilder haben keinen Nutzen: Sie verschwenden Bandbreite und verlängern die Ladezeit, besonders für Nutzer mit langsamen Verbindungen oder auf Mobilgeräten.

Befolge diese Schritte, um keine Pixel zu verschwenden:

Responsive Bilder:

Verwende das srcset-Attribut, um je nach Gerät des Nutzers verschiedene Bildgrößen bereitzustellen. So erhalten kleinere Geräte kleinere Bilder. Das beschleunigt den LCP.

Warum das sizes-Attribut entscheidend ist

Die Verwendung 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 annehmen (100 % der Viewport-Breite). Das bedeutet: Auf einem großen Desktop-Bildschirm lädt der Browser ein riesiges Bild aus deiner srcset-Liste herunter, selbst wenn das Bild nur in einer 500px breiten Spalte angezeigt wird. Du hast die richtigen Zutaten geliefert (srcset), aber das Rezept vergessen (sizes). Das verschwendet Bandbreite und verlangsamt den 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. So kann der Browser eine intelligente Entscheidung beim Download treffen.

w- vs. x-Deskriptoren verstehen

Das srcset-Attribut unterstützt zwei Arten von Deskriptoren. Für responsive Designs, bei denen sich die Bildgröße mit dem Viewport ändert, ist der w-Deskriptor (Breite) die bessere und notwendige Wahl. Er wird zusammen mit dem sizes-Attribut verwendet, damit der Browser das beste Bild basierend auf der gerenderten Größe im Layout auswählt. Der einfachere x-Deskriptor (Geräte-Pixel-Verhältnis) berücksichtigt nur die Pixeldichte des Bildschirms. Er ignoriert, wie groß das Bild im Layout tatsächlich ist. Deshalb eignet er sich nur für Bilder mit fester Größe wie Icons.

<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="Bild" 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. Glaub mir, das sehe ich jeden Tag! Um das zu prüfen, mach einfach Folgendes: Klicke mit der rechten Maustaste auf das Bild und wähle „Untersuchen“. Du siehst nun die DevTools und der HTML-Code des Bildes ist blau hinterlegt. Dort siehst du, dass die gerenderte Bildgröße (443 x 139px) viel kleiner ist als die intrinsische Bildbreite (1090x343px). Das ist fast dreimal so groß. Eine Skalierung des Bildes hätte mindestens 50 % der Dateigröße eingespart.

5. Verwende sofort geladene LCP-Bilder

Um die beste Performance aus deinem LCP herauszuholen, solltest du das sichtbare LCP-Element sofort laden (und Bilder, die nicht sofort sichtbar sind, per lazy loading laden). Das ist einer der häufigsten Fehler bei der LCP-Optimierung. Wir behandeln ihn ausführlich in unserem Artikel über die Behebung von per lazy loading geladenen LCP-Bildern.

Eager Loading: Das LCP-Element (meistens Inhalte im direkt sichtbaren Bereich) sollte immer sofort geladen werden. Dies stellt sicher, dass es so schnell wie möglich erscheint, und verkürzt die Renderzeit deines Largest Contentful Paint. Standardmäßig laden Bilder sofort, sofern nicht anders angegeben. Überprüfe aber genau, ob du nicht loading="lazy" für das LCP-Bild festgelegt hast. Das kann den LCP erheblich verzögern und deinen Core Web Vitals-Score verschlechtern. Es ist wichtig zu verstehen, dass loading="eager" das Standardverhalten des Browsers ist. Das Attribut wegzulassen hat also denselben Effekt. Die entscheidende Maßnahme ist sicherzustellen, dass loading="lazy" nicht vorhanden ist.

Geek-Alert: Bilder mit lazy loading werden nicht vom Preload-Scanner eingereiht. Der Preload-Scanner ist ein extrem schneller, sekundärer HTML-Scanner. Er reiht wichtige Ressourcen sofort ein. Wird der Preload-Scanner umgangen, muss der Browser auf die Rendering-Engine warten, bevor er „sichtbare Bilder“ einreiht. Damit der Browser natives loading="lazy" auswerten kann, muss er zuerst das gesamte render-blocking CSS herunterladen und parsen, um den Render-Tree aufzubauen. Erst nach der Layout-Berechnung kann der Browser bestimmen, ob das Bild im viewport liegt. Das bedeutet: Dein gesamtes CSS wird zu einer blockierenden Abhängigkeit für den LCP-Bild-Download. Das ist eine Performance-Katastrophe.

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

Für Bilder unterhalb des sichtbaren Bereichs (die beim ersten Laden der Seite nicht sichtbar sind) ist lazy loading die richtige Wahl. Indem du das Laden dieser Bilder verzögerst, bis der Nutzer in deren Nähe scrollt, gibst du Bandbreite für wichtigere Inhalte wie dein LCP-Element frei. So ist lazy loading ein zweischneidiges Schwert: Richtig eingesetzt beschleunigt es deine LCP-Inhalte. Falsch eingesetzt verlangsamt es sie!

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

Die Balance? Lade kritische Inhalte (wie dein LCP-Bild) sofort. Nutze lazy loading für weniger kritische Ressourcen und Bilder unterhalb des sichtbaren Bereichs!

6. Lade das LCP-Bild vor

Das Vorladen des LCP-Bildes teilt dem Browser mit, es sofort abzurufen. Dies geschieht, bevor er es auf natürlichem Weg im HTML entdeckt. Für eine vollständige Anleitung zum Vorladen siehe unseren speziellen Artikel über das Vorladen des LCP-Bildes.

Warum das LCP-Bild vorladen?

Wenn der Browser eine Seite lädt, verarbeitet er HTML, Stylesheets und Skripte in einer bestimmten Reihenfolge. Manchmal wird das LCP-Bild erst weiter unten in der Kette referenziert. Der Browser entdeckt es daher später als nötig. Das Vorladen des LCP-Bildes lässt den Browser vorab wissen, dass dieses Bild kritisch ist und sofort geladen werden sollte. Dies reduziert die Verzögerung beim Rendern deines größten Elements.

So lädst du das LCP-Bild vor

Mit dem <link rel="preload">-Tag stellst du sicher, dass der Browser so früh wie möglich im Ladevorgang mit dem Abruf des LCP-Bildes beginnt.

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

Dies sorgt dafür, dass sich das LCP-Bild von Anfang an in der Warteschlange des Browsers befindet. So verhinderst du Wartezeiten, die oft entstehen, 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: Lade nur das LCP-Bild vorab. Zu viele vorab geladene Ressourcen überfordern den Browser und schaden der Performance. Konzentriere dich auf 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, sind aber ein versteckter LCP-Engpass. Nutzt das LCP-Element (oft ein Bild) einen Fade-In-Effekt, erfasst der Browser das LCP erst nach dem Ende der Animation. Das verzögert das LCP-Timing und kann deine Performance-Metriken erheblich verschlechtern.

Das LCP-Timing erfolgt erst nach dem Ende der Animation: Der Browser stuft das LCP erst als abgeschlossen ein, wenn das Element vollständig sichtbar ist. Bei einer Fade-In-Animation läuft der Timer weiter, bis das Bild oder der Inhalt vollständig eingeblendet ist. Das kann deinen LCP-Wert leicht um zusätzliche Sekunden erhöhen.

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

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

8. Hoste das LCP-Element selbst

Hoste dein LCP-Bild selbst. Die Nutzung von Drittanbieter-Servern führt zu Verzögerungen. Diese liegen komplett außerhalb deiner Kontrolle. Das kann deinen LCP und die gesamte Performance der Seite verschlechtern.

Stell es dir so vor: Dein LCP-Element nicht selbst zu hosten ist wie ständiges Zuckerleihen beim Nachbarn. Jedes Mal musst du rübergehen, an der Tür warten und hoffen, dass jemand da ist. Wenn du dich für deinen LCP auf einen Drittanbieter-Server verlässt, muss deine Website auf diese externe Ressource warten. Das verlangsamt die Ladezeit. Self-Hosting ist, 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 Drittanbieter-Server gehostet wird, bist du von der Geschwindigkeit, Verfügbarkeit und zusätzlichen Roundtrip-Zeiten (RTT) dieses Servers abhängig. Self-Hosting beseitigt diese Unsicherheit. Du kannst das Bild direkt von deinem eigenen Server ausliefern, was eine schnellere und zuverlässigere Bereitstellung garantiert.

Nutze Caching und Optimierungen: Durch Self-Hosting nutzt du Caching-Strategien optimal aus. Du lieferst das Bild vom Server aus, der dem Nutzer am nächsten ist – besonders, wenn du ein CDN verwendest. Das verkürzt die Ladezeit des LCP-Elements, was zu einem schnelleren Rendern führt.

Kontrolle über die Bildoptimierung: Self-Hosting gibt dir die Kontrolle darüber, wie das Bild optimiert wird – ob Komprimierung, Größenänderung oder Formatauswahl – ohne auf Drittanbieter angewiesen zu sein. So stellst du sicher, dass das Bild perfekt auf schnelles Laden optimiert ist.

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

Client-Side Rendering (CSR) ist fatal für deinen LCP. Wenn dein LCP-Element (meist ein großes Bild, ein Textblock oder ein Video) clientseitig per JavaScript gerendert wird, führt das oft zu langsameren LCP-Zeiten. Der Browser muss warten, bis Skripte heruntergeladen, geparst und ausgeführt sind, 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 dessen Darstellung erheblich verzögern. Je länger das dauert, desto schlechter wird dein LCP-Wert. Jede zusätzliche Sekunde für die Verarbeitung von Skripten verlängert die Wartezeit deiner Nutzer auf den wichtigsten Inhalt.

Wechsle zu Server-Side Rendering (SSR) oder statischem Rendering: Wenn du das LCP-Element serverseitig oder als Teil einer statischen HTML-Antwort renderst, lädt und zeigt der Browser es sofort an. Er wartet nicht, bis JavaScript aktiv wird. Das verbessert die LCP-Zeit drastisch, da der Browser das LCP-Element sofort rendern kann, sobald er das HTML lädt.

Minimiere JavaScript auf dem kritischen Pfad: 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, damit sie die Anzeige deines LCP nicht verzögern.

10. Reserviere Platz, um Layout-Shifts zu verhindern

Gib auf deinen <img>-Tags immer explizite width- und height-Attribute an. Das ist eine kritische Anweisung für den Browser. Er kann so das Seitenverhältnis des Bildes berechnen und den richtigen Platz im Layout reservieren, bevor das Bild heruntergeladen ist.

Experten-Einblick: Modernes Verhalten von width und height

Ein weit verbreiteter Irrtum ist, dass diese Attribute ein Bild nicht-responsiv machen. Das stimmt in modernen Browsern nicht mehr. Der Browser nutzt diese HTML-Attribute, um das Seitenverhältnis zu berechnen und den Platz freizuhalten. Das Bild bleibt trotzdem perfekt responsiv, wenn sein CSS auf width: 100%; height: auto; gesetzt ist. Diese Attribute anzugeben ist besser, als nur die CSS-Eigenschaft aspect-ratio zu nutzen. Der Browser kann den Platz bereits reservieren, bevor das render-blocking CSS heruntergeladen und geparst ist. 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 Ursache für Layout-Shifts ist ein <div>, das anfangs auf eine Höhe von Null kollabiert und plötzlich 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 Main-Thread-Blockaden

Selbst wenn dein LCP-Bild perfekt optimiert und priorisiert ist: Das finale Rendern kann sich verzögern, wenn der Main-Thread des Browsers mit aufwendigem JavaScript beschäftigt ist. Oft sind Drittanbieter-Skripte für Analysen, Werbung oder Support-Widgets die Ursache dafür. Diese Skripte können die CPU stark beanspruchen, was den Element Render Delay erhöht. Nutze das Performance-Panel in den Chrome DevTools. Identifiziere dort Long Tasks beim ersten Laden und ordne sie ihrer Quelle zu. Verschiebe oder entferne alles, was für das initiale Rendern nicht wichtig ist. Mehr zu diesem Thema findest du in unserem Leitfaden zu Element Render Delay.

Weitere Leitfäden zur LCP-Optimierung

Die Bildoptimierung ist nur ein Teil des Puzzles. Jede LCP-Phase hat einen eigenen Leitfaden:

• LCP-Probleme finden &amp; beheben: Die komplette Diagnose-Methodik, um LCP-Probleme mithilfe von field data und lab data zu finden und zu beheben.
• Ressourcen-Ladeverzögerung: Sorge dafür, dass der Browser deine LCP-Ressource so früh wie möglich findet – mit preload, fetchpriority und einer optimalen HTML-Struktur.
• Ressourcen-Ladedauer: Reduziere die Downloadzeit durch Komprimierung, CDN-Konfiguration und Netzwerkoptimierung.
• Element-Render-Verzögerung: Halte den main thread frei, damit der Browser das LCP-Element sofort nach dem Download darstellen kann.