Largest Contentful Paint Was LCP misst, aus welchen vier Abschnitten der Wert besteht und wo große Websites die Zeit verlieren
Largest Contentful Paint misst, wann der Hauptinhalt einer Seite sichtbar ist. Der Wert ist der häufigste Grund dafür, dass eine Seite die Core Web Vitals nicht besteht: In der eigenen Erhebung verfehlen 55,9 Prozent der durchgefallenen Auftritte auf Adobe Experience Manager genau diese Kennzahl. Er ist zugleich der Wert, der sich am gründlichsten zerlegen lässt, und genau darin liegt der Weg zur Ursache.
Schwelle: 2,5 Sekunden im 75. PerzentilEigene Zahlen: Stand August 2026
Was als größtes Element zählt
Der Browser bestimmt fortlaufend das flächenmäßig größte Element im sichtbaren Bereich und meldet dessen Zeichenzeitpunkt. Infrage kommen Bilder, Videoposter, Hintergrundbilder und Textblöcke. Der Wert wird bis zur ersten Eingabe des Nutzers aktualisiert, und es zählt das Element, das zuletzt gemeldet wurde.
In der Praxis ist es auf Startseiten fast immer das Bühnenbild, auf Übersichtsseiten der erste Teaser und auf Artikelseiten die Überschrift oder das Aufmacherbild. Welche Rolle das Bild spielt, lässt sich messen: In der eigenen Erhebung liegt bei 1,9 Prozent der Auftritte eine Bildlücke vor, in der das entscheidende Bild spürbar später kommt als der übrige Inhalt.
Die vier Abschnitte des Werts
Jeder Wert zerfällt in vier Teile, und die Verteilung entscheidet über die Maßnahme.
- Antwortzeit des Servers. Die Zeit bis zum ersten Byte des Dokuments. Sie ist die Untergrenze für alles Weitere und wird auf der Seite zu Time to First Byte behandelt.
- Verzögerung bis zum Ladebeginn. Die Zeit zwischen dem Eintreffen des Dokuments und dem Moment, in dem der Browser die entscheidende Ressource anfordert. Sie wächst durch blockierende Stylesheets, durch Bilder, die erst per Skript gesetzt werden, und durch verzögertes Laden am falschen Element.
- Ladedauer. Die reine Übertragungszeit der Ressource, bestimmt von Dateigröße, Format und Auslieferungsweg.
- Zeit bis zum Zeichnen. Die Spanne zwischen fertigem Laden und sichtbarer Darstellung, meist verursacht durch Skripte, die den Hauptthread belegen, oder durch Schriften, die das Zeichnen des Textes aufhalten.
Diese Aufteilung liefern Laborwerkzeuge je Seite. Ohne sie beginnt die Optimierung bei den Bildern, obwohl der Engpass im ersten Abschnitt liegt. Welche Werkzeuge die Aufteilung zeigen, steht unter Core Web Vitals messen.
Wo große Plattformen die Zeit verlieren
Bei 80,3 Prozent der zu langsamen AEM-Auftritte und 78,8 Prozent der Magnolia-Auftritte liegt bereits die Antwortzeit des Servers über dem Grenzwert. Die Ursache steckt dort in der Cache-Schicht: verfehlte Treffer durch Parameter, zu grobe Invalidierung, Sitzungen für anonyme Besucher. Solange dieser Anteil nicht sinkt, verschiebt jede Frontend-Maßnahme den Wert nur um Bruchteile.
Bleibt die Antwortzeit gut und der Wert trotzdem schlecht, liegt es an der Ladereihenfolge. Die drei wiederkehrenden Muster: Das entscheidende Bild wird verzögert geladen, es wird erst durch ein Skript eingesetzt, oder ein Stylesheet blockiert den Aufbau, bis es vollständig geladen ist. Alle drei sind ohne Umbau behebbar.
Maßnahmen in der Reihenfolge ihrer Wirkung
- Antwortzeit des Servers senken, also Trefferquote des Caches je Seitentyp messen und erhöhen.
- Das Bild des sichtbaren Bereichs bevorzugt laden und niemals verzögern.
- Blockierende Stylesheets auflösen, den für den sichtbaren Bereich nötigen Teil zuerst ausliefern.
- Bildvarianten in passenden Breiten und modernen Formaten ausliefern, statt ein Originalbild zu skalieren.
- Schriften so laden, dass Text sofort sichtbar ist, statt auf die Schrift zu warten.
Diese Reihenfolge gilt unabhängig vom eingesetzten System. Die systemnahen Besonderheiten stehen auf den Seiten zu Adobe Experience Manager Performance und Magnolia CMS Performance.
Wie der Wert im Feld aussieht
Im DACH-Raum liegen 80,5 Prozent der AEM-Auftritte und 77,7 Prozent der Magnolia-Auftritte mobil im grünen Bereich, 4,7 beziehungsweise 0,7 Prozent im roten. Die vollständige Verteilung mit Datensätzen zum Nachrechnen steht im Core Web Vitals Benchmark.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen, welcher der vier Abschnitte bei Ihnen den Ausschlag gibt.
Häufige Fragen zu Largest Contentful Paint
Was misst Largest Contentful Paint?
Den Zeitpunkt, zu dem das größte sichtbare Element im Sichtfeld fertig gezeichnet ist, gerechnet ab dem Beginn des Seitenaufrufs. Meist ist das ein Titelbild, ein Hintergrundbild oder ein großer Textblock. Gut sind 2,5 Sekunden im 75. Perzentil, schlecht ist alles über 4 Sekunden.
Aus welchen Teilen besteht der Wert?
Aus vier Abschnitten: der Antwortzeit des Servers, der Verzögerung bis zum Ladebeginn der Ressource, ihrer Ladedauer und der Zeit bis zum Zeichnen. Ohne diese Aufteilung ist jede Maßnahme geraten. Liegt der größte Anteil im ersten Abschnitt, hilft kein Bildformat der Welt.
Wie hoch darf die Antwortzeit des Servers sein?
Google nennt 800 Millisekunden als Orientierung für Time to First Byte. In der eigenen Erhebung liegt der Median bei 666 Millisekunden über alle AEM-Auftritte, bei den zu langsamen Auftritten dagegen bei 1.565 Millisekunden. Der Unterschied zeigt, wo die Arbeit beginnt.
Hilft verzögertes Laden gegen schlechte Werte?
Für alles unterhalb des sichtbaren Bereichs ja, für das Bild, das den Wert bestimmt, nein. Ein verzögert geladenes Titelbild verschlechtert die Ladezeit des Hauptinhalts, weil der Browser erst nach dem Layout erfährt, dass er es braucht. Dieses eine Bild gehört bevorzugt geladen, alle anderen verzögert.
Warum ist der Wert auf Mobilgeräten schlechter?
Wegen schmalerer Verbindungen, schwächerer Geräte und häufig größerer Bilder im Verhältnis zur Fläche. In der eigenen Erhebung liegt der Median mobil bei 1.874 Millisekunden gegenüber 1.446 Millisekunden auf dem Desktop.