Häufige Missverständnisse bezüglich der LCP-Optimierung

Die Verbesserung des Largest Contentful Paint (LCP) einer Seite kann schwierig sein, da häufig mehrere Teile und Kompromisse berücksichtigt werden müssen. In diesem Beitrag werden Felddaten aus echten Seitenladevorgängen im Web untersucht, um zu ermitteln, wo Entwickler ihre Optimierungsbemühungen konzentrieren sollten.

Bei den meisten Webseiten im Web ist das LCP-Element ein Bild. Es liegt also nahe, anzunehmen, dass das LCP am besten durch die Optimierung des LCP-Bildes verbessert werden kann.

In den etwa fünf Jahren seit der Einführung von LCP war das oft der wichtigste Rat. Achten Sie darauf, dass Ihre Bilder die richtige Größe haben und ausreichend komprimiert sind. Verwenden Sie am besten ein Bildformat des 21. Jahrhunderts. Lighthouse bietet sogar drei unterschiedliche Prüfungen, um diese Vorschläge zu machen.

Die drei Prüfungen zur Bildoptimierung in einem Lighthouse-Bericht
Die drei Prüfungen zur Bildoptimierung in einem Lighthouse-Bericht.

Ein Grund dafür, dass dieser Ratschlag so häufig gegeben wird, ist, dass zu viele Bytes leicht zu messen sind und Bildkomprimierungstools leicht zu empfehlen sind. Je nach Build- und Bereitstellungspipelines ist die Implementierung möglicherweise auch einfach.

Wenn ja, dann tun Sie es. Wenn Sie Ihren Nutzern weniger Bytes senden, ist das fast immer von Vorteil. Es gibt viele Websites im Web, auf denen immer noch unnötig große Bilder gesendet werden, die sich durch eine einfache Komprimierung beheben ließen.

Als wir uns jedoch die Leistungsdaten von Nutzern in Chrome ansahen, um herauszufinden, wo die Zeit bis zum LCP in der Regel vergeht, stellten wir fest, dass die Bilddownloadzeit fast nie das Nadelöhr ist.

Stattdessen sind andere Teile des LCP ein viel größeres Problem.

Aufschlüsselung der LCP-Unterelemente

Um herauszufinden, wo die größten Verbesserungsmöglichkeiten für den LCP liegen, haben wir uns die Daten der LCP-Unterelemente angesehen, wie unter LCP optimieren beschrieben.

Jede Seite und jedes Framework kann einen anderen Ansatz zum Laden und Darstellen des LCP-Elements der Seite haben. Sie lassen sich jedoch alle in die folgenden Teilbereiche unterteilen:

Aufschlüsselung des LCP in die vier Unterteile

Zitat aus diesem Artikel:

Zeit bis zum ersten Byte (TTFB)
Die Zeitspanne zwischen dem Start des Ladevorgangs der Seite durch den Nutzer und dem Empfang des ersten Bytes der Antwort des HTML-Dokuments durch den Browser.
Verzögerung beim Laden der Ressourcen
Die Zeit zwischen dem TTFB und dem Beginn des Ladens der LCP-Ressource durch den Browser. Wenn für das LCP-Element keine Ressourcen geladen werden müssen, um es zu rendern, ist diese Zeit 0.
Dauer des Ressourcenladevorgangs
Die Zeit, die zum Laden der LCP-Ressource selbst benötigt wird. Wenn für das LCP-Element keine Ressourcen geladen werden müssen, um es zu rendern, ist diese Zeit 0.
Verzögerung beim Rendering des Elements
Die Zeit zwischen dem Laden der LCP-Ressource und dem vollständigen Rendern des LCP-Elements.

Echte Daten zur Navigationsleistung

Ein Balkendiagramm, in dem die Unterschiede bei der Zeit, die in den einzelnen LCP-Unterabschnitten verbracht wurde, dargestellt werden. Die LCP-Kategorien „Gut“, „Verbesserung erforderlich“ und „Schlecht“ sind farblich hervorgehoben. TTFB und Ladezeit nehmen schnell zu, während die Ladedauer und die Rendering-Verzögerung kurz bleiben. Die Daten sind in der folgenden Tabelle aufgeführt.

LCP-Bewertung TTFB (ms) Verzögerung beim Laden von Bildern (ms) Ladezeit des Bildes (ms) Renderingverzögerung (ms)
Gut 600 350 160 230
Optimierung erforderlich 1.360 720 270 310
Schlecht 2.270 1.290 350 360

In diesem Beitrag haben wir Daten von Seitennavigationen mit einem LCP für Unterressourcen in Chrome verwendet, um uns die LCP-Unterteile anzusehen. Wir haben uns diese Art von Daten schon einmal angesehen, aber noch nie anhand von Felddaten, um zu sehen, wo echte Nutzer ihre Zeit verbringen, während sie auf die LCP einer Seite warten.

Wie bei den Core Web Vitals haben wir den 75. Perzentilwert (p75) jedes LCP-Teils für jeden Ursprung im CrUX-Datensatz ermittelt. Das führte zu vier Verteilungen von p75-Werten (eine für jeden Teil). Um diese Verteilungen zusammenzufassen, haben wir für jeden der vier LCP-Unterteile den Median dieser Werte über alle Ursprünge hinweg ermittelt.

Schließlich teilen wir die Ursprünge in Gruppen ein, je nachdem, ob sie beim 75. Perzentil eine gute, verbesserungswürdige oder schlechte LCP haben. So lässt sich besser erkennen, was einen Ursprung mit guter LCP von einem Ursprung mit schlechter LCP unterscheidet.

Größe des LCP-Bildes reduzieren? Diesmal mit Daten

Die Ladedauer gibt an, wie lange es dauert, bis die LCP-Ressource abgerufen wird, in diesem Fall ein Bild. Diese Zeit ist in der Regel proportional zur Anzahl der Bytes im Bild. Daher wird empfohlen, diese Anzahl zu reduzieren.

Wenn Sie sich ansehen, wofür in den vorherigen Diagrammen Zeit aufgewendet wird, fällt auf, dass die Bildladezeit nicht sehr lang ist. Tatsächlich ist es der kürzeste LCP-Unterabschnitt in allen LCP-Buckets. Die Ladedauer ist bei Ursprüngen mit schlechtem LCP länger als bei Ursprüngen mit gutem LCP. Dies ist jedoch nicht der Hauptgrund für die lange Ladezeit.

Bei der Mehrheit der Ursprünge mit schlechtem LCP wird weniger als 10% der LCP-Zeit von p75 für das Herunterladen des LCP-Bildes aufgewendet.

Ja, Sie sollten dafür sorgen, dass Ihre Bilder optimiert sind. Das ist aber nur ein Teil der Optimierung des LCP. Aus diesen Daten geht hervor, dass die potenziellen Millisekundengewinne für LCP bei typischen Web-Quellen insgesamt gering sind, unabhängig davon, wie ausgefeilt das Komprimierungsschema ist.

Eine letzte Überraschung: Langsame Ladezeiten wurden früher in der Regel auf Mobilgeräte und die Qualität von Mobilfunknetzen zurückgeführt. Früher hätte man vielleicht erwartet, dass es auf einem typischen Smartphone mehrmals länger dauert, dasselbe Bild herunterzuladen wie auf einem Desktop-Computer mit Kabelverbindung. Die Daten deuten darauf hin, dass das nicht mehr der Fall ist. Bei Ursprüngen mit schlechtem LCP ist die mediane p75-Bildladedauer auf Mobilgeräten nur 20% länger als auf Computern.

Zeit bis zum ersten Byte (TTFB)

Bei Navigationen, die eine Netzwerkanfrage auslösen, dauert der TTFB immer einige Zeit. Es dauert einige Zeit, bis ein DNS-Lookup durchgeführt und eine Verbindung hergestellt wird. Und die Physik lässt sich nicht austricksen: Eine Anfrage muss über Drähte und optische Kabel durch die reale Welt reisen, um einen Server zu erreichen, und dann muss die Antwort denselben Weg zurücklegen. Selbst der Medianwert der Ursprungsserver mit gutem LCP benötigt beim 75. Perzentil mehr als eine halbe Sekunde für die TTFB.

Die Unterschiede bei der TTFB zwischen den guten und schlechten LCP-Quellen zeigen jedoch Verbesserungsmöglichkeiten auf. Bei mindestens der Hälfte der Ursprünge mit schlechtem LCP ist es nahezu sicher, dass der p75-TTFB von 2.270 Millisekunden allein dafür sorgt, dass der p75-LCP nicht schneller als der Schwellenwert „gut“ von 2,5 Sekunden sein kann. Selbst eine moderate prozentuale Verringerung dieser Zeit würde eine erhebliche Verbesserung des LCP bedeuten.

Sie können die Physik vielleicht nicht besiegen, aber es gibt einige Dinge, die Sie tun können. Wenn sich Ihre Nutzer beispielsweise häufig an einem ganz anderen Ort als Ihre Server befinden, kann ein CDN Ihre Inhalte näher an sie heranbringen.

Weitere Informationen finden Sie im Leitfaden zum Optimieren des TTFB.

Verzögerung beim Laden von Ressourcen – der oft übersehene Grund für ein langsames LCP

Wenn sich die TTFB zwar verbessern lässt, aber alle Verbesserungen physikalisch begrenzt sind, kann die Verzögerung bei der Ressourcenauslastung möglicherweise beseitigt werden. In der Praxis ist sie nur durch Ihre Bereitstellungsarchitektur begrenzt.

In diesem Teil wird die Zeit gemessen, die vergeht, vom Eintreffen des ersten Bytes der HTML-Antwort (TTFB) bis zum Starten einer Anfrage des Browsers für das LCP-Bild. Wir haben uns jahrelang darauf konzentriert, wie lange es dauert, LCP-Bilder herunterzuladen, aber oft ignoriert, wie viel Zeit vergeht, bevor der Browser angewiesen wird, den Download zu starten.

Auf der durchschnittlichen Website mit schlechtem LCP dauert es fast viermal so lange, bis mit dem Herunterladen des LCP-Bilds begonnen wird, wie es tatsächlich dauert. Zwischen TTFB und Bildanfrage vergehen 1,3 Sekunden. Das entspricht mehr als der Hälfte des LCP-Budgets von 2,5 Sekunden, das in einem einzigen Teil verbraucht wird.

Abhängigkeitsketten sind ein häufiger Grund für lange Ladezeiten. Am einfachsten ist eine Seite, auf der ein Stylesheet geladen wird, das nach dem Layout des Browsers ein Hintergrundbild festlegt, das dann als LCP dient. All diese Schritte müssen ausgeführt werden, bevor der Browser überhaupt weiß, dass er mit dem Herunterladen des LCP-Bilds beginnen soll.

Anhand der öffentlichen Crawling-Daten des HTTP Archive, in denen die „Initiator“-Kette der Netzwerkanfragen vom HTML-Dokument zu einem LCP-Image aufgezeichnet wird, ist die deutliche Korrelation zwischen der Länge der Anfragekette und einer langsameren LCP-Zeit zu erkennen.

Ein Diagramm, das die Beziehung zwischen abhängigen Anfrageketten und LCP veranschaulicht. Der Medianwert für die LCP steigt von 2.150 Millisekunden bei 0 abhängigen Anfragen auf 2.540 Millisekunden bei 1 abhängigen Anfragen und auf 2.850 Millisekunden bei 2 abhängigen Anfragen.
Die Beziehung zwischen abhängigen Anfrageketten und LCP.

Der Schlüssel besteht darin, dem Browser so schnell wie möglich mitzuteilen, wie hoch der LCP sein wird, damit er mit dem Laden beginnen kann, noch bevor ein Platz dafür im Layout der Seite vorhanden ist. Es gibt einige Tools, mit denen Sie dies erreichen können, z. B. ein klassisches <img>-Tag im HTML-Code, damit der Preloader es schnell finden und mit dem Download beginnen kann, oder ein <link rel="preload">-Tag (oder HTTP-Header) für Bilder, die keine <img>s sind.

Außerdem ist es wichtig, dem Browser zu helfen, zu bestimmen, welche Ressourcen priorisiert werden sollen. Das gilt insbesondere, wenn Ihre Seite beim Laden viele Anfragen sendet, da der Browser oft erst weiß, was das LCP-Element sein wird, nachdem viele dieser Ressourcen geladen und das Layout erstellt wurde. Wenn Sie das wahrscheinliche LCP-Element mit einem fetchpriority="high"-Attribut annotieren und loading="lazy" vermeiden, wird dem Browser mitgeteilt, dass die Ressource sofort geladen werden soll.

Weitere Tipps zur Optimierung der Ladezeit

Rendering-Verzögerung

Die Renderverzögerung gibt die Zeitspanne an, die vergeht, nachdem das LCP-Bild im Browser geladen und bereit ist, aber aus irgendeinem Grund dauert es noch etwas, bis es auf dem Bildschirm angezeigt wird. Manchmal ist dies eine langwierige Aufgabe, die den Hauptthread blockiert, wenn das Bild fertig ist. In anderen Fällen kann es sich um eine UI-Auswahl handeln, um ein ausgeblendetes Element zu enthüllen.

Bei der typischen Herkunft im Web gibt es anscheinend keine große Möglichkeit, die Renderverzögerung zu verkürzen. Bei der Optimierung können Sie jedoch manchmal eine Renderverzögerung schaffen, die sich aus der Zeit ergibt, die zuvor in anderen Unterteilen verbracht wurde. Wenn beispielsweise das LCP-Bild auf einer Seite vorab geladen wird, damit es schnell verfügbar ist, gibt es keine lange Ladeverzögerung mehr. Wenn die Seite selbst jedoch nicht bereit ist, das Bild anzuzeigen, z. B. aufgrund eines großen, renderblockierenden Stylesheets oder einer clientseitigen Rendering-App, die erst das gesamte JavaScript laden muss, bevor etwas angezeigt werden kann, ist das LCP immer noch langsamer als es sein sollte. Die Wartezeit wird jetzt als Rendering-Verzögerung angezeigt. Aus diesem Grund haben serverseitiges Rendering oder statische HTML-Seiten oft einen Vorteil, was den LCP angeht.

Wenn deine eigenen Inhalte betroffen sind, findest du weitere Tipps zur Optimierung der Renderverzögerung.

Prüfen Sie alle Unterelemente.

Um die LCP effektiv zu optimieren, müssen Entwickler die Seitenladezeit ganzheitlich betrachten und sich nicht nur auf die Optimierung von Bildern konzentrieren. Prüfen Sie jeden Teil der Zeit bis zum LCP, da es wahrscheinlich viel größere Verbesserungsmöglichkeiten gibt.

Für die Erhebung dieser Daten vor Ort enthält die Attributionsversion der Web Vitals-Bibliothek Zeitangaben für die LCP-Unterelemente. Der Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) enthält noch nicht alle diese Daten, aber es gibt Einträge für TTFB und LCP. Wir hoffen, die für diesen Beitrag verwendeten Daten in Zukunft in CrUX aufnehmen zu können. Wir halten Sie auf dem Laufenden.

Wenn Sie LCP-Unterelemente lokal testen möchten, verwenden Sie die Web Vitals-Erweiterung oder das JavaScript-Snippet in diesem Artikel. Lighthouse enthält auch eine Aufschlüsselung in der Analyse „Largest Contentful Paint-Element“. Weitere Tipps zu LCP-Unterelementen finden Sie demnächst im Bereich „Leistung“ der DevTools.