Largest Contentful Paint (LCP): Was es ist, wie man es misst & optimiert

Was ist der Largest Contentful Paint (LCP)?

Der Largest Contentful Paint ist eine Messung der Renderzeit des größten Inhaltselements (vom Typ Bild, Video oder Text), das auf dem sichtbaren Teil des Bildschirms gezeichnet wurde. Das LCP-Timing gibt die Zeit in Millisekunden zwischen der Anforderung der Seite und dem Zeitpunkt an, zu dem dieses größte inhaltsreiche Element auf dem sichtbaren Teil der Webseite (Above the Fold) angezeigt wird.

Geschichte des Largest Contentful Paint

Wenn man darüber nachdenkt, mag der LCP wie eine triviale Metrik erscheinen, um den Lade-Teil der Core Web Vitals zu repräsentieren. Warum messen wir die Ladegeschwindigkeit nicht als 'die Zeit, die die Seite zum Laden benötigt'?

Das liegt daran, dass es bei den meisten modernen Webseiten schwierig (oder sogar unmöglich) ist, zu definieren, wann die Seite geladen ist. Immer mehr Webseiten verwenden Techniken wie Lazy Loading oder progressives Laden, bei denen die Seite im Grunde ewig weiterladen kann. Das bedeutet, dass die Seitengeschwindigkeit nicht an einem einzigen Zeitpunkt gemessen werden kann.

Es gibt verschiedene Momente beim Laden der Seite, die dazu führen können, dass ein Benutzer die Seite als schnell oder langsam empfindet. Zum Beispiel die Serververzögerung (Time to First Byte), das erste Mal, dass Inhalt sichtbar ist (First Contentful Paint), der Zeitpunkt, an dem der sichtbare Viewport vollständig zu sein scheint (Largest Contentful Paint) und wenn die Seite interaktiv wird (wenn das Klicken auf einen Link möglich wird), sind alles Zeitpunkte während des Ladeprozesses, an denen die Seite langsam oder schnell wirken kann!

Der Largest Contentful Paint (LCP) wurde gewählt, weil er sich auf die user experience eines Besuchers konzentriert. Wenn der LCP eintritt, kann man davon ausgehen, dass ein Besucher denkt, die Seite sei fertig geladen (auch wenn im Hintergrund noch Prozesse laufen). Der LCP wurde entwickelt, um die Frage zu beantworten: 'Wann ist der Inhalt einer Seite sichtbar?'. Aus diesem Grund wird LCP als Kernindikator für nutzerzentrierte Performance anerkannt.

LCP vs FCP: Was ist der Unterschied?

Largest Contentful Paint (LCP) und First Contentful Paint (FCP) messen beide die Ladeleistung, erfassen aber grundlegend unterschiedliche Momente im Zeitablauf des Seitenladens. Der FCP wird ausgelöst, sobald der Browser das erste Pixel des Inhalts zeichnet, was eine winzige Navigationsleiste oder ein Ladespinner sein kann. Der LCP wird ausgelöst, wenn das größte aussagekräftige Element im Viewport gerendert wird.

Stellen Sie es sich so vor: FCP sagt Ihnen, dass die Seite begonnen hat zu laden; LCP sagt Ihnen, dass sich die Seite geladen anfühlt. Google hat LCP als Core Web Vital gewählt, weil es genauer widerspiegelt, was Nutzer als "Geschwindigkeit" wahrnehmen.

Für die meisten Webseiten sollte die Optimierung des LCP Priorität haben. Wenn Ihr LCP schnell ist, wird Ihr FCP fast immer ebenfalls schnell sein, da der FCP früher im Zeitverlauf des Ladens auftritt. Umgekehrt gilt das nicht: Ein schneller FCP garantiert keinen schnellen LCP.

Warum LCP für Ihr Unternehmen wichtig ist

Der Largest Contentful Paint ist einer der 3 Core Web Vitals. Als Core Web Vital ist der Largest Contentful Paint wichtig für SEO, aber was noch wichtiger ist: LCP ist entscheidend für die UX. Besucher warten nicht gerne, und bei immer mehr mobilem Traffic (der tendenziell langsamer ist als Desktop-Traffic) macht die Optimierung des Largest Contentful Paint absolut Sinn.

• Für SEO. Ja, Google konzentriert sich darauf, die besten Seiten in seinen Suchergebnissen anzuzeigen. LCP ist Teil der Core Web Vitals von Google. Google gibt klar an, dass die Seitengeschwindigkeit ein factor in den Suchergebnissen ist.
• Für Besucher: Laut aktueller Forschung von Google selbst verdoppelt sich die Wahrscheinlichkeit, dass ein Nutzer die Seite verlässt, bei einer Ladezeit von 3 Sekunden. Das werden Sie wahrscheinlich von sich selbst kennen. Beim Surfen im Internet scheint fast nichts so ärgerlich zu sein wie eine langsam ladende Webseite. Die Chancen stehen gut, dass Sie eine langsam ladende Seite schnell wieder verlassen.
• Andere Gründe: Die Seitengeschwindigkeit ist ein factor in Ihrem Google Ad Score. Dies bedeutet, dass Sie Ihre Anzeigen günstiger kaufen können. Darüber hinaus ist das Bestehen der Core Web Vitals eine der Voraussetzungen für die Top-Story-Box von Google.

Ein schneller LCP vermittelt dem Besucher den Eindruck, dass die Seite schnell lädt. Infolgedessen navigiert ein Besucher seltener von der Seite weg.

Fallstudie: Vodafone (31% LCP-Verbesserung, 8% mehr Umsatz)

Vodafone Italien führte ein kontrolliertes Experiment zur Optimierung ihres LCP-Wertes durch. Durch die Reduzierung des LCP um 31 % verzeichneten sie eine Umsatzsteigerung von 8 %. Dies ist keine Korrelation; es ist ein direkter A/B-Test, der beweist, dass sich ein schneller wahrgenommenes Laden in mehr Umsatz niederschlägt. Die Optimierung konzentrierte sich auf das Preloading des LCP-Bildes und die Reduzierung von render-blocking Ressourcen. Lesen Sie die vollständige Vodafone-Fallstudie auf web.dev.

Fallstudie: Google Flights (fetchpriority sparte 700ms)

Das Team von Google Flights fügte seinem Hero-Bild fetchpriority="high" hinzu und stellte fest, dass sich der LCP um 700 Millisekunden verbesserte. Diese einzige Änderung des HTML-Attributs war die wirkungsvollste Optimierung in ihrem Performance-Sprint. Das fetchpriority-Attribut teilt dem Browser mit, den Download des LCP-Bildes gegenüber anderen Ressourcen zu priorisieren, und wie das Google Flights Experiment zeigt, kann die Auswirkung dramatisch sein. Erfahren Sie mehr über die Ressourcen-Priorisierung für Core Web Vitals.

Welche Elemente werden als LCP-Elemente betrachtet?

Not all elements are considered as an LCP element. Das größte inhaltsreiche Element muss auf dem sichtbaren Teil des Bildschirms (dem Viewport) gezeichnet werden, bevor der Benutzer mit der Seite interagiert hat.

Das Element muss sein:

• Ein <img>-Element.
• Ein <image>-Element, das in einem <svg>- Element verschachtelt ist.
• Ein <video>-Element (das Poster-Bild oder der erste Video-Frame, je nachdem, was früher eintritt, wird verwendet).
• Ein Element mit einem Hintergrundbild, das über die CSS-Funktion url() geladen wird. (Hinweis: Dies ist ein Anti-Pattern für die LCP-Optimierung, da es das Bild für den Preload-Scanner des Browsers unauffindbar macht. Lesen Sie unseren Leitfaden zum Aufschieben von Hintergrundbildern).

• Ein Block-Level-Element, das Textknoten oder andere Inline-Textelemente enthält (bei Inline-Textelementen wie <span> wird das nächstgelegene Block-Level-Element <div> oder <p> berücksichtigt).

Derzeit sind bestimmte Elemente als LCP-Kandidaten ausgeschlossen, wie z. B. mit opacity: 0 versteckte Elemente, Bilder, die 100 % der Viewport-Größe entsprechen (Cover-Bilder), und Platzhalter (Bilder mit niedriger Entropie). Denken Sie daran, dass sich dies im Zuge der Weiterentwicklung der Spezifikation ändern kann!

Technisch werden: Messung der LCP-Elementgröße

LCP identifiziert das größte sichtbare Inhaltselement im Viewport und berechnet seine Größe basierend auf einer Reihe präziser Regeln. Diese Regeln gewährleisten Konsistenz und Genauigkeit, selbst in komplexen Layouts.

• Nur Viewport: Es wird nur der sichtbare Teil der Seite berücksichtigt. Wenn ein Element nur teilweise im sichtbaren Viewport liegt, wird die berücksichtigte Größe beschnitten.
• Kein Rahmen, Padding oder Margin: Bei allen Elementen werden Text- und Bildränder, Abstände (Padding) und Außenabstände (Margin) vollständig ignoriert.
• Textgröße: Textelemente werden als das kleinste Rechteck gemeldet, das um den oder die Textknoten gezeichnet werden kann.
• Bildgröße: Bei Bildern wird die kleinste der intrinsischen Dimensionen (die ursprüngliche Breite und Höhe) und die Anzeigegröße (die Größe auf dem Bildschirm) verwendet, um die LCP-Elementgröße zu berechnen.
• Die erste Größe zählt: Wenn sich das Layout ändert oder wenn sich eine Elementgröße ändert, wird nur die erste Größe für den LCP berücksichtigt.
• Entfernte Elemente werden einbezogen: Wenn ein Element aus dem DOM entfernt wird, ist es immer noch ein LCP-Kandidat.

Dynamische Natur des LCP

Largest Contentful Paint (LCP) ist eine dynamische Metrik. Während das Rendern komplex sein kann und in Phasen erfolgt, ist es normal, dass sich das LCP-Element während des Ladens der Seite ändert. Vor der ersten Benutzerinteraktion identifiziert der Performance Observer des Browsers alle Elemente, die als LCP-Kandidaten in Frage kommen könnten. Wenn ein neues Element gerendert wird, das sowohl innerhalb des Viewports sichtbar als auch größer als das zuvor identifizierte LCP-Element ist, es wird zum neuen LCP.

Erkenntnisse aus LCP-Felddaten: Bei CoreDash verfolgen wir täglich Millionen von LCP-Einträgen. Wie sich herausstellt, ist das LCP-Element bei mobilen Seitenaufrufen oft ein textbasiertes Element, entweder ein Absatz oder eine Überschrift. Im Durchschnitt (oder genauer gesagt im 75. Perzentil) werden die Core Web Vitals bestanden, wenn das LCP-Element ein Textknoten oder sogar ein normales Bild ist. Wenn das LCP-Element ein Hintergrundbild, ein Video oder ein lazy-loaded Bild ist, tendieren die Core Web Vitals dazu, fehlzuschlagen.

Was ist ein guter LCP-Wert?

Um die Core Web Vitals für den Largest Contentful Paint zu bestehen, müssen mindestens 75 % Ihrer Besucher einen 'guten' LCP-Wert haben. Ein LCP-Wert zwischen 0 und 2,5 Sekunden gilt als gut, ein LCP-Wert zwischen 2,5 und 4 Sekunden muss verbessert werden und ein LCP-Wert von über 4 Sekunden gilt als schlecht.

Was reale LCP-Daten zeigen

CoreDash verfolgt täglich Millionen von LCP-Messungen realer Nutzer. Hier ist, was die Daten über die LCP-Performance im Web verraten.

Bild-LCP vs. Text-LCP

Seiten mit bildbasierten LCP-Elementen haben einen LCP im 75. Perzentil von 744ms, fast doppelt so langsam wie textbasierte LCP-Elemente mit 388ms. Dies bestätigt, dass die Bildoptimierung der Bereich mit dem größten Einfluss auf die Verbesserung der LCP-Werte ist. Wenn Ihr LCP-Element ein Bild ist, müssen Sie bei der Optimierung besonders aggressiv vorgehen.

Die Auswirkungen von Preloading und Lazy Loading

Preloaded LCP-Bilder erreichen zu 100 % "gut" Werte mit einem 75. Perzentil von 364ms. Im Gegensatz dazu gehören lazy-loaded LCP-Bilder mit 720ms zu den langsamsten, wobei 4,3 % der Seitenladevorgänge als "schlecht" eingestuft werden. Non-preloaded Bilder schneiden mit 752ms fast ebenso schlecht ab. Die Erkenntnis ist klar: Preloaden Sie Ihr LCP-Bild und führen Sie niemals ein Lazy Loading dafür durch.

Mobile vs. Desktop LCP

Der mobile LCP (764ms im 75. Perzentil) ist doppelt so langsam wie der Desktop-LCP (380ms). Diese Lücke wird durch langsamere Mobilfunknetze und weniger leistungsstarke Mobilprozessoren verursacht. Da Google das Mobile-First-Indexing verwendet, sollte die Optimierung für den mobilen LCP Priorität haben.

Globale LCP-Statistiken

Laut dem HTTP Archive Web Almanac 2025 erreichen weltweit 62 % der mobilen Seiten einen guten LCP-Wert (unter 2,5 Sekunden), gegenüber 44 % im Jahr 2022. LCP bleibt der am schwierigsten zu bestehende Core Web Vital und ist der Hauptengpass für die CWV-Gesamtwerte. Darüber hinaus sind 73 % der mobilen LCP-Elemente Bilder, und 16 % der mobilen Webseiten führen fälschlicherweise ein Lazy Loading für ihr LCP-Bild durch.

Wie LCP gemessen wird: Die vier Schlüsselphasen

Laut Google kann der Largest Contentful Paint in 4 Teilbereiche unterteilt werden. Zu verstehen, welche Phase den Engpass verursacht, ist für eine effiziente Optimierung unerlässlich, da jede Phase eine völlig andere Lösung erfordert. Eine langsame Time to First Byte (TTFB) erfordert serverseitige Arbeit, während eine langsame Ressourcenladeverzögerung Änderungen an Ihrem HTML erfordert.

Die endgültige LCP-Zeit einer Seite ist kein einzelner, monolithischer Wert. Sie ist die Summe aus vier verschiedenen Teilbereichen. Das Verständnis dieser Aufschlüsselung ist der Schlüssel zur effizienten Diagnose und Behebung von LCP-Problemen.

Hier ist eine Aufschlüsselung der vier Phasen:

• Time to First Byte (TTFB): Dies ist die reine Serverantwortzeit. Sie deckt alles ab, vom DNS-Lookup über die TCP/TLS-Verbindung bis hin zu dem Moment, in dem der Browser das erste Byte des HTML-Dokuments empfängt. Eine langsame TTFB ist ein grundlegendes Problem, das Ihren LCP immer ruinieren wird. Im gesamten Web verbringen Seiten mit schlechtem LCP durchschnittlich 2,27 Sekunden allein mit der TTFB, was fast dem gesamten Schwellenwert von 2,5 Sekunden entspricht. Die Optimierung der TTFB umfasst serverseitiges Caching, die Konfiguration von CDNs und effizienten Backend-Code.
• Resource Load Delay: Dies ist die „Entdeckungslücke“. Sie misst die Zeit zwischen dem Abschluss der TTFB und dem tatsächlichen Beginn des Downloads der LCP-Ressource durch den Browser. Eine lange Verzögerung hier bedeutet, dass der Browser die LCP-Ressource spät gefunden hat. Dies ist das klassische Symptom für die Verwendung von CSS-Hintergrundbildern (die der Preload-Scanner nicht entdecken kann) oder Client-Side-Rendering (bei dem das LCP-Element erst nach der Ausführung von JavaScript erscheint). Die Lösung besteht darin, sicherzustellen, dass sich Ihr LCP-Element im ursprünglichen HTML befindet, und das LCP-Bild zu preloaden, wenn der Browser es nicht früh genug entdecken kann.
• Resource Load Duration: Dies ist die Zeit, die benötigt wird, um die LCP-Ressourcendatei (das Bild, die Schriftart oder das Video) tatsächlich herunterzuladen. In dieser Phase geht es vor allem um die Dateigröße und die Netzwerkbedingungen. Optimierung bedeutet die Verwendung moderner Bildformate wie AVIF oder WebP, die Implementierung responsiver Bilder mit srcset und die Bereitstellung von Assets über ein CDN mit angemessener Komprimierung.
• Element Render Delay: Dies ist die letzte Verzögerung. Sie misst die Zeit zwischen dem Ende des Downloads der LCP-Ressource und dem vollständigen Rendern des Elements auf dem Bildschirm. Diese Verzögerung wird fast immer dadurch verursacht, dass der Haupt-Thread des Browsers durch andere Aufgaben blockiert wird, insbesondere durch die JavaScript-Verarbeitung. Render-blocking CSS und synchrone Skripte sind die häufigsten Ursachen.

Jeder dieser Schwerpunktbereiche kann optimiert werden, um den Largest Contentful Paint zu verbessern. Um zu verstehen, welche Schritte Sie unternehmen müssen, lesen Sie LCP-Probleme (Largest Contentful Paint) beheben &amp; identifizieren.

Häufige LCP-Fehler

Nach der Analyse von Millionen von Seitenladevorgängen durch CoreDash treten drei LCP-Fehler weitaus häufiger auf als alle anderen. Die Vermeidung dieser Fehler wird den meisten Seiten zu einem bestandenen LCP-Wert verhelfen.

Fehler 1: Lazy-Loading des LCP-Bildes

Das Hinzufügen von loading="lazy" zu Ihrem Hero-Bild ist der häufigste LCP-Fehler überhaupt. Lazy Loading weist den Browser an, den Download des Bildes absichtlich zu verzögern, bis es in den Viewport gescrollt wird. Für Ihr LCP-Bild (das sich bereits im Viewport befindet), verursacht dies eine völlig unnötige Verzögerung. Laut CrUX-Daten machen 16 % der mobilen Webseiten diesen Fehler. CoreDash-Daten zeigen, dass lazy-loaded LCP-Bilder ein 75. Perzentil von 720ms mit 4,3 % schlechten Erlebnissen haben, verglichen mit 364ms und 0 % schlechten Erlebnissen bei preloaded Bildern. Lesen Sie unseren vollständigen Leitfaden zur Behebung eines lazy-loaded LCP-Bildes.

Fehler 2: Kein Preloading des LCP-Bildes

Selbst ohne Lazy Loading versäumen es viele Seiten, den Browser früh genug über das LCP-Bild zu informieren. Wenn die Bild-URL erst nach dem Parsen von CSS oder der Ausführung von JavaScript entdeckt wird, verschwendet der Browser Hunderte von Millisekunden, bevor er überhaupt mit dem Download beginnt. Die Lösung besteht darin, einen Preload-Hinweis im <head> Ihres Dokuments hinzuzufügen:

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

Dies weist den Browser an, sofort mit dem Herunterladen des Bildes zu beginnen, ohne auf CSS- oder Layoutberechnungen zu warten. Kombinieren Sie dies mit fetchpriority="high" für maximale Wirkung. Erfahren Sie mehr in unserem Leitfaden zum Preloading des LCP-Bildes.

Fehler 3: Verwendung eines CSS-Hintergrundbildes für LCP

CSS-Hintergrundbilder, die über background-image: url(...) sind für den Preload-Scanner des Browsers unsichtbar. Der Browser kann sie erst entdecken, wenn er das HTML heruntergeladen, das CSS geparst und den Render-Tree erstellt hat. Dies führt zu einer erheblichen Ressourcenladeverzögerung. Laut CrUX-Daten verwenden 9 % der mobilen Seiten ein CSS-Hintergrundbild als ihr LCP-Element. Die Lösung besteht darin, stattdessen ein Standard-<img>-Tag mit dem Attribut fetchpriority="high" zu verwenden:

<img src="/img/hero.webp"
     alt="Descriptive alt text"
     width="1200"
     height="600"
     fetchpriority="high">

Das Attribut fetchpriority="high" ist ein direktes Signal an den Browser, dass dieses Bild die Ressource mit der höchsten Priorität auf der Seite ist. Wie die Fallstudie von Google Flights gezeigt hat, kann dieses einzige Attribut den LCP um 700ms reduzieren. Für ein tieferes Verständnis lesen Sie unseren Leitfaden zur Ressourcen-Priorisierung.

So messen Sie den Largest Contentful Paint

Der Largest Contentful Paint (LCP) kann mit reinem JavaScript, Lab-Daten und Feld-Tools gemessen werden. Beide haben ihre Vor- und Nachteile.

Messung des Largest Contentful Paint with JavaScript

Um den Largest Contentful Paint (LCP) mit JavaScript zu messen, bietet die Performance Observer API eine schnelle Lösung. Das folgende Code-Snippet zeigt, wie man das LCP-Timing und die Element-Informationen erfasst:

new PerformanceObserver((list) => {
    const lcpEntry = list.getEntries().at(-1);
    console.log('LCP value: ', lcpEntry.startTime);
    console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  }).observe({ type: 'largest-contentful-paint', buffered: true });

Dieses Snippet verfolgt den LCP-Eintrag während er gemeldet wird und zeigt seinen Zeitstempel und die Element-Details in der Konsole an. Für umfangreichere Einblicke sollten Sie die Verwendung der Web Vitals Library in Erwägung ziehen.

Measure Largest Contentful Paint (LCP) in Chrome DevTools

1. Öffnen Sie die Chrome DevTools durch Drücken von Strg+Umschalt+I (oder Cmd+Option+I auf dem Mac).
2. Navigieren Sie zum Tab Performance.
3. Laden Sie die Seite neu, um die Core Web Vitals anzuzeigen.

Der Performance-Tab der DevTools zeigt nun Informationen über die Core Web Vitals an, einschließlich des Zeitpunkts und des Elements des Largest Contentful Paint.

Messung des Largest Contentful Paint mit Lab- und Feld-Tools

Um es klar zu sagen: Lab- und Feld-Daten dienen zwei verschiedenen Zwecken. Sie benötigen beide.

• Felddaten (RUM und CrUX) sind die einzigen Daten, die tatsächlich für das Bestehen der Core Web Vitals zählen. Es ist das, was Ihre echten Nutzer erleben. Google verwendet diese Daten aus seinem CrUX-Datensatz. Sie beginnen hier, um herauszufinden, ob Sie ein Problem haben.
• Labordaten (Lighthouse usw.) sind ein kontrollierter Test. Es ist nicht das, was Google für das Ranking verwendet, aber es ist unerlässlich für das Debugging. Sie verwenden dies, um herauszufinden, warum Sie ein Problem haben.

Hier ist eine kurze Anleitung zu den wichtigsten Tools:

Verbesserung des Largest Contentful Paint

Optimierung des LCP erfordert einen systematischen Ansatz, der die vier Phasen berücksichtigt. Alles, was passiert, bevor das LCP-Element gezeichnet wird, ob netzwerkbedingt oder CPU-intensiv, kann den LCP-Wert beeinflussen. Jagen Sie nicht nur einer einzigen Lösung hinterher; verstehen Sie die gesamte Kette. Hier ist die übergeordnete Strategie:

• TTFB optimieren: Ihr Server muss schnell sein. Wenn Ihre TTFB langsam ist, spielt alles andere keine Rolle. Dies umfasst serverseitiges Caching, die Verwendung eines CDN und effizienten Backend-Code. Lesen Sie mehr in unserem Leitfaden zur Optimierung der TTFB.
• Ressourcenladeverzögerung eliminieren: Stellen Sie sicher, dass sich das LCP-Element im ursprünglichen HTML befindet, damit der Preload-Scanner des Browsers es sofort finden kann. Vermeiden Sie CSS-Hintergrundbilder für den LCP. Preloaden Sie kritische Bilder, die spät entdeckt werden. Erfahren Sie wie in unserem Leitfaden zur Behebung der Ressourcenladeverzögerung.
• Ressourcenladezeit reduzieren: Verkleinern Sie die LCP-Datei. Das bedeutet die Verwendung moderner Bildformate wie AVIF, responsiver Bilder und angemessener Komprimierung. Siehe unseren vollständigen Leitfaden zur Optimierung des LCP-Bildes. Sie können auch darüber lesen, wie wir den LCP bei einem realen Projekt um 70 % gesenkt haben.
• Shorten Element Render Delay: Stop blocking the main thread. Defer non-critical JavaScript, break up long tasks, and minimize render-blocking CSS. Dies wird in unserem Leitfaden zur Behebung der Element-Renderverzögerung behandelt.

Verwandte Leitfäden

Diese Hub-Seite behandelt den Largest Contentful Paint auf einer übergeordneten Ebene. Für detaillierte, praktische Anleitungen zu jedem Aspekt der LCP-Optimierung erkunden Sie diese speziellen Leitfäden:

• LCP-Probleme beheben &amp; identifizieren: Eine schrittweise Diagnoseanleitung, um mit Chrome DevTools, WebPageTest und CoreDash genau herauszufinden, was Ihren langsamen LCP verursacht.
• LCP-Bild optimieren: Alles über Bildformate, responsive Bilder, Komprimierung und die Bereitstellung des optimalen Bildes für jedes Gerät.
• Ressourcenladeverzögerung: So stellen Sie sicher, dass der Browser Ihre LCP-Ressource so früh wie möglich entdeckt, einschließlich Preloading, fetchpriority und der Vermeidung von CSS-Hintergrundbildern.
• Ressourcenladedauer: Reduzierung der tatsächlichen Downloadzeit der LCP-Ressource durch Optimierung der Dateigröße, CDN-Konfiguration und moderne Komprimierung.
• Element-Renderverzögerung: Eliminierung der Verzögerung zwischen Ressourcen-Download und Screen-Rendering durch Reduzierung der Haupt-Thread-Blockierung durch JavaScript und CSS.