Was ist der LCP?

Der Largest Contentful Paint misst den Zeitpunkt, an dem das größte sichtbare Inhaltselement fertig gezeichnet ist. Die Uhr läuft ab dem Moment, in dem der Nutzer die Seite aufruft, und stoppt bei diesem einen Element, nicht beim zuletzt geladenen.

Google zählt dabei nur eine feste Gruppe von Kandidaten: <img>-Bilder, Bilder innerhalb eines <svg>, das Vorschaubild eines <video>, jedes Element mit einem per CSS geladenen Hintergrundbild sowie Blöcke, die Text enthalten. Der Browser merkt sich während des Aufbaus laufend den größten Kandidaten; der Wert steht fest, sobald der Nutzer zum ersten Mal mit der Seite interagiert.

Daraus folgt etwas, das viele überrascht: Das Element, das den LCP bestimmt, ist selten das, was man vermutet. Auf einer Produktseite ist es meist das Hauptfoto, in einem Artikel die Überschrift oder das Aufmacherbild, auf einer Startseite mit Video das Standbild. Wer optimieren will, muss es zuerst nachsehen statt es anzunehmen.

Zwei Fragen werden hier oft vermischt. Die eine ist, wie lange die ganze Seite lädt, und das ist das Feld von Page Speed insgesamt. Die andere ist, wann der Besucher etwas sieht, das er als die Seite erkennt, und genau die misst der LCP. Eine Seite kann noch mehrere Sekunden lang Skripte über Google Tag Manager nachladen, ohne dass sich der Wert ändert, solange das Hauptelement bereits steht.

Diese Unterscheidung erklärt, warum der LCP in die Core Web Vitals aufgenommen wurde und keine Kennzahl für die Gesamtladezeit. Erfasst werden soll die Wahrnehmung, nicht die Arbeit des Browsers. Für den Traffic aus der Suche wiegt der Moment, in dem die Seite brauchbar wirkt, schwerer als der, in dem sie fertig ist.

Google setzt drei Stufen: Bis 2,5 Sekunden gilt der LCP als gut, zwischen 2,5 und 4,0 Sekunden als verbesserungswürdig, über 4,0 Sekunden als schlecht. Die Schwellen sind für Mobil und Desktop gleich, die realen Werte werden aber getrennt erfasst.

Am häufigsten missverstanden wird die Aggregation. Gerechnet wird nicht der Durchschnitt, sondern das 75. Perzentil aller Aufrufe der letzten 28 Tage: der Wert, unter dem drei von vier Ladevorgängen bleiben. Ein Mittelwert versteckt die langsamen Nutzer hinter den schnellen. Das 75. Perzentil erzwingt, dass auch der viertschlechteste Fall noch brauchbar ist.

Deshalb kann sich eine Seite im Büro flott anfühlen und trotzdem durchfallen. Das Notebook am Glasfaseranschluss liegt im 20. Perzentil, nicht im 75. Die Werte, die zählen, stammen aus dem Chrome-Nutzererfahrungsbericht, gesammelt aus echten Browsern, und stehen in Google Search Console oder in PageSpeed Insights.

Der LCP ist keine undurchsichtige Zahl. Er zerfällt in vier aufeinanderfolgende Abschnitte, und welcher davon am schwersten wiegt, sagt genau, wo die Arbeit liegt.

1. Zeit bis zum ersten Byte: wie lange der Server braucht, bis er zu antworten beginnt.
2. Verzögerung bis zum Ressourcenabruf: die Lücke zwischen erstem Byte und dem Moment, in dem der Browser das Bild oder die Schrift des LCP-Elements überhaupt anfordert.
3. Dauer des Ressourcenabrufs: wie lange dieser Download dauert.
4. Verzögerung beim Zeichnen: die Zeit zwischen fertigem Download und tatsächlicher Darstellung, meist durch CSS oder JavaScript blockiert.

Bei den meisten gemessenen Seiten entfallen auf die ersten beiden Abschnitte der größte Teil der Gesamtzeit. Damit verlagert sich die Arbeit vom Bild hin zu Server und Ladereihenfolge, und das ist technisches SEO statt Gestaltung.

Die beiden letzten Abschnitte werden am häufigsten für ein Bildproblem gehalten. Überwiegt die Verzögerung beim Zeichnen, liegt die Ursache im Stylesheet oder in einem blockierenden Skript, nicht in der Datei. Das JPEG durch WebP zu ersetzen bewegt den Wert dann nicht, und das ist der häufigste Grund, warum ein Team die Kennzahl für kaputt hält.

Diese Diagnose gehört zum technischen Teil von On-Page-SEO und überschneidet sich mit der Arbeit des Crawlers: Was den menschlichen Browser aufhält, hält meist auch den Roboter auf, und bei knappem Crawl-Budget schlägt das auf die Indexierung durch.

In Prüfung um Prüfung wiederholen sich dieselben vier, fünf Ursachen.

• Verzögertes Laden beim Aufmacherbild. Ein pauschal auf alle Bilder gesetztes loading="lazy" trifft auch das Bild, das den LCP bestimmt, und der Browser fordert es dann absichtlich spät an.
• Langsamer Server ohne Zwischenspeicher. Kommt das erste Byte nach einer Sekunde, bleiben 1,5 für alles Übrige.
• CSS und JavaScript, die das Zeichnen blockieren. Die Ressource liegt vor, und der Browser darf sie nicht darstellen.
• Rendern im Browser statt auf dem Server. Die Seite kommt leer an, der Inhalt erscheint erst nach Ausführung des JavaScripts.
• Unskalierte, unkomprimierte Bilder. Ein JPEG mit drei Megabyte braucht seine Zeit, so gut die Leitung auch ist.

Das verzögerte Laden verdient eine eigene Erklärung, weil es die häufigste Ursache ist und die am leichtesten zu behebende. Das Attribut loading="lazy" sagt dem Browser, ein Bild erst zu laden, wenn der Nutzer in die Nähe scrollt. Für alles unterhalb der ersten Bildschirmseite ist das ein klarer Gewinn: Es spart Daten und gibt Bandbreite für das frei, was tatsächlich zu sehen ist.

Das Problem entsteht, wenn das CMS es pauschal auf alle Bilder setzt, das Aufmacherbild eingeschlossen. Der Browser fordert dann genau die Datei nicht mehr früh an, die den LCP bestimmt, und wartet ab, wo sie im Layout landet. In einer Vorlage mit Responsive Design fällt diese Entscheidung spät, und der Wert verschlechtert sich, ohne dass jemand am Inhalt etwas geändert hätte. Die Faustregel: verzögertes Laden für alle Bilder außer dem ersten sichtbaren, das zusätzlich fetchpriority="high" bekommt.

Die Reihenfolge entscheidet: erst das Element bestimmen, dann den schwersten Abschnitt messen, und erst danach etwas anfassen.

• Beim LCP-Element loading="lazy" entfernen und fetchpriority="high" setzen, damit der Browser es früher anfordert.
• Bild oder Schrift vorab laden, wenn der Browser sie spät entdeckt, weil sie im CSS stecken.
• Das Bild in einem modernen Format und in der Größe ausliefern, die es wirklich einnimmt, mit deklarierter width und height.
• Die Zeit bis zum ersten Byte senken: Seiten-Zwischenspeicher, ein Auslieferungsnetz und weniger Arbeit pro Anfrage auf dem Server.
• CSS und JavaScript aus dem kritischen Pfad nehmen, die für die erste Bildschirmseite nicht gebraucht werden.

Nach jeder Änderung lohnt Geduld. Die Felddaten rechnen über 28 Tage, eine echte Verbesserung ist in Search Console also erst nach Wochen vollständig zu sehen, auch wenn ein Labortest sie sofort anzeigt.

Es lohnt zu trennen, was gemessen wird, und was entschieden wird. Der LCP ist ein technischer KPI: Er sagt, wie lange etwas dauert, nicht ob die Seite überzeugt. Eine Landingpage, die in zwei Sekunden lädt und an der Suchabsicht vorbeigeht, wird weiter nicht konvertieren, und keine Millisekunde ändert daran etwas. Deshalb plant man Geschwindigkeitsarbeit neben CRO, nicht an dessen Stelle.

Ob die Änderung gewirkt hat, zeigen zwei Messungen zusammen. Die Felddaten in Search Console bestätigen die tatsächliche Bewertung; eine Heatmap oder die Kennzahlen aus der Web-Analyse zeigen, ob sich das Verhalten wirklich geändert hat, mit Blick auf Absprungrate und Verweildauer vorher und nachher.

• Ein Bild optimieren, das gar nicht das LCP-Element ist, und sich wundern, dass der Wert stehen bleibt.
• Den Laborwert eines Werkzeugs für die Wirklichkeit halten; für die Bewertung zählen die Daten echter Nutzer.
• Nur den Desktop ansehen, obwohl die Mehrheit der Aufrufe mobil kommt, wo die Mobile-First-Indexierung entscheidet.
• Verzögertes Laden pauschal auf alle Bilder setzen, das erste eingeschlossen.
• Am nächsten Tag nachmessen und aus einem Zeitfenster schließen, das noch 27 Tage alte Daten enthält.

Ein letztes Missverständnis, teurer als es aussieht: den LCP als Note zu behandeln, die man bestehen muss. Die Stufen sind keine Prüfung, sondern eine Beschreibung. Von 4,2 auf 3,8 Sekunden zu kommen verbessert das Erleben der halben Besucherschaft, auch wenn das Etikett weiter „verbesserungswürdig" sagt. In einem E-Commerce-Shop schlägt das auf die Conversion durch, lange bevor der Bericht die Farbe wechselt.