Wie man LCP senkt.

LCP ist die Zeit, zu der das größte Inhaltselement einer Seite im sichtbaren Bereich gemalt wird, und Google zählt unter 2,5 Sekunden als gut.

Die Metrik versucht den Moment zu fassen, in dem der Nutzer sagt „die Seite ist da“. Gemessen wird nicht, wann das erste Pixel der Seite gemalt wurde, sondern wann ihr EIGENTLICHER Inhalt erschien — denn für den Nutzer heißt das Ankommen der Seite das Ankommen dessen, was er lesen wird.

Das gemessene Element ist meist ein Bild oder ein Textblock. Welches Element das LCP-Element ist, variiert je Seite, und die erste Arbeit ist, es zu finden — die Entwicklerwerkzeuge des Browsers markieren es im Performance-Panel direkt. Das falsche Element zu optimieren ist der häufigste und zeitraubendste Fehler.

LCP besteht aus vier Teilen

Um die Zeit zu senken, muss man erst wissen, wohin sie geht. Googles eigene Aufschlüsselung definiert vier Phasen, und jede hat ihre eigene Behandlung.

1. Zeit bis zum ersten Byte — wie lange brauchte der Server für die erste Antwort? Hosting, Cache und Serverarbeit.
2. Ressourcen-Ladeverzögerung — wann entdeckte der Browser die LCP-Ressource und begann sie anzufordern? Ein Entdeckungsproblem.
3. Ressourcen-Ladedauer — wie lange lud die Ressource selbst? Ein Größen- und Formatproblem.
4. Element-Renderverzögerung — wie lange bis zum Malen, nachdem die Ressource da war? Ein Renderblocker-Problem.

Diese Aufschlüsselung beschleunigt die Diagnose. Sammelt sich die Zeit in der ersten Phase, schaut man auf die Serverseite; in der zweiten auf die Entdeckungskette; in der dritten auf die Größe; in der vierten auf renderblockierende Ressourcen. Die Arbeiten für die vier sind völlig verschieden, und sie zu vermischen heißt vergeudete Mühe.

Die Entdeckungsverzögerung: die am meisten übersehene

Die zweite Phase ist praktisch der häufigste Schuldige und die am wenigsten bekannte. Das Problem: Der Browser fordert das LCP-Bild erst an, wenn er es entdeckt — und bei langer Entdeckungskette beginnt er spät. Ist ein Bild im CSS als Hintergrund definiert, muss der Browser erst das HTML, dann das CSS laden und parsen — erst danach weiß er von der Existenz des Bildes.

Dasselbe Problem ist bei per JavaScript eingefügten Bildern noch schlimmer: Die Ressource bleibt unbekannt, bis das Skript geladen und ausgeführt ist. Karussell- und Slider-Komponenten sind für LCP genau deshalb schwach — das erste Bild wird meist vom Skript platziert.

Die Lösung: Die LCP-Ressource erscheint direkt im HTML, das vom Server kommt. Als Bild-Element, nicht als Hintergrund. So entdeckt sie der Preload-Scanner des Browsers beim Parsen des HTML und beginnt sofort mit der Anforderung.

Das zweite Werkzeug zur Beschleunigung der Entdeckung ist der Preload-Hinweis: Dem Browser lässt sich sagen „lade diese Ressource mit Priorität“. Aber dieses Werkzeug will Vorsicht — allem Priorität zu geben liefert dasselbe Ergebnis, wie nichts zu priorisieren, und kann die echte LCP-Ressource verlangsamen.

Die Ladedauer: Größe und Format

Die dritte Phase ist die konkreteste und meist die Stelle des größten Gewinns. Die Größe eines Hero-Bildes bestimmt LCP direkt, und auf den meisten Websites kommt dieses Bild weit größer als nötig.

1. Moderne Formate verwenden — AVIF und WebP liefern dieselbe visuelle Qualität in deutlich kleinerer Datei.
2. Responsive Größen ausliefern — dem Telefon das Desktop-Bild zu schicken ist die häufigste Verschwendung.
3. In echter Größe produzieren — es gibt keinen Grund, dass ein mit 800 Pixeln gezeigtes Bild mit 3000 ankommt.
4. Die Kompression messen — die Qualitätsstufe im Vergleich wählen, nicht nach Augenmaß.
5. Das LCP-Bild lazy laden — die häufigste kontraproduktive Optimierung.

Der letzte Punkt zählt besonders. Lazy Loading ist ein Gewinn für Bilder AUSSERHALB des sichtbaren Bereichs; das LCP-Element ist per Definition darin, und lazy geladen wird seine Entdeckung verzögert. Pauschales Lazy Loading auf alle Bilder einer Website verschlechtert LCP direkt.

Die Renderverzögerung: blockierende Ressourcen

Die vierte Phase: Das Malen wartet, obwohl die Ressource da ist. Die Ursache ist fast immer dieselbe: Der Browser malt nichts, bevor die Stildateien geladen und geparst sind. Jede zusätzliche Stildatei ist eine zusätzliche Anfrage und ein zusätzliches Warten.

Genau das wurde auf dieser Website gemessen und geschlossen. Im mobilen Lighthouse-Lauf blockierten zwei getrennte Stildateien das Rendern: eine 821 Millisekunden, die andere 221. Die zwei Dateien wurden zu einer verschmolzen und die Kommentare entfernt — 67,4 Kilobyte Quelle, 12,4 Kilobyte nach gzip. Der gemessene Gewinn an der renderblockierenden Datei: 11,4 Kilobyte.

Das Entfernen blieb bewusst konservativ: nur Kommentare, Zeileneinzüge und Leerzeilen. Selektoren und Werte wurden nie berührt, denn aggressives Entfernen brachte nur 747 Byte mehr und trug das Risiko, Nachfahren-Pseudo-Muster zu brechen. Gewinn und Risiko wurden beide gemessen und verglichen.

Für 747 Byte riskiert man keinen Selektor — der Gewinn wird gemessen, das Risiko auch.

Eine letzte Erinnerung: LCP ist keine einzelne Zahl, sondern eine Verteilung. In den Felddaten zählt das 75. Perzentil — die Zeit, die drei Viertel der Nutzer erleben. Die auf dem eigenen Gerät gemessene Zeit ist eine Stichprobe vom besten Ende dieser Verteilung und genügt allein für kein Urteil.

Verbreitete falsche Optimierungen

Ein Teil der LCP-Arbeit wirkt rückwärts, und weil es bekannte Muster sind, sind sie besonders heimtückisch. Das häufigste: pauschales Lazy Loading auf allen Bildern. Richtig für Bilder außerhalb des sichtbaren Bereichs, verzögert diese Einstellung am LCP-Element die Entdeckung und erhöht die Zeit direkt.

Zweitens: auf alles einen Preload-Hinweis zu setzen. Die Aufgabe des Hinweises ist, eine Ressource vorzuziehen; auf zehn Ressourcen zugleich gesetzt, wird keine vorgezogen — und die echte LCP-Ressource beginnt, mit den anderen um Bandbreite zu konkurrieren. Die Zahl der auf einer Seite vorzuladenden Ressourcen ist meist eins oder zwei.

Drittens: das Schriftladen blockierend zu machen. Text kann ein LCP-Element sein, und wird bis zur Ankunft der Schrift nichts gemalt, verlängert sich die Zeit direkt. Das richtige Verhalten: sofort mit der Ersatzschrift malen und beim Eintreffen der echten tauschen — aber damit dieser Tausch keine Layoutverschiebung erzeugt, muss die Ersatzfamilie metrisch passen.

Viertens: die Drittanbieter-Skripte zu ignorieren. Analytik, Chat-Blasen und Werbeskripte scheinen nach dem LCP-Element zu laden, teilen aber Bandbreite und Hauptthread. Eine Chat-Blase zu verzögern bringt auf den meisten Websites mehr als das Entschlacken einer Stildatei.