Was zählt auf einer typischen Seite als LCP-Element?

Welches sichtbare Element auch immer die meisten Pixel im Viewport rendert - meist ein Hero-Bild, ein großes Hintergrundbild oder ein großer Block Überschriftentext. Textknoten im selben Block gelten für diese Messung als ein Element.

Wird LCP auf Mobile, Desktop oder beidem gemessen?

Beides, und sie stimmen oft nicht überein. Scanverras Website-Audit führt einen vollständigen Lighthouse-Lauf auf einem Desktop-Profil und erneut auf einem 375px-Mobile-Viewport durch, denn eine Seite, die ihr Hero-Bild preloadet, kann auf Mobile trotzdem langsam sein, wenn dasselbe Bild dort nicht in mobil-passender Größe ausgeliefert wird.

Hilft Preloading immer bei LCP?

Nur für die tatsächliche LCP-Ressource. Das Preloading unbeteiligter Assets konkurriert um dieselbe frühe Bandbreite und kann LCP sogar verschlechtern - preloaden Sie das konkrete Bild oder die Schrift, die der Browser sonst zu spät entdecken würde, nicht alles, was above the fold liegt.

Warum wurde mein LCP schlechter, nachdem ich ein CDN hinzugefügt habe?

Ein CDN hilft erst, sobald Assets tatsächlich an einem Edge-Knoten nahe dem Besucher gecacht sind - die erste Anfrage nach einem Deploy oder einer Cache-Leerung ist ein Cold Miss. Testen Sie direkt nach einem Deploy, führen Sie den Test ein zweites Mal aus, bevor Sie schließen, dass das CDN nicht funktioniert.

Largest Contentful Paint (LCP) beheben

Warum Ihr LCP langsam ist

LCP ist ein Wettlauf zwischen der Browser-Anfrage für Ihre Seite und dem Rendering dieses einen größten Elements. Fast jeder langsame LCP lässt sich auf eines von vier Hindernissen in diesem Wettlauf zurückführen:

Langsame Time to First Byte. Braucht der Server schon 2 Sekunden, um überhaupt zu antworten, kann LCP die Uhr nicht früher starten - alles Nachfolgende erbt diese Verzögerung.
Ein unoptimiertes Hero-Bild. Ein 4-MB-PNG in Anzeigegröße statt eines komprimierten, korrekt dimensionierten Formats ist die mit Abstand häufigste Ursache, die wir sehen.
Render-blockierendes CSS oder JS im <head>. Der Browser kann nichts zeichnen, auch nicht das LCP-Element, bevor er render-blockierende Ressourcen fertig heruntergeladen und geparst hat.
Späte Ressourcen-Entdeckung. Wird das LCP-Bild nur tief in einem CSS-background-image referenziert oder erst nach der Hydration per JavaScript geladen, weiß der Browser erst viel später, dass er es überhaupt anfordern soll.

So identifizieren Sie Ihr LCP-Element

Zu raten, welches Element Ihr LCP ist, ist unzuverlässig - es ändert sich mit Viewport-Größe und Inhalt. Scanverras Website-Audit führt einen echten Lighthouse-Lauf sowohl auf einem Desktop-Profil als auch auf einem 375px-Mobile-Viewport durch und meldet den LCP-Wert und das Timing direkt aus diesem Lauf, keine Schätzung - Sie sehen also dieselbe Metrik, die Googles Felddaten irgendwann widerspiegeln, keinen Näherungswert dafür.

In den Chrome DevTools können Sie außerdem das Performance-Panel öffnen, einen Seitenaufruf aufzeichnen und im Timing-Track nach der "LCP"-Markierung suchen - sie hebt beim Hovern das exakte Element in der gerenderten Seite hervor.

So behebt man es

1. Die tatsächliche LCP-Ressource preloaden

Kann der Browser Ihr Hero-Bild erst nach dem Parsen von CSS oder dem Ausführen von JS entdecken, teilen Sie ihm das Bild stattdessen von vornherein mit:

Das Hero-Bild im Dokument-Head preloadentypescript

1export default function RootLayout() {
2  return (
3    <html lang="en">
4      <head>
5        <link
6          rel="preload"
7          as="image"
8          href="/hero.webp"
9          fetchPriority="high"
10        />
11      </head>
12      <body>{/* ... */}</body>
13    </html>
14  );
15}

2. Das LCP-Bild als hochpriorisiert markieren

Rendern Sie das Hero-Bild über ein Komponenten-Image-Tag, markieren Sie es als priorisierte Ressource, damit es nicht lazy geladen wird und zuerst um Bandbreite konkurriert:

Das Hero-Bild priorisiert laden, Lazy-Loading überspringentypescript

1<img
2  src="/hero.webp"
3  alt="Product dashboard overview"
4  width={1200}
5  height={630}
6  fetchPriority="high"
7  loading="eager"
8/>

3. Das Bild selbst komprimieren und korrekt dimensionieren

Liefern Sie AVIF oder WebP statt PNG/JPEG, wo der Browser es unterstützt, und liefern Sie nie ein Bild größer als die größte Größe, in der es tatsächlich angezeigt wird - ein 3000px breites Quellbild, das per CSS verkleinert wird, kostet trotzdem den vollen Download.

4. Zuerst TTFB aus dem Weg räumen

Ein langsam ladendes Bild zu preloaden behebt keinen langsamen Server. Ist TTFB ein bedeutender Teil Ihres LCP-Budgets, beheben Sie das zuerst - siehe die TTFB-Anleitung unten -, denn jede andere LCP-Optimierung ist dadurch begrenzt, wie spät der Browser überhaupt starten kann.

5. Render-blockierende Ressourcen aus dem kritischen Pfad entfernen

Verschieben Sie nicht-kritisches JavaScript oder laden Sie es asynchron, binden Sie die kleine Menge an CSS, die für Above-the-Fold-Inhalt nötig ist, inline ein, und laden Sie den Rest Ihres Stylesheets, ohne den ersten Bildaufbau zu blockieren.

Wie Scanverra LCP-Probleme erkennt

Scanverras Performance-Checks führen einen echten Lighthouse-Audit gegen Ihre Live-URL durch, sowohl auf Desktop als auch auf einem 375px-Mobile-Viewport, und melden das reale LCP-Timing aus diesem Lauf zusammen mit den anderen Core Web Vitals - das ist keine synthetische Schätzung und keine gecachte Drittanbieter-Zahl.