LCP mit einem KI-Agenten beheben: Von Felddaten zum Code-Fix

Ein langsamer Largest Contentful Paint hat vier mögliche Ursachen. Ein KI-Agent, der mit Felddaten verbunden ist, kann identifizieren, welcher davon Ihr tatsächlicher Engpass ist, ihn in Chrome nachverfolgen und den Fix generieren. Dies ist der vollständige LCP-Diagnose-Workflow mit CWV Superpowers.

Zuletzt überprüft von Arjen Karel im März 2026

Die vier LCP-Phasen

Google unterteilt den LCP in vier Phasen. Jede hat andere Ursachen und andere Fixes.

TTFB ist die Zeit vom Start der Navigation bis zum ersten Byte der HTML-Antwort. Langsame Server, fehlendes CDN, kein Caching, lange Datenbankabfragen. Wenn TTFB der Engpass ist, spielt nichts anderes eine Rolle, bis Sie den Server repariert haben.

Load Delay ist die Lücke zwischen dem Empfang von HTML und der Anforderung der LCP-Ressource durch den Browser. Dies ist ein Discovery-Problem. Wenn sich das LCP-Bild in einem CSS-Hintergrund befindet, über JavaScript geladen wird oder hinter einer Kette von Weiterleitungen vergraben ist, kann der Browser nicht mit dem Abruf beginnen, bevor er nicht entdeckt hat, dass er es benötigt.

Load Time ist die Zeit, die das Herunterladen der LCP-Ressource nach der Anforderung dauert. Große Bilder, fehlende Komprimierung, langsames CDN, kein responsives srcset.

Render Delay ist die Lücke zwischen dem abgeschlossenen Download der Ressource und dem tatsächlichen Rendern auf dem Bildschirm durch den Browser. Renderblockierende Skripte, Web-Font-Ladevorgänge oder JavaScript, das das DOM manipuliert, bevor das LCP-Element sichtbar wird.

Den Engpass mit proportionalem Denken finden

Öffentliche Daten über die Core Web Vitals sind nicht gut genug, um Ihnen zu helfen, die wahren Probleme mit Ihren Core Web Vitals zu finden.  Lighthouse führt einen synthetischen Test auf einem simulierten Moto G Power durch und meldet eine LCP-Zeit. CrUX aggregiert 28 Tage echter Chrome-Daten in einem einzigen p75-Wert pro URL. Keines von beiden sagt Ihnen, was Sie beheben müssen.

Es kommt noch schlimmer: Keines von beiden kann sinnvoll segmentieren. CrUX kombiniert gecachte Seitenaufrufe, nicht gecachte Seitenaufrufe, neue Besuche und Seitenaktualisierungen in einem einzigen p75-Wert. Diese sollten als separate Probleme behandelt werden. Gecachte Seitenaufrufe könnten einen TTFB-Engpass aufgrund einer veralteten Cache-Validierung aufweisen. Seitenaktualisierungen verbergen möglicherweise ein Ressourcen-Discovery-Problem, bei dem der Browser das LCP-Bild bei jedem Besuch spät findet. Der vermischte p75-Wert maskiert beides.

CrUX hat 2025 LCP-Teilbereiche hinzugefügt, was hilft. Aber es ist immer noch ein 28-Tage-p75-Wert ohne Element-, Viewport- oder sonstige Filterung. Sie sehen die Phasenanteile für "alle Besucher dieser URL im letzten Monat". Sie sehen nicht, was auf dem spezifischen Gerätetyp, in dem Land oder auf der Seitenvorlage passiert, wo das Problem auftritt.

RUM-Daten segmentieren nach all diesen Dimensionen. CWV Superpowers fragt diese segmentierten Daten ab und interpretiert sie proportional. Der Engpass ist die Phase, die den größten Anteil der Gesamtzeit für das spezifische fehlschlagende Segment verbraucht. Kein bedeutungsloser Durchschnitt oder eine Lighthouse-Simulation. Echte Daten!

Konkretes Beispiel. LCP beträgt 3.800 ms auf mobilen Produktseiten. Die Aufschlüsselung echter Nutzer für Erstbesucher bei gecachten Seitenaufrufen:

• TTFB: 600ms (28.7%)
• Load Delay: 1.900ms (44.6%)
• Load Time: 800ms (19.3%)
• Render Delay: 500ms (7.4%)

Load Delay ist der offensichtliche Engpass. Die Hälfte der gesamten LCP-Zeit verbringt der Browser damit, darauf zu warten, zu entdecken, dass das Bild existiert. Lighthouse, CrUX oder manuelle Untersuchungen hätten echte Schwierigkeiten gehabt, genau diese Kombination von Besuchermerkmalen zu finden, die dieses Problem verursacht hat.

Für eine vollständige Erklärung dieses Ansatzes, siehe proportionales Denken für Web-Performance.

Warum der Browser Ihr Bild spät findet

Load Delay ist der häufigste LCP-Engpass, den ich sehe. Es bedeutet, dass der Browser das HTML empfangen hat, aber erst viel später wusste, dass er das Hero-Bild benötigt.

Drei häufige Ursachen. Das Bild ist ein CSS-Hintergrundbild, das für den Preload-Scanner unsichtbar ist. Die Bild-URL wird in JavaScript konstruiert. Oder das Bild befindet sich technisch gesehen im HTML, verfügt aber über ein Lazy-Loading-Attribut, das der Browser zu eifrig respektiert.

Öffnen Sie den Chrome-Trace. Sie werden eine große Lücke im Netzwerk-Wasserfall zwischen dem Eintreffen des HTML und dem Auslösen der Bildanforderung sehen. Diese Lücke ist Ihr Load Delay. Auf den Websites, die ich auditiere, beträgt er auf Mobilgeräten 1.500 bis 2.500 ms. Zwei volle Sekunden, in denen der Browser das HTML hat, aber keine Ahnung hat, dass er das Hero-Bild benötigt.

Der Agent sieht dieselbe Lücke. Er gleicht den Wasserfall mit der CoreDash-Aufschlüsselung ab und sagt Ihnen genau, warum das Bild zu spät war.

Wie die Diagnose aussieht

So sieht die Ausgabe aus:

KI-Ursache identifiziert: Das LCP-Bild div.hero-banner > img.product-main auf /product/running-shoes-42 wird 1.980 ms zu spät entdeckt, da ihm ein Preload-Hint fehlt und es kein fetchpriority="high" aufweist. CoreDash-Daten: LCP beträgt 3.820 ms (poor) auf Mobilgeräten, p75. Load Delay ist der Engpass mit 52 % der Gesamtzeit. Der Chrome-Trace bestätigt: 1.940 ms Lücke zwischen dem ersten HTML-Byte und der Bildanforderung im Netzwerk-Wasserfall.

Das ist die gesamte Diagnose. Der Agent hat die Datei gefunden und den Diff geschrieben. Sie überprüfen es und stellen es live.

Typische Fixes nach Phase

Load Delay: Fügen Sie einen Preload-Hint im <head> hinzu. Setzen Sie fetchpriority="high" für das LCP-Bild. Verschieben Sie das Bild aus dem CSS-Hintergrund oder JavaScript in das HTML, wo der Preload-Scanner es finden kann.

Load Time: Konvertieren Sie nach WebP oder AVIF. Reduzieren Sie die Bildabmessungen, damit sie der tatsächlichen Anzeigegröße entsprechen. Fügen Sie ein responsives srcset hinzu, damit mobile Nutzer kein Bild in Desktop-Größe herunterladen. Siehe Bilder für Core Web Vitals optimieren.

Render Delay: Entfernen oder verzögern Sie renderblockierende Skripte, die ausgeführt werden, bevor das LCP-Element sichtbar wird. Überprüfen Sie font-display bei Web-Fonts, die sich auf das LCP-Textelement auswirken. Verwenden Sie 103 Early Hints, um CSS früher bereitzustellen.

TTFB: Fügen Sie ein CDN hinzu. Aktivieren Sie serverseitiges Caching. Reduzieren Sie die Zeit für Datenbankabfragen. Verwenden Sie 103 Early Hints, damit der Browser mit dem Vorladen von Ressourcen beginnen kann, während der Server noch die Antwort generiert.

Den Fix verifizieren

Fragen Sie nach dem Deployment die CoreDash-Felddaten für dieselbe Seite und dasselbe Gerätesegment ab. Felddaten werden aktualisiert, wenn echte Nutzer die Seite laden. Normalerweise überprüfe ich dies nach 24 bis 48 Stunden Traffic. Der LCP-p75-Wert sollte sinken und die Verteilung der Engpass-Phasen sollte sich verschieben.

Das ist der Unterschied zwischen dem Reparieren einer Zahl und dem Reparieren der User Experience. Sie warten nicht 28 Tage auf ein CrUX-Update oder führen Lighthouse erneut aus und hoffen, dass der Score gestiegen ist. Sie sehen die Verbesserung in echten Nutzerzahlen, auf den Geräte- und Netzwerksegmenten, in denen das Problem bestand.

Für die INP-Diagnose (die Metrik, die nicht in einem Labor gemessen werden kann), gilt derselbe segmentierte Workflow. Einen breiteren Überblick darüber, wie KI-Agenten Felddaten im Vergleich zu Labordaten über alle drei Core Web Vitals hinweg verwenden, finden Sie unter KI-Agent Core Web Vitals Debugging.