Largest Contentful Paint (LCP)

Philip Walton

Barry Pollard

In der Vergangenheit war es für Webentwickler eine Herausforderung, zu messen, wie schnell der Hauptinhalt einer Webseite geladen und für Nutzer sichtbar ist. Ältere Messwerte wie load oder DOMContentLoaded eignen sich nicht gut, da sie nicht unbedingt dem entsprechen, was der Nutzer auf seinem Bildschirm sieht. Und neuere, nutzerorientierte Leistungsmesswerte wie First Contentful Paint (FCP) erfassen erst den Anfang des Ladevorgangs. Wenn auf einer Seite ein Startbildschirm oder ein Ladebalken angezeigt wird, ist dieser Moment für den Nutzer nicht sehr relevant.

Bisher haben wir Leistungsmesswerte wie First Meaningful Paint (FMP) und Speed Index (SI) (beide in Lighthouse verfügbar) empfohlen, um einen größeren Teil des Ladevorgangs nach dem ersten Paint zu erfassen. Diese Messwerte sind jedoch komplex, schwer zu erklären und oft falsch. Sie können also immer noch nicht erkennen, wann der Hauptinhalt der Seite geladen wurde.

Basierend auf Diskussionen in der W3C Web Performance Working Group und Studien von Google haben wir festgestellt, dass es genauer ist, zu messen, wann das größte Element gerendert wird, um zu ermitteln, wann der Hauptinhalt einer Seite geladen ist.

Was ist LCP?

Der LCP meldet die Renderingzeit des größten Bilds, Textblocks oder Videos, das im Darstellungsbereich sichtbar ist, bezogen auf den Zeitpunkt, zu dem der Nutzer die Seite zum ersten Mal aufgerufen hat.

Was ist ein guter LCP-Wert?

Für eine gute Nutzerfreundlichkeit sollten Websites einen Largest Contentful Paint von 2,5 Sekunden oder weniger anstreben. Damit Sie dieses Ziel für die meisten Nutzer erreichen, ist der 75. Perzentilwert der Seitenladezeiten, segmentiert nach Mobilgeräten und Computern, ein guter Messwert.

<ph type="x-smartling-placeholder"></ph>

Welche Elemente werden berücksichtigt?

Derzeit werden in der Largest Contentful Paint API die folgenden Elementtypen für Largest Contentful Paint berücksichtigt:

• <img>-Elemente (die Präsentationszeit des ersten Frames wird für animierte Inhalte wie GIFs oder animierte PNGs verwendet)
• <image>-Elemente innerhalb eines <svg>-Elements
• <video>-Elemente (die Ladezeit des Posterbilds oder die Darstellungszeit des ersten Frames für Videos, je nachdem, was früher eintritt)
• Ein Element mit einem Hintergrundbild, das mit der Funktion url() geladen wird (im Gegensatz zu einem CSS-Gradienten)
• Elemente auf Blockebene, die Textknoten oder andere untergeordnete Textelemente auf Inline-Ebene enthalten.

Die Beschränkung der Elemente auf diese begrenzte Menge war beabsichtigt, um die Dinge am Anfang einfach zu halten. Weitere Elemente (z. B. der vollständige <svg>-Support) werden möglicherweise im Laufe der Zeit hinzugefügt, wenn weitere Studien durchgeführt werden.

Bei LCP-Messungen werden nicht nur bestimmte Elemente berücksichtigt, sondern auch bestimmte Elemente mithilfe von Heuristiken ausgeschlossen, die Nutzer wahrscheinlich als „inhaltslos“ empfinden. Für Chromium-basierte Browser:

• Elemente mit einer Deckkraft von 0, die für den Nutzer nicht sichtbar sind
• Elemente, die den gesamten Darstellungsbereich abdecken und wahrscheinlich als Hintergrund und nicht als Inhalt betrachtet werden
• Platzhalterbilder oder andere Bilder mit geringer Entropie, die wahrscheinlich nicht den tatsächlichen Inhalt der Seite widerspiegeln

Browser werden diese Heuristiken wahrscheinlich weiter verbessern, um den Erwartungen der Nutzer an das größte contentful-Element gerecht zu werden.

Diese „inhaltlichen“ Heuristiken können sich von denen unterscheiden, die für First Contentful Paint (FCP) verwendet werden. Dabei werden einige dieser Elemente, z. B. Platzhalterbilder oder Bilder im Vollansichtsbereich, möglicherweise berücksichtigt, auch wenn sie nicht als LCP-Kandidaten infrage kommen. Obwohl beide Messwerte den Begriff „aussagekräftig“ im Namen tragen, haben sie unterschiedliche Ziele. Der FCP gibt an, wann Inhalte auf dem Bildschirm dargestellt werden, der LCP, wann die Hauptinhalte dargestellt werden. Der LCP ist also selektiver.

Wie wird die Größe eines Elements bestimmt?

Die Größe des Elements, die für LCP erfasst wird, entspricht in der Regel der Größe, die für den Nutzer im Darstellungsbereich sichtbar ist. Wenn sich das Element über den Darstellungsbereich hinaus erstreckt, Elemente abgeschnitten haben oder einen nicht sichtbaren Überlauf aufweisen, werden diese Teile nicht auf die Größe des Elements angerechnet.

Bei Bildelementen, deren Größe von der ursprünglichen Größe geändert wurde, wird die Größe gemeldet, die entweder kleiner ist als die sichtbare Größe oder als die ursprüngliche Größe.

Bei Textelementen berücksichtigt LCP nur das kleinste Rechteck, das alle Textknoten enthalten kann.

Der LCP berücksichtigt nicht für alle Elemente Ränder, Abstände oder Rahmen, die mithilfe von CSS angewendet wurden.

Wann wird der LCP erfasst?

Webseiten werden häufig in Phasen geladen. Daher kann sich das größte Element auf der Seite ändern.

Um diesem Änderungspotenzial zu begegnen, sendet der Browser ein PerformanceEntry vom Typ largest-contentful-paint, das das größte Inhaltselement identifiziert, sobald der Browser den ersten Frame gezeichnet hat. Nach dem Rendern der nachfolgenden Frames wird dann jedoch ein weiteres PerformanceEntry ausgelöst, wenn sich die größten inhaltsbezogenen Elemente ändern.

Auf einer Seite mit Text und einem Hero-Image rendert der Browser beispielsweise möglicherweise zuerst nur den Text. In diesem Fall sendet der Browser einen largest-contentful-paint-Eintrag, dessen element-Eigenschaft wahrscheinlich auf eine <p> oder <h1> verweist. Sobald das Hero-Image fertig geladen ist, wird ein zweiter largest-contentful-paint-Eintrag gesendet und die Property element würde auf <img> verweisen.

Ein Element gilt erst als größte Inhaltselement, nachdem es gerendert wurde und für den Nutzer sichtbar ist. Bilder, die noch nicht geladen wurden, gelten nicht als „gerendert“. Während des Schriftblockzeitraums werden auch keine Textknoten verwendet, die Webschriftarten verwenden. In solchen Fällen wird möglicherweise ein kleineres Element als größtes Element mit Inhalt gemeldet. Sobald das größere Element jedoch fertig gerendert ist, wird ein weiterer PerformanceEntry-Wert erstellt.

Neben Bildern und Schriftarten, die erst später geladen werden, kann einer Seite auch neues DOM-Element hinzugefügt werden, sobald neue Inhalte verfügbar sind. Wenn eines dieser neuen Elemente größer ist als das vorherige größte Inhaltselement, wird auch ein neues PerformanceEntry gemeldet.

Wenn das größte Inhaltselement aus dem Darstellungsbereich oder sogar aus dem DOM entfernt wird, bleibt es das größte Inhaltselement, sofern kein größeres Element gerendert wird.

Der Browser meldet keine neuen Einträge mehr, sobald der Nutzer mit der Seite interagiert (z. B. durch Tippen, Scrollen oder Drücken einer Taste), da sich durch die Nutzerinteraktion häufig ändert, was für den Nutzer sichtbar ist. Das gilt insbesondere beim Scrollen.

Zu Analysezwecken sollten Sie nur die zuletzt gesendeten PerformanceEntry an Ihren Analysedienst senden.

Ladezeit und Renderingzeit

Aus Sicherheitsgründen wird der Renderingzeitstempel von Bildern für ursprungsübergreifende Bilder ohne den Header Timing-Allow-Origin nicht verfügbar gemacht. Stattdessen wird nur die Ladezeit angegeben, da diese bereits über viele andere Web-APIs verfügbar ist.

Das kann zu der scheinbar unmöglichen Situation führen, dass der LCP von Web-APIs früher als der FCP gemeldet wird. Das ist nicht der Fall, sondern erscheint aufgrund dieser Sicherheitsbeschränkung nur so.

Nach Möglichkeit sollten Sie immer den Header Timing-Allow-Origin festlegen, damit Ihre Messwerte genauer sind.

Wie werden Änderungen am Layout und der Größe von Elementen gehandhabt?

Um den Leistungsaufwand für die Berechnung und den Versand neuer Leistungseinträge gering zu halten, generieren Änderungen an der Größe oder Position eines Elements keine neuen LCP-Kandidaten. Es wird nur die ursprüngliche Größe und Position des Elements im Darstellungsbereich berücksichtigt.

Das bedeutet, dass Bilder, die zuerst außerhalb des sichtbaren Bereichs gerendert und dann in den sichtbaren Bereich wechseln, möglicherweise nicht gemeldet werden. Außerdem wird für Elemente, die anfänglich im Darstellungsbereich gerendert und dann nach unten und außerhalb des sichtbaren Bereichs verschoben wurden, weiterhin ihre ursprüngliche Größe im Darstellungsbereich gemeldet.

Beispiele

Hier sind einige Beispiele dafür, wann der Largest Contentful Paint auf einigen beliebten Websites vorkommt:

In beiden Zeitleisten oben ändert sich das größte Element, während der Inhalt geladen wird. Im ersten Beispiel wird dem DOM neuer Inhalt hinzugefügt, wodurch sich das größte Element ändert. Im zweiten Beispiel werden die Layoutänderungen und der vorher größte Inhalt aus dem Darstellungsbereich entfernt.

Es ist zwar oft der Fall, dass Inhalte, die später geladen werden, größer sind als Inhalte, die bereits auf der Seite sind, aber das ist nicht unbedingt so. In den nächsten beiden Beispielen tritt die LCP auf, bevor die Seite vollständig geladen ist.

Im ersten Beispiel wird das Instagram-Logo relativ früh geladen und bleibt das größte Element, auch wenn andere Inhalte nach und nach angezeigt werden. Im Beispiel für die Google-Suchergebnisseite ist das größte Element ein Textabsatz, der angezeigt wird, bevor die Bilder oder das Logo vollständig geladen sind. Da alle einzelnen Bilder kleiner als dieser Absatz sind, bleibt es das größte Element während des Ladevorgangs.

LCP messen

LCP kann im Labor oder im Feld gemessen werden und ist in den folgenden Tools verfügbar:

Feldtools

• Bericht zur Nutzererfahrung in Chrome
• PageSpeed Insights
• Search Console (Core Web Vitals-Bericht)
• web-vitals JavaScript-Bibliothek

Lab-Tools

• Chrome-Entwicklertools
• Leuchtturm
• PageSpeed Insights
• WebPageTest

LCP in JavaScript messen

Wenn Sie LCP in JavaScript messen möchten, können Sie die Largest Contentful Paint API verwenden. Im folgenden Beispiel wird gezeigt, wie eine PerformanceObserver erstellt wird, die auf largest-contentful-paint-Einträge wartet und sie in der Console protokolliert.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Im obigen Beispiel steht jeder protokollierte largest-contentful-paint-Eintrag für den aktuellen LCP-Kandidaten. Im Allgemeinen ist der startTime-Wert des letzten ausgegebenen Eintrags der LCP-Wert. Dies ist jedoch nicht immer der Fall. Nicht alle largest-contentful-paint-Einträge sind für die Messung des LCP gültig.

Im folgenden Abschnitt werden die Unterschiede zwischen den Angaben in der API und der Berechnung des Messwerts aufgeführt.

Unterschiede zwischen dem Messwert und der API

• Die API sendet largest-contentful-paint-Einträge für Seiten, die in einem Hintergrundtab geladen werden. Diese Seiten sollten bei der Berechnung der LCP jedoch ignoriert werden.
• Die API sendet weiterhin largest-contentful-paint-Einträge, nachdem eine Seite im Hintergrund ausgeführt wurde. Diese Einträge sollten jedoch bei der Berechnung des LCP ignoriert werden. Elemente können nur berücksichtigt werden, wenn sich die Seite die ganze Zeit im Vordergrund befand.
• Die API meldet keine largest-contentful-paint-Einträge, wenn die Seite aus dem Zurück-/Vorwärts-Cache wiederhergestellt wird. LCP sollte in diesen Fällen jedoch gemessen werden, da Nutzer sie als separate Seitenaufrufe wahrnehmen.
• Die API berücksichtigt keine Elemente in iFrames, der Messwert jedoch schon, da sie Teil der Nutzererfahrung der Seite sind. Auf Seiten mit einem LCP innerhalb eines iFrames, z. B. einem Posterbild in einem eingebetteten Video, wird dies als Unterschied zwischen CrUX und RUM angezeigt. Sie sollten sie zur richtigen Messung des LCP berücksichtigen. Subframes können die API verwenden, um ihre largest-contentful-paint-Einträge zur Aggregation an den übergeordneten Frame zu melden.
• Die API misst den LCP ab Beginn der Navigation. Für vorgerenderte Seiten sollte der LCP jedoch ab activationStart gemessen werden, da dies der vom Nutzer erfassten LCP-Zeit entspricht.

Anstatt sich all diese kleinen Unterschiede zu merken, können Entwickler die web-vitalsJavaScript-Bibliothek verwenden, um die LCP zu messen. Diese Bibliothek berücksichtigt diese Unterschiede nach Möglichkeit (das Problem mit Iframes wird jedoch nicht abgedeckt):

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

Im Quellcode für onLCP() finden Sie ein vollständiges Beispiel für die Messung von LCP in JavaScript.

Was ist, wenn das größte Element nicht das wichtigste ist?

In einigen Fällen sind die wichtigsten Elemente auf der Seite nicht mit dem größten Element identisch. Entwickler sind möglicherweise eher daran interessiert, die Renderzeiten dieser anderen Elemente zu messen. Dies ist mit der Element Timing API möglich, wie im Artikel zu benutzerdefinierten Messwerten beschrieben.

LCP verbessern

Es steht ein vollständiger Leitfaden zur LCP-Optimierung zur Verfügung, der Sie durch die Ermittlung des LCP-Timings vor Ort und die Verwendung von Lab-Daten zur Aufschlüsselung und Optimierung der LCP-Werte führt.

Zusätzliche Ressourcen

• Lessons learned from performance monitoring in Chrome von Annie Sullivan auf performance.now() (2019)

Änderungsprotokoll

Gelegentlich werden Fehler in den APIs gefunden, die zum Erfassen von Messwerten verwendet werden, und manchmal auch in den Definitionen der Messwerte selbst. Daher müssen manchmal Änderungen vorgenommen werden. Diese Änderungen können sich in Ihren internen Berichten und Dashboards als Verbesserungen oder Rückschritte zeigen.

Alle Änderungen an der Implementierung oder der Definition dieser Messwerte werden in diesem Änderungsprotokoll veröffentlicht, um Ihnen die Verwaltung zu erleichtern.

Wenn Sie Feedback zu diesen Messwerten haben, können Sie es in der Google-Gruppe „web-vitals-feedback“ geben.