Früher war es für Webentwickler schwierig zu messen, wie schnell der Hauptinhalt einer Webseite geladen wird und für Nutzer sichtbar ist. Ältere Messwerte wie load oder DOMContentLoaded funktionieren nicht gut, da sie nicht unbedingt mit dem übereinstimmen, was der Nutzer auf dem Bildschirm sieht. Und neuere, nutzerorientierte Leistungsmesswerte wie First Contentful Paint (FCP) erfassen nur den ganz zu Beginn des Ladevorgangs. Wenn eine Seite einen Ladebildschirm oder eine Ladeanzeige zeigt, ist dieser Moment für den Nutzer nicht sehr relevant.
In der Vergangenheit haben wir Leistungsmesswerte wie First Meaningful Paint (FMP) und Speed Index (SI) (beide in Lighthouse verfügbar) empfohlen, um nach der Erstmalung mehr vom Ladeprozess zu erfassen. Diese Messwerte sind jedoch komplex, schwer zu erklären und oft falsch, sodass sie immer noch nicht erkennen, wann der Hauptinhalt der Seite geladen wurde.
Auf der Grundlage von Diskussionen in der W3C Web Performance Working Group und bei Google durchgeführten Untersuchungen haben wir herausgefunden, dass sich genauer messen lässt, wann der Hauptinhalt einer Seite geladen wird, indem wir uns ansehen, wann das größte Element gerendert wurde.
Was ist LCP?
Der LCP gibt die Renderingzeit des größten sichtbaren Bildes oder Textblocks im Darstellungsbereich an, und zwar in Relation zu dem Zeitpunkt, an dem der Nutzer zum ersten Mal die Seite aufgerufen hat.
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 für die meisten Nutzer erreichen, sollten Sie das 75. Perzentil der Seitenaufbauvorgänge, aufgeschlüsselt nach Mobilgeräten und Desktop-Geräten, messen.
Welche Elemente werden berücksichtigt?
Wie derzeit in der Largest Contentful Paint API angegeben, werden für Largest Contentful Paint folgende Elementtypen berücksichtigt:
<img>-Elemente (für animierte Inhalte wie GIFs oder animierte PNGs wird die Zeit für die Präsentation im ersten Frame verwendet)<image>-Elemente innerhalb eines<svg>-Elements<video>-Elemente: Es wird die Ladezeit des Posterbilds oder die Zeit der Präsentation im ersten Frame für Videos verwendet – je nachdem, was früher eintritt.- Ein Element mit einem Hintergrundbild, das mithilfe der Funktion
url()geladen wird (im Gegensatz zu einem CSS-Farbverlauf) - Elemente auf Blockebene, die Textknoten oder andere untergeordnete Textelemente auf Inline-Ebene enthalten.
Beachte, dass die Beschränkung der Elemente auf diese begrenzte Menge beabsichtigt war, um die Dinge am Anfang einfach zu halten. In Zukunft können weitere Elemente (wie die vollständige <svg>-Unterstützung) hinzugefügt werden, wenn weitere Studien durchgeführt werden.
Bei LCP-Messungen werden nicht nur einige Elemente berücksichtigt, sondern auch Heuristiken eingesetzt, um bestimmte Elemente auszuschließen, die Nutzer wahrscheinlich als „nicht inhaltlich“ einstufen. Für Chromium-basierte Browser sind das die folgenden:
- Elemente mit der Deckkraft 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 einer niedrigen Entropie, die wahrscheinlich nicht den tatsächlichen Inhalt der Seite widerspiegeln
Die Browser werden diese Heuristik wahrscheinlich weiter verbessern, um sicherzustellen, dass wir den Erwartungen der Nutzer gerecht werden, welches das größte inhaltsbezogene Element ist.
Diese „inhaltsbezogenen“ Heuristiken können sich von denen von First Contentful Paint (FCP) unterscheiden, bei denen möglicherweise einige dieser Elemente berücksichtigt werden, z. B. Platzhalterbilder oder Bilder mit vollständigem Darstellungsbereich, auch wenn sie sich nicht als LCP-Kandidaten eignen. Obwohl beide „contentful“ in ihrem Namen verwendet werden, haben diese Messwerte ein anderes Ziel. FCP misst, ob Inhalte auf dem Bildschirm dargestellt werden, und LCP, wenn der Hauptinhalt dargestellt wird, damit der LCP selektiver ist.
Wie wird die Größe eines Elements bestimmt?
Die Größe des für den 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 oder ein Element abgeschnitten ist oder einen nicht sichtbaren overflow aufweist, werden diese Teile nicht auf die Größe des Elements angerechnet.
Bei Bildelementen, deren Größe von ihrer systeminternen Größe aus angepasst wurde, wird entweder die sichtbare Größe oder die ursprüngliche Größe gemeldet, je nachdem, welcher Wert kleiner ist.
Bei Textelementen berücksichtigt LCP nur das kleinste Rechteck, das alle Textknoten enthalten kann.
Beim LCP werden Ränder, Abstände und Rahmen, die mit CSS angewendet wurden, nicht für alle Elemente berücksichtigt.
Wann wird der LCP gemeldet?
Webseiten werden oft stufenweise geladen. Daher ist es möglich, dass sich das größte Element auf der Seite ändert.
Um dieses Änderungspotenzial zu bewältigen, gibt der Browser ein PerformanceEntry vom Typ largest-contentful-paint aus und identifiziert das größte inhaltsbezogene Element, sobald der Browser den ersten Frame gerendert hat. Nach dem Rendern der nachfolgenden Frames wird jedoch jedes Mal ein weiteres PerformanceEntry gesendet, wenn sich die größten inhaltsbezogenen Elementänderungen ändern.
Beispielsweise kann der Browser auf einer Seite mit Text und einem Hero-Image erst den Text rendern. Danach sendet der Browser einen largest-contentful-paint-Eintrag, dessen element-Eigenschaft wahrscheinlich auf <p> oder <h1> verweisen würde. Sobald das Hero-Image fertig geladen ist, wird ein zweiter largest-contentful-paint-Eintrag gesendet und seine element-Eigenschaft würde auf die <img> verweisen.
Ein Element kann erst als das größte inhaltsbezogene Element betrachtet werden, nachdem es gerendert wurde und für den Nutzer sichtbar ist. Bilder, die noch nicht geladen wurden, gelten nicht als „gerendert“. Während des Schriftblocks verwenden Textknoten auch keine Webschriftarten. In solchen Fällen wird ein kleineres Element möglicherweise als das größte inhaltsbezogene Element gemeldet. Sobald das größere Element aber gerendert wurde, wird ein weiteres PerformanceEntry-Element erstellt.
Neben dem verspäteten Laden von Bildern und Schriftarten kann eine Seite dem DOM auch neue Elemente hinzufügen, wenn neue Inhalte verfügbar sind. Ist eines dieser neuen Elemente größer als das vorherige, größte inhaltsbezogene Element, wird auch ein neues PerformanceEntry gemeldet.
Wenn das größte inhaltsbezogene Element aus dem Darstellungsbereich oder sogar aus dem DOM entfernt wird, bleibt es das größte inhaltsbezogene Element, sofern kein größeres Element gerendert wird.
Der Browser meldet keine neuen Einträge mehr, sobald der Nutzer durch Tippen, Scrollen oder Tastendruck mit der Seite interagiert, da sich durch diese Interaktion häufig der für den Nutzer sichtbare Bereich ändert. Dies gilt insbesondere beim Scrollen.
Zu Analysezwecken sollten Sie nur die zuletzt gesendeten PerformanceEntry an Ihren Analysedienst melden.
Ladezeit im Vergleich zur Renderingzeit
Aus Sicherheitsgründen wird der Zeitstempel des Renderings von Bildern bei ursprungsübergreifenden Bildern ohne Timing-Allow-Origin-Header nicht angezeigt. Stattdessen wird nur die Ladezeit angezeigt, da diese bereits über viele andere Web-APIs sichtbar ist.
Dies kann zu einer scheinbar unmöglichen Situation führen, in der LCP von Web-APIs noch früher als FCP gemeldet wird. Dies ist nicht der Fall, sondern erscheint nur aufgrund dieser Sicherheitsbeschränkung.
Nach Möglichkeit wird immer empfohlen, den Header Timing-Allow-Origin festzulegen, damit Ihre Messwerte genauer sind.
Wie werden Layout- und Größenänderungen von Elementen gehandhabt?
Um den Leistungsaufwand bei der Berechnung und Weiterleitung neuer Leistungseinträge gering zu halten, werden bei Änderungen an der Größe oder Position eines Elements keine neuen LCP-Kandidaten generiert. Es wird nur die anfängliche Größe und Position des Elements im Darstellungsbereich berücksichtigt.
Daher werden Bilder, die zuerst außerhalb des Bildschirms gerendert und dann auf dem Bildschirm übergehen, möglicherweise nicht gemeldet. Das bedeutet auch, dass für Elemente, die ursprünglich im Darstellungsbereich gerendert und dann nach unten verschoben werden, weiterhin ihre ursprüngliche Größe im Darstellungsbereich erfasst werden.
Beispiele
Hier sind einige Beispiele für den Fall, dass der Largest Contentful Paint auf einigen beliebten Websites auftritt:
In beiden Zeitachsen oben ändert sich das größte Element, wenn der Inhalt geladen wird. Im ersten Beispiel wird neuer Inhalt zum DOM hinzugefügt, wodurch sich ändert, welches Element das größte ist. Im zweiten Beispiel wird das Layout geändert und Inhalte, die zuvor am größten waren, aus dem Darstellungsbereich entfernt.
Zwar kommt es häufig vor, dass der Content, der spät geladen wird, größer ist als der Content, der bereits auf der Seite vorhanden ist. Dies ist jedoch nicht unbedingt der Fall. Die nächsten beiden Beispiele zeigen den LCP, bevor die Seite vollständig geladen wurde.
Im ersten Beispiel wird das Instagram-Logo relativ früh geladen und bleibt das größte Element, auch wenn andere Inhalte nach und nach gezeigt werden. Auf der Google-Suchergebnisseite ist das größte Element ein Textabsatz, der angezeigt wird, bevor Bilder oder Logos vollständig geladen sind. Da alle einzelnen Bilder kleiner als dieser Absatz sind, bleibt es während des gesamten Ladevorgangs das größte Element.
LCP messen
Der LCP kann im Labor oder vor Ort gemessen werden und ist in folgenden Tools verfügbar:
Außendienst-Tools
- Bericht zur Nutzererfahrung in Chrome
- PageSpeed Insights
- Search Console (Core Web Vitals-Bericht)
web-vitals-JavaScript-Bibliothek
Lab-Tools
LCP in JavaScript messen
Zur Messung des LCP in JavaScript können Sie die Largest Contentful Paint API verwenden. Das folgende Beispiel zeigt, wie Sie einen PerformanceObserver erstellen, der largest-contentful-paint-Einträge überwacht und in der Konsole 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 stellt jeder protokollierte largest-contentful-paint-Eintrag den aktuellen LCP-Kandidaten dar. Im Allgemeinen ist der Wert startTime des letzten ausgegebenen Eintrags der LCP-Wert. Das 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 Informationen in der API und der Berechnung des Messwerts aufgeführt.
Unterschiede zwischen Messwert und 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 werden möglicherweise nur berücksichtigt, 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 aber in diesen Fällen gemessen werden, da sie für Nutzer als separate Seitenaufrufe empfunden werden. - Die API berücksichtigt keine Elemente in iFrames, der Messwert hingegen schon, da sie Teil der Nutzererfahrung auf der Seite sind. Auf Seiten mit einem LCP in einem iFrame, z. B. einem Posterbild in einem eingebetteten Video, wird dies als Unterschied zwischen CrUX und RUM angezeigt. Um den LCP-Wert korrekt zu messen, sollten Sie sie 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 vor gerenderte Seiten sollte der LCP jedoch ab
activationStartgemessen werden, da dies der vom Nutzer wahrgenommenen LCP-Zeit entspricht.
Anstatt sich all die subtilen Unterschiede zu merken, können Entwickler die web-vitals-JavaScript-Bibliothek verwenden, um den LCP-Wert zu messen, der diese Unterschiede für Sie handhabt (sofern möglich – beachten Sie, dass das iFrame-Problem nicht abgedeckt wird):
import {onLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
onLCP(console.log);
Im Quellcode für onLCP() findest du ein vollständiges Beispiel für die Messung des LCP in JavaScript.
Was ist, wenn das größte Element nicht das wichtigste ist?
In einigen Fällen sind das wichtigste Element (oder die wichtigsten Elemente) auf der Seite nicht dasselbe wie das größte Element. Daher sind Entwickler möglicherweise eher daran interessiert, die Rendering-Zeiten dieser anderen Elemente zu messen. Dies ist mit der Element Timing API möglich, wie im Artikel zu benutzerdefinierten Messwerten beschrieben.
LCP verbessern
In einem umfassenden Leitfaden zur LCP-Optimierung finden Sie eine Anleitung, wie Sie LCP-Zeitangaben vor Ort ermitteln und anhand der Labdaten diese aufschlüsseln und optimieren.
Zusätzliche Ressourcen
- Lessons Learned from Performance Monitoring in Chrome von Annie Sullivan bei performance.now() (2019)
Änderungsprotokoll
Gelegentlich werden Fehler in den APIs entdeckt, die zum Messen von Messwerten verwendet werden, und manchmal in den Definitionen der Messwerte selbst. Aus diesem Grund müssen gelegentlich Änderungen vorgenommen werden, die sich in Ihren internen Berichten und Dashboards als Verbesserungen oder Regressionen zeigen lassen.
Alle Änderungen an der Implementierung oder an der Definition dieser Messwerte werden in diesem Änderungsprotokoll angezeigt.
Wenn du Feedback zu diesen Messwerten hast, kannst du es in der Google-Gruppe „web-vitals-feedback“ einreichen.