Das Largest Contentful Paint Bild optimieren

Optimieren Sie das Largest Contentful Paint Bild

Laut Google haben nur 65% aller Seitenaufrufe im Internet (und das schließt Desktop sowie Mobilgeräte ein) einen 'guten' Largest Contentful Paint Score. Das bedeutet, dass 35% der Seitenaufrufe scheitern, und das liegt zum Teil an Fehlern, die mit Bildern gemacht werden. Dieser Artikel schlüsselt gängige Best Practices und Fehler auf, wenn Bilder das Largest Contentful Paint Element werden.

Obwohl all diese Faktoren wichtig sind: Wenn Ihr LCP-Element ein Bild ist (und das ist es häufig!), gibt es einfache Schritte, die Sie unternehmen können, um sicherzustellen, dass es so schnell wie möglich lädt!

Experimente mit dem Largest Contentful Paint

Ich sage immer: Zuhören und lernen, aber niemanden beim Wort nehmen. Es gibt zu viele 'Gurus' da draußen, die falsche Informationen predigen. Deshalb habe ich ein vollautomatisches LCP-Experiment erstellt, bei dem Sie selbst überprüfen können, was passiert, wenn das LCP-Element nicht optimal geladen wird.  Schauen Sie sich meinen LCP Test auf GitHub an oder probieren Sie die Live-Demo! 

Es wird automatisch mehrere LCP-Szenarien für Sie testen und Ihnen die Ergebnisse anzeigen. Ich werde diese Szenarien unten besprechen und erklären, wie und warum es das LCP-Bildelement beschleunigen oder verlangsamen wird.

1. Kontrollieren Sie den LCP-Kandidaten: Die Text-First-Strategie

Der schnellste Weg, Ihren bildbasierten Largest Contentful Paint zu verbessern? Verwenden Sie kein Bild! Moment, was? Ja, Sie haben richtig gehört. Lassen Sie es mich erklären.

Warum Text schneller ist als ein Bild. Der Leistungsunterschied liegt in der Anfrage-Pipeline. Ein Textknoten (wie ein <h1> oder <p>) ist Teil des Haupt-HTML-Dokuments. Er hat keine separate Ressourcenanfrage; sein Rendering wird nur durch CSS blockiert. Ein Bild hingegen ist eine externe Ressource, die ihre eigene HTTP-Anfrage erfordert. Dies führt zu Netzwerklatenz (DNS, TCP, TLS und Downloadzeit), zusätzlich dazu, dass es durch CSS blockiert wird. Dieser Unterschied ist der Hauptgrund für den Leistungsunterschied und warum die Kontrolle des LCP-Kandidaten eine leistungsstarke Strategie auf Expertenniveau ist.

Also, was spricht für Bilder im Vergleich zu Text? Bilder sind wichtig, sie machen Ihre Seite visuell ansprechend. Aber Core Web Vitals kümmert sich nicht darum, welches Element zum LCP wird. Wenn das LCP- Element ein textbasiertes Element ist, tritt es normalerweise zusammen mit dem First Contentful Paint auf.

Sollten Sie also zu einem textbasierten Largest Contentful Paint Element wechseln? Das kommt darauf an! Bilder sind wichtig und  sie machen Ihre Seite visuell ansprechend. Das bedeutet, dass Sie mich nicht dafür plädieren hören werden, zu alten langweiligen Textelementen zu wechseln. Aber Fehler passieren auch! Wenn ich einen Dollar für jede Kategorieseite hätte, die dem **"Accidental LCP" Anti-Muster** zum Opfer fiel. Dies ist der Fall, wenn eine Seite "vergisst", einen beschreibenden Kategorietext above the fold hinzuzufügen, wodurch ein lazy-geladenes Produktbild zum LCP wird und die Ladezeiten um Sekunden verzögert. Dies geschieht oft, wenn Designer ein großes Hero-Banner ganz oben im DOM platzieren, vor irgendwelchen signifikanten Überschriften, was dem Browser keine andere Wahl lässt, als einen langsameren LCP- Kandidaten auszuwählen.

2. Verwenden Sie das schnellste verfügbare Bildformat

Ohne in eine hitzige Debatte über das Ausquetschen des letzten Bytes oder die perfekten Einstellungen für WebP vs. AVIF einzusteigen, lassen Sie uns auf eines einigen: Ältere Formate wie JPEG und PNG sind größer und langsamer im Vergleich zu modernen Formaten wie WebP oder AVIF. Wenn Sie tiefer eintauchen möchten, dieser Artikel schlüsselt es auf.

Als allgemeine Regel sollten Sie eine verlustbehaftete WebP- oder AVIF-Version Ihres LCP-Bildes bereitstellen (noch besser ist es, diese Formate für alle Ihre Bilder zu verwenden, aber wir konzentrieren uns hier auf LCP). Mit WebP-Unterstützung bei etwa 95% und AVIF-Unterstützung bei 92% ist es immer noch sinnvoll, auch ältere Fallback-Bilder bereitzustellen. Tun Sie dies einfach durch 'progressive Enhancement', bei dem wir diese modernen Formate nur an Browser liefern, die sie unterstützen.

Dekodiergeschwindigkeit vs. Kompromiss bei der Komprimierung

Während AVIF die beste Komprimierung (kleinste Dateigröße) bietet, können seine komplexen Algorithmen mehr CPU-Leistung erfordern, um in ein renderbares Bild dekodiert zu werden, verglichen mit WebP. Dies ist eine CPU-gebundene Aufgabe, die auf den Rasterizer-Threads des Browsers stattfindet und die Element Render Delay direkt erhöht. Ein kleineres AVIF mag schneller heruntergeladen werden, aber seine längere Dekodierzeit könnte diesen Vorteil zunichtemachen, insbesondere auf Mobilgeräten. Sie können dies im Chrome DevTools Performance-Panel diagnostizieren, indem Sie nach lang laufenden "Decode Image"-Aufgaben suchen, die mit Ihrem LCP- Element verbunden sind. Wenn Sie dies sehen, ist es ein klares Signal, dass die Dekodiergeschwindigkeit Ihr Engpass ist, nicht nur die Downloadzeit.

Experteneinblick: Der Fall von JPEG-XL Ein echter Expertenleitfaden muss JPEG XL ansprechen. Es ist ein technisch bemerkenswertes Format, insbesondere wegen seiner Fähigkeit, bestehende JPEGs verlustfrei neu zu komprimieren (ein riesiger Gewinn für Legacy-Websites) und seiner Unterstützung für progressives Dekodieren, was AVIF fehlt. Sein entscheidender Nachteil ist jedoch das Fehlen einer breiten Browserunterstützung, nachdem es von Chrome fallen gelassen wurde. Dies macht es noch nicht praktikabel für den allgemeinen Webgebrauch, positioniert es aber als eines, das man für die Zukunft im Auge behalten sollte.

Verwendung des <picture>-Elements: Das <picture>-Element ermöglicht es Browsern, nicht unterstützte Bildformate zu überspringen und das erste auszuwählen, 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="Bild" width="123" height="123">
</picture>

Verwendung von Content Negotiation: Content Negotiation lässt Ihren Server verschiedene Bildformate basierend auf der Browserunterstützung bereitstellen. Browser kündigen 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

Lesen Sie dann auf der Serverseite den Accept-Header und liefern Sie basierend auf dem Header das 'beste Format' aus 

3. Verwenden Sie responsive Bilder

Wenn es um die Optimierung von LCP-Bildern geht, spielt die Größe wirklich eine Rolle. Einer der einfachsten Gewinne ist das Bereitstellen von Bildern mit den kleinstmöglichen Abmessungen, die auf den Bildschirmen Ihrer Benutzer immer noch gut aussehen. Große Bilder haben überhaupt keine Funktion: Sie verschwenden Bandbreite & verlangsamen Ladezeiten, insbesondere für Benutzer mit langsameren Verbindungen oder Mobilgeräten.

Um sicherzustellen, dass Sie keine Pixel verschwenden, befolgen Sie diese Schritte:

Responsive Bilder:

Verwenden Sie das srcset-Attribut, um basierend auf dem Gerät des Benutzers unterschiedliche Bildgrößen bereitzustellen. Auf diese Weise erhalten kleinere Geräte kleinere Bilder, was hilft, den LCP zu beschleunigen.

Warum das `sizes`-Attribut entscheidend ist

Die Verwendung von srcset mit w-Deskriptoren, aber das Weglassen des sizes-Attributs ist ein häufiger und kostspieliger Fehler. Ohne das sizes-Attribut ist der Browser gezwungen, einen Standardwert von 100vw (100% der Viewport-Breite) anzunehmen. Das bedeutet, dass der Browser auf einem großen Desktop-Bildschirm ein riesiges Bild aus Ihrer srcset-Liste herunterlädt, selbst wenn das Bild nur in einer kleinen 500px-Spalte angezeigt wird. Sie haben die richtigen Zutaten (srcset) geliefert, aber das Rezept (sizes) weggelassen, was zu verschwendeter Bandbreite und einem langsameren LCP führt. Das sizes-Attribut liefert den entscheidenden Layout-Kontext und teilt dem Browser mit, wie breit das Bild bei verschiedenen Viewport-Breakpoints tatsächlich sein wird, wodurch er eine intelligente Download-Wahl treffen kann.

Verständnis von `w` vs. `x`-Deskriptoren

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

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

Vermeiden Sie es, Bilder bereitzustellen, die größer als nötig sind. Wenn das LCP-Element im Viewport nur 600px breit ist, stellen Sie sicher, dass das Bild nicht größer als das ist. Vertrauen Sie mir, ich sehe das jeden Tag passieren! Um dies zu überprüfen, tun Sie einfach Folgendes: Untersuchen Sie das Bild, indem Sie mit der rechten Maustaste auf das Bild klicken und 'Untersuchen' wählen. Sie werden nun die Dev-Tools sehen und das Bild-HTML ist mit einem blauen Hintergrund hervorgehoben. Sie können nun sehen, dass die gerenderte Größe des Bildes (443 x 139px)  viel kleiner ist als die intrinsische Bildbreite  (1090x343px). Das ist fast 3-mal so groß und die Größenänderung des Bildes hätte mindestens 50 der Dateigröße sparen können

5. Verwenden Sie eager geladene LCP-Bilder

Um die beste Leistung aus Ihrem LCP herauszuholen, sollten Sie das sichtbare LCP-Element eager laden (und Bilder lazy laden, die nicht sofort sichtbar sind).

Eager Loading: Das LCP-Element (normalerweise Inhalt above-the-fold) sollte immer eager geladen werden. Dies stellt sicher, dass es so schnell wie möglich erscheint, was die Zeit verkürzt, die Ihr Largest Contentful Paint zum Rendern benötigt. Standardmäßig laden Bilder eager, sofern nicht anders angegeben, aber überprüfen Sie doppelt, ob Sie loading="lazy" auf dem LCP-Bild gesetzt haben. Dies zu tun kann den LCP erheblich verzögern und Ihren Core Web Vitals Score beeinträchtigen. Es ist wichtig zu verstehen, dass loading="eager" das Standardverhalten des Browsers ist, sodass das vollständige Weglassen des Attributs denselben Effekt hat. Die kritische Maßnahme ist sicherzustellen, dass loading="lazy" nicht vorhanden ist.

Geek-Alarm: Lazy Images werden vom Preload Scanner nicht in die Warteschlange gestellt. Der Preload Scanner ist ein superschneller sekundärer HTML-Scanner, der wichtige Ressourcen sofort in die Warteschlange stellt. Wenn der Preload Scanner umgangen wird, muss der Browser warten, bis die Rendering-Engine fertig ist, bevor er 'sichtbare Bilder' in die Warteschlange stellt. Damit der Browser natives loading="lazy" bewerten kann, muss er zuerst alles render-blockierende CSS herunterladen und parsen, um den Render-Baum zu konstruieren. Erst nachdem das Layout berechnet wurde, kann der Browser bestimmen, ob sich das Bild im Viewport befindet. Das bedeutet, dass Ihr gesamtes CSS zu einer blockierenden Abhängigkeit für den LCP-Bilddownload wird, was eine Leistungskatastrophe ist.

<img src="lcp-image.jpg" alt="Hauptbild" 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 Sie das Laden dieser Bilder verzögern, bis der Benutzer in ihre Nähe scrollt, geben Sie Bandbreite für wichtigere Inhalte frei, wie Ihr LCP-Element. Auf diese Weise ist Lazy Loading ein zweischneidiges Schwert: Wenn es richtig verwendet wird, beschleunigt es Ihren LCP-Inhalt, wenn es falsch verwendet wird, verlangsamt es ihn!.

<img src="non-visible-image.jpg" 
     alt="Sekundäres Bild" 
     
     width="800" height="400">

Die Balance? Laden Sie den kritischen Inhalt (wie Ihr LCP-Bild) eager und lazy laden Sie weniger kritische Ressourcen und Bilder below the fold!

6. Preladen Sie das LCP-Bild

Das Preladen des Largest Contentful Paint (LCP) Bildes ist eine der einfachsten Möglichkeiten, sein Erscheinen auf der Seite zu beschleunigen. Es teilt dem Browser mit, das Laden dieses Bildes zu priorisieren, um sicherzustellen, dass es so schnell wie möglich bereit ist.

Warum das LCP-Bild preladen?

Wenn der Browser eine Seite lädt, verarbeitet er das HTML, Stylesheets und Skripte in einer bestimmten Reihenfolge. Manchmal wird das LCP- Bild weiter unten in der Kette referenziert, was bedeutet, dass der Browser später dazu kommt als er sollte. Das Preladen des LCP- Bildes lässt den Browser im Voraus wissen, dass dieses Bild kritisch ist und sofort geladen werden sollte, was die Verzögerung beim Rendern Ihres größten Elements reduziert.

Wie man das LCP-Bild preladet

Durch die Verwendung des <link rel="preload">-Tags können Sie sicherstellen, dass der Browser so früh wie möglich im Ladeprozess mit dem Abrufen des LCP-Bildes beginnt.

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

Dies stellt sicher, dass das LCP-Bild von Anfang an in der Warteschlange des Browsers ist, wodurch das Warten vermieden wird, das oft auftritt, 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">

Denken Sie daran: Preladen Sie nur das LCP-Bild, da das Preladen zu vieler Ressourcen den Browser überfordern und die Leistung beeinträchtigen kann. Bleiben Sie bei dem, was für Ihre Core Web Vitals am wichtigsten ist.

7. Entfernen Sie Fade-in-Animationen vom LCP-Bild

Fade-in-Animationen können visuell ansprechend sein, aber wenn es um Ihren Largest Contentful Paint geht, sind sie ein versteckter Engpass. Wenn das LCP-Element (oft ein Bild) einen Fade-in-Effekt verwendet, zählt der Browser den LCP erst, wenn die Animation beendet ist. Dies verzögert das LCP-Timing und kann Ihre Leistungsmetriken erheblich beeinträchtigen.

LCP-Timing passiert nachdem die Animation endet: Der Browser betrachtet den LCP erst als vollständig, wenn das Element vollständig sichtbar ist. Wenn Sie eine Fade-in-Animation haben, läuft der Timer weiter, bis das Bild oder der Inhalt vollständig eingeblendet ist, was Ihrem LCP-Score leicht zusätzliche Sekunden hinzufügen kann.

Halten Sie es simpel: Um sicherzustellen, dass das LCP-Element so schnell wie möglich erscheint, vermeiden Sie die Verwendung von Fade-in-Effekten. Lassen Sie das Bild sofort laden und anzeigen, ohne jeglichen Übergang oder Animation.

Indem Sie Fade-ins auf dem LCP-Bild überspringen, verhindern Sie unnötige Verzögerungen und verbessern Ihre Core Web Vitals, was eine schnellere, reibungslosere Erfahrung für Benutzer gewährleistet.

8. Self-Hosten Sie das LCP-Element

Um die beste Leistung aus Ihrem Largest Contentful Paint herauszuholen, sollten Sie immer in Betracht ziehen, das LCP-Element selbst zu hosten, insbesondere wenn es sich um ein Bild oder eine andere kritische Ressource handelt. Das Verlassen auf Server von Drittanbietern kann Verzögerungen einführen, die vollständig außerhalb Ihrer Kontrolle liegen, was Ihren LCP und die gesamte Seitenleistung beeinträchtigen kann.

Betrachten Sie es so: Das nicht Self-Hosten Ihres LCP-Elements ist wie das ständige Leihen von Zucker von Ihrem Nachbarn. Jedes Mal müssen Sie hinübergehen, an der Tür warten und hoffen, dass sie zu Hause sind. Das Verlassen auf einen Drittanbieter-Server für Ihren LCP lässt Ihre Website auf diese externe Ressource warten, was die Ladezeiten verlangsamt. Self-Hosting ist wie das Aufbewahren des Zuckers in Ihrer Küche: "schnell, direkt und zuverlässlich".

Reduzieren Sie externe Abhängigkeiten: Wenn Ihr LCP-Element (wie ein Bild) auf einem Server eines Drittanbieters gehostet wird, sind Sie der Geschwindigkeit, Verfügbarkeit und eventuellen zusätzlichen Round-Trip-Times (RTT) dieses Servers ausgeliefert. Self-Hosting eliminiert diese Unsicherheit, sodass Sie das Bild direkt von Ihrem eigenen Server bereitstellen können, was eine schnellere und zuverlässigere Lieferung gewährleistet.

Nutzen Sie Caching und Optimierungen: Durch Self-Hosting können Sie Caching-Strategien voll ausschöpfen und das Bild von dem Server bereitstellen, der dem Benutzer am nächsten ist, insbesondere wenn Sie ein CDN verwenden. Dies reduziert die Zeit, die das Laden des LCP-Elements benötigt, was zu schnellerem Rendering führt.

Kontrolle über Bildoptimierung: Self-Hosting gibt Ihnen die Kontrolle darüber, wie das Bild optimiert wird, sei es Komprimierung, Größenänderung oder Formatauswahl —ohne auf die Handhabung durch Dritte angewiesen zu sein. Auf diese Weise können Sie sicherstellen, dass das Bild perfekt auf schnelles Laden zugeschnitten ist.

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

Client-Side Rendering (CSR) kann ein großes Hindernis sein, wenn es um die Optimierung Ihres Largest Contentful Paint geht. Wenn Ihr LCP-Element (normalerweise ein großes Bild, Textblock oder Video) auf der Client-Seite über JavaScript gerendert wird, führt dies oft zu langsameren LCP- Zeiten, da der Browser warten muss, bis Skripte heruntergeladen, geparst und ausgeführt wurden, bevor der kritische Inhalt angezeigt wird.

Verzögerungen beim Rendering: Mit CSR wird das LCP-Element erst angezeigt, nachdem der Browser JavaScript verarbeitet hat, was sein Erscheinen erheblich verzögern kann. Je länger dies dauert, desto schlechter wird Ihr LCP-Score. Jede zusätzliche Sekunde, die mit der Verarbeitung von Skripten verbracht wird, führt zu einer längeren Wartezeit für Ihre Benutzer, um den wichtigsten Inhalt zu sehen.

Wechseln Sie zu Server-Side Rendering (SSR) oder Statischem Rendering: Indem Sie das LCP-Element serverseitig oder als Teil einer statischen HTML-Antwort rendern, ermöglichen Sie dem Browser, es sofort zu laden und anzuzeigen, ohne darauf zu warten, dass JavaScript einsetzt. Dies verbessert das LCP-Timing drastisch, da der Browser das LCP-Element sofort rendern kann, wenn er mit dem Laden des HTML beginnt.

Minimieren Sie JavaScript auf dem kritischen Pfad: Wenn Sie nicht vermeiden können, einige client-seitige Skripte zu verwenden, stellen Sie sicher, dass sie das Rendern des LCP-Elements nicht blockieren. Defer oder async nicht-kritische Skripte, um zu verhindern, dass sie das Erscheinen Ihres LCP verzögern.

10. Reservieren Sie Platz, um Layoutverschiebungen zu verhindern

Fügen Sie immer explizite width- und height-Attribute in Ihre <img>-Tags ein. Dies ist eine kritische Anweisung an den Browser, die es ihm ermöglicht, das Seitenverhältnis des Bildes zu berechnen und die richtige Menge an Platz im Layout zu reservieren, *bevor* das Bild heruntergeladen wurde.

Experteneinblick: Modernes width- und height-Verhalten

Ein häufiges Missverständnis ist, dass diese Attribute ein Bild nicht responsiv machen. Dies ist in modernen Browsern nicht mehr wahr. Der Browser verwendet diese HTML-Attribute, um ein Seitenverhältnis zu berechnen und den Platz freizuhalten, aber das Bild ist immer noch perfekt responsiv, wenn sein CSS auf width: 100%; height: auto; gesetzt ist. Die Bereitstellung dieser Attribute ist der Verwendung der reinen CSS-Eigenschaft aspect-ratio überlegen, da der Browser den Platz reservieren kann, *bevor* irgendwelches render-blockierendes CSS heruntergeladen und geparst wurde, was ihm einen entscheidenden Vorsprung verschafft.

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 Layoutverschiebungen ist ein <div>, das anfangs auf eine Höhe von null zusammenbricht und dann in der Größe springt, wenn das Hintergrundbild angewendet wird. Um dies zu verhindern, verwenden Sie die CSS-Eigenschaft aspect-ratio direkt auf dem Container-Element, um den erforderlichen Platz von Anfang an zu reservieren.

11. Audit auf Main-Thread-Blockierung

Selbst wenn Ihr LCP-Bild perfekt optimiert und priorisiert ist, kann das endgültige Rendering verzögert werden, wenn der Main Thread des Browsers mit der Ausführung von schwerem JavaScript beschäftigt ist. Oft ist die Quelle dieser Blockierung Skripte von Drittanbietern für Analysen, Anzeigen oder Kundensupport-Widgets. Diese Skripte können die CPU monopolisieren, was die Element Render Delay erhöht. Verwenden Sie das Performance-Panel in Chrome DevTools, um lang laufende Aufgaben während des anfänglichen Ladens zu identifizieren, sie ihrer Quelle zuzuordnen und alle, die für das anfängliche Rendern nicht kritisch sind, zu verzögern oder zu entfernen.