Es kann kompliziert sein, den Largest Contentful Paint (LCP) einer Seite zu verbessern. Oft müssen dabei mehrere Aspekte berücksichtigt werden und es müssen auch Kompromisse eingegangen werden. In diesem Beitrag wird anhand von Felddaten aus realen Seitenaufrufen im Web ermittelt, worauf Entwickler sich bei der Optimierung konzentrieren sollten.
Klassischer LCP-Tipp: Verringern Sie die Größe der Bilder.
Bei den meisten Seiten im Web ist das LCP-Element ein Bild. Es liegt also nahe, anzunehmen, dass die beste Möglichkeit zur Verbesserung des LCP in der Optimierung des LCP-Bilds besteht.
Etwa fünf Jahre nach der Einführung von LCP war das oft der wichtigste Ratschlag. Achten Sie darauf, dass Ihre Bilder die richtige Größe haben und ausreichend komprimiert sind. Verwenden Sie dabei am besten ein Bildformat des 21. Jahrhunderts. Für Lighthouse gibt es sogar drei verschiedene Prüfungen.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Der Grund dafür ist, dass übermäßig viele Byte leicht gemessen werden können und Bildkomprimierungstools leicht vorgeschlagen werden können. Abhängig von Ihren Build- und Bereitstellungspipelines kann es auch einfach zu implementieren sein.
Wenn ja, tun Sie es! Es ist fast immer ein Gewinn, weniger Bytes an die Nutzer zu senden. Es gibt zahlreiche Websites im Web, die immer noch unnötig große Bilder bereitstellen, die selbst mit einer einfachen Komprimierung behoben werden können.
Als wir uns jedoch die Leistungsdaten von Chrome-Nutzern angesehen haben, um herauszufinden, wo die Zeit bis zum LCP normalerweise aufgewendet wird, stellten wir fest, dass die Downloadzeit für Bilder fast nie der Engpass ist.
Stattdessen stellen andere Teile des LCP ein viel größeres Problem dar.
Aufschlüsselung nach LCP-Unterteil
Wir haben uns die Daten aus den LCP-Teilabschnitten angesehen, um zu ermitteln, in welchen Bereichen der LCP die größte Optimierung ist. Weitere Informationen hierzu finden Sie im Artikel LCP optimieren.
Während jede Seite und jedes Framework einen anderen Ansatz zum Laden und Anzeigen des LCP-Elements der Seite verfolgen kann, kann jeder in die folgenden Unterabschnitte unterteilt werden:
Aus diesem Artikel zitiert dieser Artikel in folgende Unterabschnitte:
- Time to First Byte (TTFB)
- Die Zeit ab dem Laden der Seite durch den Nutzer bis zum Browser erhält das erste Byte der HTML-Dokumentantwort.
- Verzögerung beim Laden von Ressourcen
- Die Zeit zwischen der TTFB und dem Zeitpunkt, zu dem der Browser mit dem Laden der LCP-Ressource beginnt. Wenn
Zum Rendern des LCP-Elements ist kein Ressourcenaufbau erforderlich. Dieses Mal ist es
0. - Ladedauer der Ressource
- Die Zeit, die zum Laden der LCP-Ressource benötigt wird. Wenn der LCP
-Element erfordert zum Rendern kein Ressourcenladevorgang. Dies ist die Zeit für
0. - Verzögerung beim Rendern von Elementen
- Die Zeit zwischen dem Abschluss des Ladens der LCP-Ressource und dem LCP-Element vollständig gerendert werden.
Echte Navigationsleistungsdaten
| LCP-Bewertung | TTFB (ms) | Verzögerung beim Laden des Bildes (ms) | Ladedauer 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 aus Seitennavigationen mit einem LCP-Unterressourcenbild 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 herauszufinden, wo echte Nutzer ihre Zeit verbringen, während sie auf den LCP einer Seite warten.
Wie bei Core Web Vitals haben wir auch hier für jeden Ursprung im CrUX-Dataset das 75. Perzentil (p75) jedes LCP-Unterabschnitts genommen. Daraus wurden vier Verteilungen von p75-Werten (eine für jeden Teilteil) ermittelt. Um diese Verteilungen zusammenzufassen, haben wir den Medianwert dieser Werte für alle Ursprünge für jede der vier LCP-Unterabschnitte ermittelt.
Schließlich teilen wir Ursprünge in Gruppen auf, je nachdem, ob sie eine „gut“, „verbesserungsbedürftig“ oder „schlecht“ haben. LCP beim 75. Perzentil So lässt sich besser erkennen, wodurch sich ein Ursprung mit gutem LCP von einem Ursprung mit niedrigem LCP unterscheidet.
Größe des LCP-Bilds verringern? Dieses Mal mit Daten
Die Ladezeit gibt an, wie lange es dauert, die LCP-Ressource – in diesem Fall ein Bild – abzurufen. Diese Zeit ist normalerweise proportional zur Anzahl der Bytes im Bild. Daher wird empfohlen, diese Anzahl von Bytes zu reduzieren.
Bei der Betrachtung der Zeit in den vorherigen Diagrammen fällt auf, dass die Dauer des Bildladevorgangs nicht zu lange aufgewendet wird. Tatsächlich ist er der kürzeste LCP-Unterteil in allen LCP-Buckets. Die Ladedauer ist bei Ursprüngen mit niedrigem LCP länger als bei Ursprüngen mit gutem LCP, allerdings wird hier nicht viel Zeit verbraucht.
Die meisten Ursprünge mit einem schlechten LCP verbringen weniger als 10% ihrer Zeit für p75-LCP für das Herunterladen des LCP-Bilds.
Ja, Sie sollten darauf achten, dass Ihre Bilder optimiert sind, aber das ist nur ein Teil der Verbesserung des LCP. Anhand dieser Daten wird deutlich, dass bei einem typischen Ursprung im Web die potenziellen Steigerungen des LCP im Millisekundenbereich insgesamt gering sind, unabhängig davon, wie ausgefeilt das Komprimierungsschema ist.
<ph type="x-smartling-placeholder">Eine letzte Überraschung: Lange Ladezeiten wurden früher in der Regel auf Mobilgeräten und der Qualität von Mobilfunknetzen zurückzuführen. Früher haben wir erwartet, dass der Download eines Bildes bei einem herkömmlichen Mobiltelefon über ein Kabel mehrmals länger dauert als auf einem Desktop-Computer. Die Daten deuten darauf hin, dass das nicht mehr der Fall ist. Bei Ursprüngen mit einem schlechten LCP ist der Medianwert der Ladedauer von P75-Bildern auf Mobilgeräten nur 20% langsamer als auf Computern.
Time to First Byte (TTFB)
Bei Navigationen, die eine Netzwerkanfrage stellen, nimmt TTFB immer einige Zeit in Anspruch. Es dauert einige Zeit, einen DNS-Lookup durchzuführen und eine Verbindung herzustellen. Und die Physik ist einfach unschlagbar: Eine Anfrage muss über Kabel und optische Kabel durch die reale Welt reisen, um einen Server zu erreichen. Dann muss die Antwort den Weg zurückführen. Selbst der Medianwert für den Ursprung mit gutem LCP verbringt bei seinem 75. Perzentil mehr als eine halbe Sekunde für TTFB.
Die Unterschiede zwischen dem guten und dem schlechten LCP zeigen jedoch noch Verbesserungspotenzial. Bei mindestens der Hälfte der Ursprünge mit schlechtem LCP garantiert die p75-TTFB von 2.270 Millisekunden allein fast, dass der p75-LCP nicht schneller als der „gute“ 2,5-Sekunden-LCP sein kann. Grenzwert. Selbst eine moderate Verkürzung dieser Zeit würde eine erhebliche Verbesserung des LCP bedeuten.
Auch wenn du die Physik nicht besiegen kannst, gibt es einiges, was du tun kannst. Wenn sich Ihre Nutzer beispielsweise häufig an einem sehr anderen Standort als Ihre Server befinden, kann ein CDN Ihre Inhalte näher an sie heranbringen.
Weitere Informationen findest du im Leitfaden zur Optimierung der TTFB.
Verzögerung beim Laden der Ressource, der übersehene langsame LCP-Ursache
Wenn die TTFB verbessert werden kann, aber alle Verbesserungen von der Physik abhängig sind, lässt sich die Verzögerung beim Laden von Ressourcen möglicherweise eliminieren, was in der Praxis nur an Ihre Bereitstellungsarchitektur gebunden ist.
Dieser Teilabschnitt misst die Zeit vom Eingang des ersten Byte der HTML-Antwort (TTFB) bis zu dem Zeitpunkt, zu dem der Browser eine Anforderung für das LCP-Bild startet. Wir konzentrieren uns schon seit Jahren darauf, wie lange das Herunterladen von LCP-Bildern dauert. Wir ignorieren jedoch oft die Zeit, die verschwendet wird, bevor der Browser überhaupt aufgefordert wird, den Download zu starten.
Die durchschnittliche Website mit einem schlechten LCP muss fast viermal so lange auf den Download des LCP-Bilds warten wie beim eigentlichen Download und zwischen TTFB und Bildanfrage 1, 3 Sekunden warten. Das entspricht mehr als der Hälfte des 2,5-Sekunden-LCP-Budgets, das in einen einzelnen Teil eingeflossen ist.
Abhängigkeitsketten sind ein häufiger Grund für lange Ladeverzögerungen. Einfacher ist es, wenn eine Seite ein Style-Sheet lädt, das nach dem Layout durch den Browser ein Hintergrundbild festlegt, das schließlich als LCP dient. All diese Schritte müssen ausgeführt werden, bevor der Browser überhaupt weiß, dass er mit dem Herunterladen des LCP-Bildes beginnen soll.
Verwendung von öffentlichen Crawling-Daten des HTTP-Archivs, die den Initiator aufzeichnen vom HTML-Dokument zu einem LCP-Bild führt, erkennen Sie einen deutlichen Zusammenhang zwischen der Länge der Anfragekette und dem langsameren LCP.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Wichtig ist, dem Browser so schnell wie möglich den LCP mitzuteilen, damit er mit dem Laden beginnen kann, noch bevor er Platz im Layout der Seite hat. Dafür gibt es einige Tools, z. B. ein klassisches <img>-Tag im HTML-Code, damit der Preload-Scanner es schnell findet und mit dem Download beginnt, oder ein <link rel="preload">-Tag (oder HTTP-Header) für Bilder, die keine <img>-Elemente sind.
Es ist auch wichtig, dem Browser bei der Entscheidung zu helfen, welche Ressourcen priorisiert werden sollen. Dies gilt insbesondere, wenn Ihre Seite viele Anfragen während des Seitenaufbaus sendet, da der Browser oft erst weiß, was das LCP-Element ist, nachdem viele dieser Ressourcen geladen und das Layout erstellt wurde. Wenn Sie das mögliche LCP-Element mit einem fetchpriority="high"-Attribut annotieren und dabei loading="lazy" vermeiden, wird dem Browser klar, dass die Ressource sofort geladen werden muss.
Weitere Tipps zum Optimieren der Ladeverzögerung
Rendering-Verzögerung
Mit der Rendering-Verzögerung wird die Zeit gemessen, die vergeht, bis das LCP-Bild im Browser geladen und bereit ist. Es kann jedoch zu einer Verzögerung kommen, bis das Bild auf dem Bildschirm angezeigt wird. Manchmal ist dies eine lange Aufgabe, die den Hauptthread blockiert, wenn das Bild fertig ist. In anderen Fällen kann es eine Entscheidung über die Benutzeroberfläche sein, ein verstecktes Element sichtbar zu machen.
Bei einem typischen Ursprung im Web scheint keine große Verzögerung beim Rendering zu sein. Bei der Optimierung können Sie jedoch gelegentlich eine Rendering-Verzögerung erstellen, sodass diese über die in anderen Unterbereichen aufgewendete Zeit hinausgeht. Wenn eine Seite beispielsweise damit beginnt, das LCP-Bild vorab zu laden, damit es schnell verfügbar ist, gibt es keine lange Verzögerung beim Laden mehr. Wenn die Seite selbst jedoch nicht für die Anzeige des Bildes bereit ist, z. B. bei einem großen Stylesheet, das das Rendering blockiert, oder einer clientseitigen Rendering-App, die das gesamte JavaScript laden muss, bevor etwas angezeigt werden kann, ist LCP immer noch langsamer als nötig und die Wartezeit wird jetzt als Rendering-Verzögerung angezeigt. Aus diesem Grund sind serverseitiges Rendering oder statisches HTML bei LCP oft von Vorteil.
Falls Ihre eigenen Inhalte betroffen sind, finden Sie hier weitere Tipps zur Optimierung der Rendering-Verzögerung.
Überprüfen Sie alle diese Unterteile.
Es ist offensichtlich, dass Entwickler zur effektiven Optimierung des LCP nicht nur auf die Optimierung von Bildern, sondern auch auf den Seitenaufbau als Ganzes achten müssen. Überprüfen Sie jeden Teil der Zeit, um den LCP-Wert zu ermitteln, da wahrscheinlich viel größere Verbesserungsmöglichkeiten bestehen.
Zur Erfassung dieser Daten vor Ort enthält der Attributions-Build der Webvitals-Bibliothek Timings für die LCP-Unterteile. Der Bericht zur Nutzererfahrung in Chrome enthält noch nicht alle diese Daten. Er enthält jedoch Einträge für TTFB und LCP. Es ist also ein Anfang. Wir hoffen, die für diesen Beitrag verwendeten Daten in Zukunft auch in CrUX aufnehmen zu können. Wir halten Sie auf dem Laufenden.
Wenn Sie LCP-Unterteile lokal testen möchten, verwenden Sie die Web Vitals-Erweiterung oder das JavaScript-Snippet in diesem Artikel. Bei Lighthouse finden Sie eine Aufschlüsselung auch unter „Largest Contentful Paint“. Weitere Tipps zu LCP-Unterabschnitten findest du im Steuerfeld „Leistung“ in den Entwicklertools (demnächst verfügbar).