<ph type="x-smartling-placeholder">
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 funktionieren weniger gut, weil 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 Ladebildschirm oder eine Ladeanzeige eingeblendet wird, ist dieser Moment für den Nutzer nicht 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.
Laut Diskussionen der W3C-Arbeitsgruppe für Web-Performance und Untersuchungen von Google haben wir herausgefunden, dass sich genauer messen lässt, wann der Hauptinhalt einer Seite geladen wird, wenn man sich ansehen kann, wann das größte Element gerendert wird.
Was ist LCP?
Der LCP meldet die Renderingzeit des größten Bild- oder Textblocks, der im Darstellungsbereich sichtbar war, bezogen auf den Zeitpunkt, zu dem der Nutzer zum ersten Mal die Seite aufruft.
<ph type="x-smartling-placeholder">Was ist ein guter LCP-Wert?
Für eine gute Nutzerfreundlichkeit sollten Websites eine Largest Contentful Paint von 2, 5 Sekunden oder weniger anstreben. Damit Sie dieses Ziel bei den meisten Nutzern erreichen, eignet sich zur Messung das 75. Perzentil der Seitenaufbauvorgänge, segmentiert nach Mobil- und Desktopgeräten.
<ph type="x-smartling-placeholder">Welche Elemente werden berücksichtigt?
Wie derzeit in der Tabelle Largest Contentful Paint angegeben API, werden die Elementtypen für Largest Contentful Paint infrage kommen:
<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 Präsentationszeit des ersten Frames bei Videos wird verwendet – je nachdem, was früher ist)- Ein Element mit einem Hintergrundbild, das mit der Funktion
url()
geladen wird (im Gegensatz zu einem CSS-Farbverlauf) - Elemente auf Blockebene, die Textknoten oder andere untergeordnete Textelemente auf Inline-Ebene enthalten.
Die Beschränkung der Elemente auf diese begrenzte Anzahl von Elementen war beabsichtigt, um die Dinge am Anfang einfach zu halten. Weitere Elemente wie der vollständige <svg>
-Support können im Laufe der Zeit hinzukommen, wenn weitere Studien durchgeführt werden.
Bei LCP-Messungen werden nicht nur einige Elemente berücksichtigt, sondern auch bestimmte Elemente, die Nutzer wahrscheinlich als „nicht inhaltsbezogen“ empfinden, anhand von Heuristiken ausgeschlossen. 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 angesehen werden
- Platzhalterbilder oder andere Bilder mit niedriger Entropie, die wahrscheinlich nicht den tatsächlichen Inhalt der Seite widerspiegeln
Browser werden diese Heuristiken wahrscheinlich weiter verbessern, damit wir den Erwartungen der Nutzer an das größte contentful-Element gerecht werden.
Diese „konstruktiven“ Heuristiken können sich von denen unterscheiden, die von First Contentful Paint (FCP) verwendet werden. Hier werden möglicherweise einige dieser Elemente wie Platzhalterbilder oder Bilder des vollständigen Darstellungsbereichs berücksichtigt, auch wenn sie nicht als LCP-Kandidaten infrage kommen. Obwohl beide „contentful“ im Namen enthalten, ist das Ziel dieser Metriken ein anderes. Beim FCP wird gemessen, wann alle Inhalte auf dem Bildschirm dargestellt werden, und der LCP, wenn der Hauptinhalt dargestellt wird. Der LCP soll daher selektiver sein.
Wie wird die Größe eines Elements bestimmt?
Die Größe des für LCP gemeldeten Elements ist in der Regel die 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 ausgehend von ihrer systemeigenen Größe geändert wurde, wird entweder die sichtbare Größe oder die intrinsische Größe gemeldet – je nachdem, welche Größe kleiner ist.
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.
<ph type="x-smartling-placeholder">Wann wird der LCP gemeldet?
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 kann der Browser beispielsweise anfangs nur den Text rendern. An diesem Punkt löst der Browser einen largest-contentful-paint
-Eintrag aus, dessen element
-Eigenschaft wahrscheinlich auf ein <p>
oder <h1>
verweisen würde. 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 kann erst als größtes Inhaltselement betrachtet werden, nachdem es gerendert wurde und für den Nutzer sichtbar ist. Bilder, die noch nicht geladen wurden, werden nicht als „gerendert“ betrachtet. Während des Schriftblockzeitraums werden auch keine Textknoten verwendet, die Webschriftarten verwenden. In solchen Fällen kann ein kleineres Element als größtes inhaltsorientiertes Element gemeldet werden. Sobald das größere Element jedoch vollständig gerendert wurde, wird ein weiteres PerformanceEntry
-Element erstellt.
Neben den spät geladenen Bildern und Schriftarten kann eine Seite dem DOM neue Elemente hinzufügen, 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.
<ph type="x-smartling-placeholder">Der Browser meldet keine neuen Einträge mehr, sobald der Nutzer per Tippen, Scrollen oder Tastendruck mit der Seite interagiert. Dies liegt daran, dass durch die Nutzerinteraktion häufig verändert wird, was für den Nutzer sichtbar ist, was besonders beim Scrollen der Fall ist.
Zu Analysezwecken sollten Sie nur die zuletzt gesendeten PerformanceEntry
an Ihren Analysedienst melden.
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 offengelegt, da diese bereits über viele andere Web-APIs verfügbar ist.
Dies kann dazu führen, dass der LCP von Web-APIs früher als FCP gemeldet wird. Das kann scheinbar unmöglich erscheinen. Das ist nicht der Fall, sondern erscheint aufgrund dieser Sicherheitsbeschränkung nur so.
Wenn möglich, sollten Sie immer die Timing-Allow-Origin
-Kopfzeile festlegen, damit Ihre Messwerte präziser 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 Bildschirms gerendert werden und dann auf dem Bildschirm übergehen, 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:
<ph type="x-smartling-placeholder">![Largest Contentful Paint-Zeitachse von cnn.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-fc43128e011aa.png?authuser=6&hl=de)
![Largest Contentful Paint-Zeitachse von techcrunch.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-3713e2f14970a.png?authuser=6&hl=de)
In beiden Zeitachsen ändert sich das größte Element, wenn der Inhalt geladen wird. Im ersten Beispiel werden neue Inhalte zum DOM 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 kommt zwar häufig vor, dass zu spät ladender Content größer ist als der bereits auf der Seite vorhandene Content. Dies muss jedoch nicht unbedingt der Fall sein. Die nächsten beiden Beispiele zeigen den LCP, der vor dem vollständigen Laden der Seite erfolgt.
<ph type="x-smartling-placeholder">![Largest Contentful Paint-Zeitachse von instagram.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-9bc403e812154.png?authuser=6&hl=de)
![Largest Contentful Paint-Zeitachse von google.com](https://web.dev/static/articles/lcp/image/largest-contentful-paint-6c5554de0eac7.png?authuser=6&hl=de)
Im ersten Beispiel wird das Instagram-Logo relativ früh geladen und bleibt das größte Element, auch wenn andere Inhalte nach und nach eingeblendet werden. Im Beispiel der Google-Suchergebnisseite ist das größte Element ein Absatz mit Text, der angezeigt wird, bevor das Bild oder das Logo vollständig geladen wurde. Da alle einzelnen Bilder kleiner als dieser Absatz sind, bleibt es das größte Element während des Ladevorgangs.
<ph type="x-smartling-placeholder">LCP messen
Der LCP kann im Labor oder im Feld gemessen werden und ist in den folgenden Tools verfügbar:
Feld-Tools
- Bericht zur Nutzererfahrung in Chrome
- PageSpeed Insights
- Search Console (Core Web Vitals-Bericht)
web-vitals
-JavaScript-Bibliothek
Lab-Tools
LCP in JavaScript messen
Zum Messen des LCP in JavaScript können Sie die Largest Contentful Paint API verwenden. Das folgende Beispiel zeigt, wie Sie eine PerformanceObserver
erstellen, die largest-contentful-paint
-Einträge überwacht und 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 API-Berichten 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 Hintergrund-Tab geladen werden. Diese Seiten sollten jedoch bei der Berechnung des LCP 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 Back-Forward-Cache wiederhergestellt wird. Der LCP sollte in diesen Fällen jedoch gemessen werden, da die Nutzer sie als separate Seitenaufrufe erleben. - 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 feinen Unterschiede zu merken, können Entwickler den LCP mithilfe der web-vitals
-JavaScript-Bibliothek messen. Dort werden diese Unterschiede für Sie behoben (wo möglich – das Problem mit den iFrames wird nicht behandelt):
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, 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 und Entwickler sind möglicherweise eher daran interessiert, die Renderingzeiten 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 performancemonitoring in Chrome von Annie Sullivan bei performance.now() (2019)
Änderungsprotokoll
Gelegentlich werden Fehler in den APIs, die zum Messen von Messwerten verwendet werden, und manchmal in den Definitionen der Messwerte selbst entdeckt. Daher müssen manchmal Änderungen vorgenommen werden, die sich als Verbesserungen oder Regressionen in Ihren internen Berichten und Dashboards zeigen können.
Alle Änderungen an der Implementierung oder der Definition dieser Messwerte werden in diesem Änderungsprotokoll veröffentlicht, um Ihnen die Verwaltung zu erleichtern.
In der Google-Gruppe „web-vitals-feedback“ können Sie uns Feedback zu diesen Messwerten geben.