Diagnostiziere den LCP mit dem Chrome DevTools Performance Panel

Dieser Guide gehört zum Largest Contentful Paint (LCP)-Hub. Er behandelt ein Tool: das Chrome DevTools Performance-Panel. Du zeichnest einen gedrosselten Trace auf. Du liest die vier LCP-Teilbereiche ab. Danach weißt du, welchen du zuerst optimieren musst.

DevTools kommen zuletzt, nicht zuerst

Das Performance-Panel ist ein Lab-Tool. Es misst einen Seitenaufruf, auf einem Gerät, in einem Netzwerk: deinem eigenen. Das macht es zum falschen Startpunkt und zum richtigen Endpunkt.

Beginne mit field data. CrUX zeigt dir, ob LCP überhaupt ein Problem ist. RUM-Daten zeigen dir, welche Seiten und welche Elemente für deine echten Nutzer langsam sind. Dieser Workflow wird Schritt für Schritt in LCP-Probleme identifizieren & beheben behandelt. DevTools beantwortet dann die einzige verbleibende Frage: das Warum.

Wenn du die field data überspringst, optimierst du zufällig die Seite, die du gerade testest, auf der Verbindung, die du gerade hast. Dieses Muster sehe ich bei fast jedem Audit: Die Entwicklermaschine besteht, der CrUX p75 fällt durch, alle sind verwirrt. Du hast einen schnellen Laptop am Glasfasernetz gemessen. Deine Nutzer sitzen mit einem Mittelklasse-Android-Gerät im Zug.

Die Live-Metriken-Ansicht

Öffne DevTools (Strg+Umschalt+I unter Windows und Linux, Cmd+Option+I auf dem Mac) und wechsle zum Performance-Tab. Das Panel öffnet sich nicht mehr leer. Bevor du etwas aufzeichnest, zeigt es eine Live-Metriken-Ansicht mit dem LCP, CLS und INP der aktuellen Seite. Diese Werte werden lokal gemessen, während du surfst.

Drei Dinge in dieser Ansicht sind nützlich für die LCP-Arbeit. Erstens benennt sie das LCP-Element. Wenn du mit der Maus darüber fährst, wird das Element auf der Seite hervorgehoben. Du musst also nicht raten, welches Bild oder welche Überschrift der Browser gewählt hat. Außerdem kannst du in dieser Ansicht field data aktivieren. DevTools ruft dann die CrUX-Zahlen für die URL und Origin ab und zeigt sie neben deinen lokalen Werten an. Wenn dein lokaler LCP bei 0,8 Sekunden liegt und der field p75 bei 3,1 Sekunden, ist diese Lücke deine erste Erkenntnis: Deine Maschine ist nicht repräsentativ und Drosselung ist Pflicht.

Ein kurzer Tipp: Wenn du das LCP-Element auf einer beliebigen Seite hervorheben möchtest, ohne DevTools zu öffnen, nutze unsere kostenlose Core Web Vitals Visualizer Chrome-Erweiterung.

Drossle vor dem Aufzeichnen

Ein ungedrosselter Trace auf einer Entwicklermaschine ist fast wertlos. Die Zahlen werden großartig sein. Keine davon wird dem entsprechen, was deine Nutzer erleben. Stelle vor der Aufzeichnung sowohl CPU- als auch Netzwerkdrosselung im Panel ein.

• CPU-Drosselung: Nutze 4x slowdown als Standard für mobile Tests. 20x simuliert ein Low-End-Gerät. Neuere Chrome-Versionen können Presets auch auf deine spezifische Maschine kalibrieren. Die Option „Calibrate“ generiert Presets für Low-Tier- und Mid-Tier-Mobilgeräte, basierend auf der Geschwindigkeit deiner eigenen Hardware. Das ist wichtig. 4x auf einem schnellen Desktop ist ein völlig anderes Gerät als 4x auf einem alten Laptop.
• Netzwerkdrosselung: Nutze Slow 4G. Das ist das Preset, das früher Fast 3G hieß, bevor Chrome es umbenannt hat. Es ist genau das, was Lighthouse für Mobile simuliert. Fast 4G ist die leichtere Option, um bessere Verbindungen zu testen.

Wenn field data aktiviert ist, können DevTools sogar ein Drosselungs-Preset empfehlen, das der Erfahrung deiner echten Nutzer entspricht. Nutze es. Die vollständige Begründung für diese Einstellungen findest du in unserem Guide zu den besten DevTools-Netzwerkeinstellungen für die Core Web Vitals.

Zeichne einen Seitenaufruf auf

Klicke auf den Button „Record and reload“. Chrome navigiert zu einer leeren Seite, startet den Trace, lädt deine Seite und beendet die Aufzeichnung selbstständig ein paar Sekunden nach Abschluss des Ladevorgangs. Für LCP musst du während der Aufzeichnung nichts anfassen. Lass die Finger von der Seite.

Ein kurzer Tipp: Zeichne in einem Inkognito-Fenster mit deaktivierten Erweiterungen auf. Erweiterungen injizieren Skripte in jede Seite. Diese Skripte tauchen in deinem Trace als long tasks auf, die nichts mit deiner Seite zu tun haben.

Lies den LCP-Breakdown-Insight

Nachdem der Trace abgeschlossen ist, listet die Insights-Sidebar links auf, was DevTools gefunden hat. Du suchst nach LCP breakdown (ältere Chrome-Versionen nennen es LCP by phase). Er teilt die LCP-Zeit in vier Teilbereiche auf:

Für einen Text-LCP ohne Webfont gibt es nichts herunterzuladen. Die beiden Ressourcen-Teilbereiche sind also null. Die ganze Geschichte besteht nur aus TTFB und dem Element render delay.

Fahre mit der Maus über einen Teilbereich im Insight. DevTools hebt genau dieses Fenster in der Timeline hervor. Klicke darauf und die Timeline zoomt hinein. So siehst du, welche Requests und Tasks in dieses Fenster fallen. Wenn du field data aktiviert hast, zeigt das Insight den CrUX p75-Wert neben jedem Lab-Teilbereich (sofern CrUX Bild-LCP-Daten für deine Seite hat). Dieser Vergleich ist das am meisten unterschätzte Feature im Panel. Er verrät dir, ob der Trace, den du gerade ansiehst, dem entspricht, was deine Nutzer tatsächlich erleben. Und das, bevor du einen Nachmittag mit Fixes verbringst.

Wie sollte ein gesunder Breakdown aussehen? Googles Vorgabe lautet, dass die beiden Delay-Teilbereiche nahe null liegen sollten (jeweils unter 10 % des LCP). Fast die gesamte Zeit sollte in die TTFB und den eigentlichen Download fließen. Unsere eigene Core Web Vitals-Forschung über Millionen von Seitenaufrufen zeigt, wie weit die Realität davon entfernt ist. Die TTFB beansprucht 48 %, das load delay 24 %, die load duration nur 10 % und das render delay 17 %. Lies das noch einmal: Auf der Median-Seite verschwenden die beiden Wartephasen zusammen viermal mehr Zeit als der Download selbst. In diesen Phasen lädt nichts herunter. Es rendert auch nichts. Der Browser wartet auf Arbeit, die er früher hätte beginnen können. Deshalb sind diese beiden Teilbereiche der erste Ort, um nach Optimierungen zu suchen.

Das LCP request discovery-Insight

Wenn der LCP ein Bild ist, lohnt sich ein zweites Insight: LCP request discovery. Es führt drei Checks für den LCP-Request durch:

• Ist fetchpriority="high" auf das Bild (oder seinen Preload) angewendet?
• Ist der Request im initialen HTML-Dokument auffindbar?
• Ist lazy loading korrekterweise nicht darauf angewendet?

Jeder fehlgeschlagene Check deutet auf ein Discovery-Problem hin. Das Insight markiert in der Timeline den Moment, an dem der Download des Bildes hätte starten können, und schätzt die Zeit, die du verlierst. Jeder dieser drei Fehler hat eine konkrete Lösung. Sie alle werden im Resource Load Delay-Guide behandelt.

Die Timeline selbst lesen

Die Insights decken die häufigen Fälle ab. Für alles andere liest du den Trace direkt. Drei Tracks sind für LCP wichtig.

Der Timings-Track zeigt Marker für FCP, LCP, DCL und das Load-Event. Der LCP-Marker ist der Moment, in dem das Element gezeichnet wurde. Alles, was du diagnostizierst, passiert links davon.

Der Network-Track zeigt jeden Request. Finde die LCP-Ressource. Schau dir an, wann sie startet, nicht nur, wie lange sie dauert. Ein Request, der bei einem 3-Sekunden-LCP erst bei 2,5 Sekunden startet, ist ein Discovery-Problem. Keine Bildkomprimierung wird ihn retten. Wenn du dieses Bild in den ersten HTML-Bytes auffindbar gemacht hättest, hätte der Download begonnen, während der Browser noch den Head parste.

Der Main-Track zeigt die main thread-Arbeit. Long tasks sind mit einem roten Dreieck in der Ecke markiert. Das Muster, auf das du achten musst: Die LCP-Ressource ist fertig heruntergeladen, aber der LCP-Marker sitzt Hunderte von Millisekunden weiter rechts. Diese Lücke ist ein Element render delay. Einer dieser markierten Tasks ist normalerweise dafür verantwortlich. Fahre über den Task, um zu sehen, welches Skript zuständig ist. Meiner Erfahrung nach ist es viel öfter ein Tag-Manager oder ein Consent-Skript als dein eigener Code.

Behebe, was du gefunden hast

Der größte Teilbereich im Breakdown entscheidet, wo du als Nächstes ansetzt: TTFB, Resource Load Delay, Resource Load Duration oder Element Render Delay. Wenn das LCP-Element ein Bild ist, deckt der Guide LCP-Bild optimieren alle vier ab.

Noch eine abschließende Bemerkung: Eine vorgerenderte Seite zeigt alle vier Teilbereiche bei fast null. Der Browser hat die ganze Arbeit erledigt, bevor der Nutzer geklickt hat. Wenn dein LCP-Problem bei Navigationen innerhalb deiner Seite und nicht auf Landingpages auftritt, können Speculation Rules die gesamte Diagnose überflüssig machen.