Eine detaillierte Anleitung zum Aufschlüsseln des LCP und zum Identifizieren wichtiger Verbesserungsbereiche.
Veröffentlicht: 30. April 2020
Largest Contentful Paint (LCP) ist einer der drei Core Web Vitals-Messwerte und gibt an, wie schnell der Hauptinhalt einer Webseite geladen wird. Insbesondere misst der LCP die Zeit ab dem Laden der Seite durch den Nutzer, bis das größte Bild oder der größte Textblock im Darstellungsbereich gerendert wird.
Für eine gute Nutzerfreundlichkeit sollten Websites einen LCP von höchstens 2, 5 Sekunden bei mindestens 75% der Seitenaufrufe erzielen.
Es gibt eine Reihe von Faktoren, die beeinflussen können, wie schnell der Browser eine Webseite laden und rendern kann. Verzögerungen bei diesen Tests können erhebliche Auswirkungen auf den LCP haben.
Selten kann die schnelle Korrektur eines einzelnen Teils einer Seite zu einer deutlichen Verbesserung des LCP-Werts führen. Wenn Sie den LCP-Wert verbessern möchten, müssen Sie sich den gesamten Ladevorgang ansehen und darauf achten, dass jeder Schritt optimiert ist.
LCP-Messwert
Bevor Entwickler die LCP optimieren, sollten sie herausfinden, ob sie überhaupt ein LCP-Problem haben und wie schwerwiegend es ist.
LCP kann mit einer Reihe von Tools gemessen werden. Nicht alle Tools messen LCP auf dieselbe Weise. Um den LCP echter Nutzer zu verstehen, sollten wir uns die Erfahrungen echter Nutzer ansehen und nicht, was ein laborbasiertes Tool wie Lighthouse oder lokale Tests zeigt. Diese Tools können Ihnen eine Fülle von Informationen zur Verfügung stellen, um den LCP zu erklären und zu verbessern. Beachten Sie jedoch, dass Lab-Tests allein möglicherweise nicht vollständig repräsentativ für die tatsächliche Nutzererfahrung sind.
LCP-Daten, die auf echten Nutzern basieren, können über RUM-Tools (Real User Monitoring) abgerufen werden, die auf einer Website installiert sind, oder über den Chrome User Experience Report (CrUX), in dem anonyme Daten von echten Chrome-Nutzern für Millionen von Websites erfasst werden.
CrUX-LCP-Daten in den Chrome-Entwicklertools verwenden
Im Bereich „Leistung“ der Chrome-Entwicklertools wird in der Live-Messwertansicht der lokale LCP neben dem CrUX-LCP der Seite oder des Ursprungs angezeigt.
Wenn Sie Felddaten in den Bereich „Leistung“ einblenden, können Sie feststellen, ob auf einer Seite LCP-Probleme für echte Nutzer auftreten, und die Einstellungen Ihrer lokalen Umgebung anpassen, um diese Probleme besser zu reproduzieren und zu beheben.
CrUX-LCP-Daten von PageSpeed Insights verwenden
In PageSpeed Insights finden Sie im Bereich Ergebnisse für Ihre echten Nutzer ansehen Zugriff auf CrUX-Daten. Detailliertere datenbankbasierte Daten finden Sie im unteren Bereich mit der Überschrift Leistungsprobleme diagnostizieren. Wenn für Ihre Website CrUX-Daten verfügbar sind, konzentrieren Sie sich immer zuerst auf die echten Nutzerdaten.
In PageSpeed Insights werden bis zu vier verschiedene CrUX-Daten angezeigt:
- Mobile Daten für Diese URL
- Desktop-Daten für Diese URL
- Mobile Daten für den gesamten Ursprung
- Desktop-Daten für den gesamten Origin
Sie können sie über die Steuerelemente oben und oben rechts in diesem Bereich aktivieren oder deaktivieren. Wenn für eine URL nicht genügend Daten vorhanden sind, um sie auf URL-Ebene anzuzeigen, aber Daten für den Ursprung vorliegen, werden in PageSpeed Insights immer die Ursprungsdaten angezeigt.
Der LCP für den gesamten Ursprung kann sich stark vom LCP einer einzelnen Seite unterscheiden, je nachdem, wie der LCP auf dieser Seite im Vergleich zu anderen Seiten dieses Ursprungs geladen wird. Sie kann auch dadurch beeinflusst werden, wie Besucher zu diesen Seiten navigieren. Startseiten werden tendenziell von neuen Nutzern besucht und werden daher häufig kalt geladen, es fehlen jedoch im Cache gespeicherte Inhalte. Dies sind oft die langsamsten Seiten einer Website.
Ein Blick auf die vier verschiedenen Kategorien von CrUX-Daten gibt Aufschluss darüber, ob ein LCP-Problem nur auf dieser Seite oder auf ein allgemeineres, websiteweites Problem zutrifft. Außerdem können Sie sehen, bei welchen Gerätetypen LCP-Probleme auftreten.
Zusätzliche CrUX-Messwerte in PageSpeed Insights verwenden
Wenn Sie den LCP optimieren möchten, sollten Sie auch die Zeitangaben für First Contentful Paint (FCP) und Time to First Byte (TTFB) verwenden. Dies sind gute Diagnosemesswerte, die wertvolle Einblicke in den LCP liefern können.
Der TTFB ist die Zeitspanne zwischen dem Zeitpunkt, zu dem der Besucher beginnt, eine Seite aufzurufen (z. B. auf einen Link klickt), und dem Zeitpunkt, zu dem die ersten Bytes des HTML-Dokuments empfangen werden. Bei einer hohen TTFB kann es schwierig oder sogar unmöglich sein, ein LCP von 2,5 Sekunden zu erreichen.
Ein hoher TTFB kann auf mehrere Serverweiterleitungen, Besucher, die weit vom nächsten Websiteserver entfernt sind, Besucher mit schlechten Netzwerkbedingungen oder die Unfähigkeit zurückzuführen sein, aufgrund von Suchparametern im Cache gespeicherte Inhalte zu verwenden.
Sobald das Rendern einer Seite beginnt, wird möglicherweise zuerst etwas gezeichnet (z. B. die Hintergrundfarbe), gefolgt von einigen Inhalten (z. B. der Websiteheader). Das Erscheinen der ersten Inhalte wird mit FCP gemessen. Das Delta zwischen FCP und anderen Messwerten kann sehr aufschlussreich sein.
Ein großer Unterschied zwischen TTFB und FCP kann darauf hinweisen, dass der Browser viele renderblockierende Assets herunterladen muss. Es kann auch ein Zeichen dafür sein, dass für das Rendern sinnvoller Inhalte viel Arbeit erforderlich ist - ein klassisches Zeichen für eine Website, die stark auf clientseitiges Rendering angewiesen ist.
Ein großer Unterschied zwischen FCP und LCP bedeutet, dass die LCP-Ressource entweder nicht sofort für die Priorisierung durch den Browser verfügbar ist (z. B. Text oder Bilder, die über JavaScript verwaltet werden, anstatt in der ursprünglichen HTML-Datei verfügbar zu sein) oder dass der Browser andere Aufgaben ausführt, bevor er die LCP-Inhalte anzeigen kann.
PageSpeed Insights Lighthouse-Daten verwenden
Im Lighthouse-Abschnitt von PageSpeed Insights finden Sie einige Hinweise zur Verbesserung des LCP. Zuerst sollten Sie jedoch prüfen, ob der angegebene LCP weitgehend mit den echten Nutzerdaten übereinstimmt, die von CrUX bereitgestellt werden. Wenn Lighthouse und CrUX nicht übereinstimmen, liefert CrUX wahrscheinlich ein genaueres Bild Ihrer Nutzererfahrung. Achten Sie darauf, dass Ihre CrUX-Daten sich auf Ihre Seite und nicht auf den gesamten Ursprung beziehen, bevor Sie Maßnahmen ergreifen.
Wenn sowohl Lighthouse als auch CrUX LCP-Werte anzeigen, die verbessert werden müssen, finden Sie im Lighthouse-Abschnitt wertvolle Informationen dazu, wie Sie die LCP verbessern können. Mit dem LCP-Filter können Sie nur Prüfungen anzeigen lassen, die für LCP relevant sind. Gehen Sie dazu so vor:
Neben den zu verbessernden Empfehlungen gibt es auch Diagnosedaten, die Ihnen bei der Diagnose des Problems helfen können. Die Diagnose Largest Contentful Paint-Element enthält eine nützliche Aufschlüsselung der verschiedenen Timings, aus denen sich der LCP zusammensetzt:
Mit diesen Teilbereichen beschäftigen wir uns als Nächstes.
LCP-Aufschlüsselung
Die Optimierung für LCP kann eine komplexere Aufgabe sein, wenn PageSpeed Insights Ihnen keine Antwort zur Verbesserung dieses Messwerts liefert. Bei komplexen Aufgaben ist es im Allgemeinen besser, sie in kleinere, überschaubarere Aufgaben aufzuteilen und jede davon getrennt anzugehen.
In diesem Abschnitt wird eine Methodik zur Unterteilung des LCP in seine wichtigsten Teilabschnitte vorgestellt. Im Anschluss werden spezifische Empfehlungen und Best Practices für die Optimierung der einzelnen Teile vorgestellt.
Die meisten Seitenladevorgänge umfassen in der Regel eine Reihe von Netzwerkanfragen. Um Möglichkeiten zur Verbesserung des LCP zu ermitteln, sollten Sie sich jedoch zunächst nur zwei ansehen:
- Das ursprüngliche HTML-Dokument
- Die LCP-Ressource (falls zutreffend)
Auch andere Anfragen auf der Seite können sich auf den LCP auswirken. Diese beiden Anfragen – insbesondere die Zeiten, zu denen die LCP-Ressource beginnt und endet – geben Aufschluss darüber, ob Ihre Seite für den LCP optimiert ist.
Sie können Entwicklertools wie PageSpeed Insights, die bereits erwähnten Chrome DevTools oder WebPageTest verwenden, um die LCP-Ressource zu ermitteln. Dort können Sie die URL (falls zutreffend) abgleichen, die vom Element in einer Netzwerkabfolge aller von der Seite geladenen Ressourcen geladen wird.
In der folgenden Visualisierung sind diese Ressourcen beispielsweise in einem Netzwerkabfolgediagramm für eine typische Seitenladezeit hervorgehoben, bei der für das LCP-Element eine Bildanfrage erforderlich ist.
Bei einer gut optimierten Seite sollte die LCP-Ressourcenanfrage so früh wie möglich gestartet werden und das LCP-Element sollte nach dem Laden der LCP-Ressource so schnell wie möglich gerendert werden. Um zu visualisieren, ob eine bestimmte Seite diesem Prinzip folgt, können Sie die gesamte LCP-Zeit in die folgenden Teilbereiche unterteilen:
- Time to First 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 der TTFB und dem Zeitpunkt, zu dem der Browser mit dem Laden der LCP-Ressource beginnt. Wenn für das LCP-Element keine Ressourcen geladen werden müssen, um es zu rendern (z. B. wenn es sich um einen Textknoten handelt, der mit einer Systemschriftart gerendert wird), beträgt diese Zeit 0.
- Ladedauer der Ressource
- 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 dieser Wert „0“.
- Verzögerung beim Rendering des Elements
- Die Zeit zwischen dem Ende des Ladens der LCP-Ressource und dem vollständigen Rendern des LCP-Elements.
Der LCP jeder Seite besteht aus diesen vier Unterkategorien. Es gibt keine Lücke oder Überschneidung und sie ergeben zusammen die volle LCP-Zeit.
Der LCP-Wert jeder einzelnen Seite kann in diese vier Teilwerte unterteilt werden. Es gibt keine Überschneidungen oder Lücken zwischen ihnen. Zusammen ergeben sie die gesamte LCP-Zeit.
Bei der Optimierung des LCP ist es hilfreich, diese Teilelemente einzeln zu optimieren. Sie müssen aber auch alle optimieren. In einigen Fällen verbessert die auf einen Teil angewendete Optimierung den LCP nicht, sondern verlagert lediglich die eingesparte Zeit in einen anderen Teil.
Wenn Sie beispielsweise in der vorherigen Netzwerkabfolge die Dateigröße unseres Bildes reduzieren, indem Sie es stärker komprimieren oder zu einem optimaleren Format wie AVIF oder WebP wechseln, wird die Dauer der Ressourcenauslieferung verkürzt. Der LCP wird dadurch jedoch nicht verbessert, da sich die Zeit nur auf den Teil Element-Rendering-Verzögerung verlagert:
Das liegt daran, dass auf dieser Seite das LCP-Element ausgeblendet ist, bis der JavaScript-Code geladen ist. Dann wird alles auf einmal angezeigt.
Dieses Beispiel veranschaulicht, warum Sie alle diese Unterbereiche optimieren müssen, um die besten LCP-Ergebnisse zu erzielen.
Optimale Zeiträume für Unterelemente
Um die einzelnen Bestandteile des LCP zu optimieren, ist es wichtig zu wissen, wie diese auf einer gut optimierten Seite idealerweise aufgeteilt sind.
Zwei der vier Unterteile tragen das Wort „delay“ in ihrem Namen. Das ist ein Hinweis darauf, dass Sie diese Zeiten so nah wie möglich an null bringen möchten. Die anderen beiden Teile umfassen Netzwerkanfragen, die ihrer Natur nach Zeit in Anspruch nehmen.
Diese Zeitaufschlüsselungen sind Richtlinien, keine strikten Regeln. Wenn die LCP-Zeiten auf Ihren Seiten konstant unter 2,5 Sekunden liegen, spielt das relative Verhältnis keine Rolle. Wenn Sie jedoch in einer der Verzögerungsabschnitte viel unnötig Zeit verbringen, ist es sehr schwierig, ständig das Ziel von 2,5 Sekunden zu erreichen.
So können Sie sich die Aufschlüsselung der LCP-Zeit vorstellen:
- Der überwiegende Großteil der LCP-Zeit sollte für das Laden des HTML-Dokuments und der LCP-Quelle aufgewendet werden.
- Wenn eine dieser beiden Ressourcen vor dem LCP nicht geladen wird, bietet sich Verbesserungsmöglichkeit.
So optimieren Sie die einzelnen Teile
Nachdem Sie nun wissen, wie sich die einzelnen LCP-Teilzeiträume auf einer gut optimierten Seite aufschlüsseln sollten, können Sie mit der Optimierung Ihrer eigenen Seiten beginnen.
In den nächsten vier Abschnitten finden Sie Empfehlungen und Best Practices zur Optimierung der einzelnen Teile. Sie werden in der Reihenfolge präsentiert, beginnend mit den Optimierungen, die voraussichtlich die größten Auswirkungen haben.
1. Verzögerung beim Laden der Ressourcen beseitigen
Ziel dieses Schritts ist es, dass das Laden der LCP-Ressource so früh wie möglich beginnt. Theoretisch kann das Laden einer Ressource sofort nach dem TTFB beginnen. In der Praxis gibt es jedoch immer eine Verzögerung, bis Browser mit dem Laden von Ressourcen beginnen.
Als Faustregel gilt: Die LCP-Ressource sollte gleichzeitig mit der ersten Ressource geladen werden, die von dieser Seite geladen wird. Anders ausgedrückt: Wenn die LCP-Ressource erst später geladen wird als die erste, besteht Verbesserungspotenzial.
Im Allgemeinen gibt es zwei Faktoren, die sich darauf auswirken, wie schnell eine LCP-Ressource geladen wird:
- Wenn die Ressource gefunden wird.
- Die Priorität der Ressource.
Optimieren, wenn die Ressource gefunden wird
Damit die LCP-Ressource so früh wie möglich geladen wird, muss sie vom Vorablade-Scanner des Browsers in der ersten HTML-Dokumentantwort gefunden werden. In den folgenden Fällen kann der Browser die LCP-Ressource finden, indem er die Antwort des HTML-Dokuments scannt:
- Das LCP-Element ist ein
<img>-Element und seinesrc- odersrcset-Attribute sind im ursprünglichen HTML-Markup vorhanden. - Für das LCP-Element ist ein CSS-Hintergrundbild erforderlich. Dieses Bild wird jedoch mit
<link rel="preload">im HTML-Markup oder mithilfe einesLink-Headers vorab geladen. - Das LCP-Element ist ein Textknoten, für den eine Webschriftart zum Rendern erforderlich ist. Diese wird mithilfe von
<link rel="preload">im HTML-Markup oder mithilfe einesLink-Headers geladen.
Im Folgenden finden Sie einige Beispiele, in denen die LCP-Ressource beim Scannen der HTML-Dokumentantwort nicht gefunden werden kann:
- Das LCP-Element ist ein
<img>, das der Seite mithilfe von JavaScript dynamisch hinzugefügt wird. - Das LCP-Element wird mit einer JavaScript-Bibliothek verzögert geladen, die seine
src- odersrcset-Attribute ausblendet (häufig alsdata-srcoderdata-srcset). - Für das LCP-Element ist ein CSS-Hintergrundbild erforderlich.
In jedem dieser Fälle muss der Browser das Script ausführen oder das Stylesheet anwenden. Dazu muss er in der Regel warten, bis Netzwerkanfragen abgeschlossen sind, bevor er die LCP-Ressource finden und laden kann. Das ist nie optimal.
Um unnötige Verzögerungen bei der Ressourcenauslieferung zu vermeiden, sollte Ihre LCP-Ressource über die HTML-Quelle erreichbar sein. Wenn die Ressource nur aus einer externen CSS- oder JavaScript-Datei referenziert wird, sollte die LCP-Ressource mit einer hohen Abrufpriorität vorab geladen werden, z. B.:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Priorität der Ressource optimieren
Auch wenn die LCP-Ressource im HTML-Markup sichtbar ist, wird sie möglicherweise nicht so früh wie die erste Ressource geladen. Dies kann passieren, wenn die Prioritätsheuristik des Scanners für das Vorabladen nicht erkennt, dass die Ressource wichtig ist, oder wenn er feststellt, dass andere Ressourcen wichtiger sind.
Sie können das LCP-Bild beispielsweise mit HTML verzögern, indem Sie loading="lazy" für das <img>-Element festlegen. Beim Lazy Loading wird die Ressource erst geladen, wenn das Layout bestätigt, dass sich das Bild im Viewport befindet. Das Laden kann also später beginnen als sonst.
Auch ohne Lazy Loading werden Bilder von Browsern nicht mit der höchsten Priorität geladen, da sie keine renderblockierenden Ressourcen sind. Sie können dem Browser mit dem Attribut fetchpriority mitteilen, welche Ressourcen am wichtigsten sind. Das Attribut kann für Ressourcen verwendet werden, die von einer höheren Priorität profitieren könnten:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Es ist empfehlenswert, fetchpriority="high" für ein <img>-Element festzulegen, wenn Sie der Meinung sind, dass es sich wahrscheinlich um das LCP-Element Ihrer Seite handelt. Wenn Sie jedoch für mehr als ein oder zwei Bilder eine hohe Priorität festlegen, ist das Festlegen der Priorität nicht hilfreich, um den LCP zu reduzieren.
Sie können auch die Priorität von Bildern herabsetzen, die möglicherweise früh in der Dokumentantwort, aber aufgrund von Stilen nicht sichtbar sind, z. B. Bilder auf Karussellfolien, die beim Start nicht sichtbar sind:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Wenn Sie bestimmte Ressourcen herabstufen, kann mehr Bandbreite für Ressourcen freigegeben werden, die sie dringender benötigen. Seien Sie jedoch vorsichtig. Prüfen Sie immer die Ressourcenpriorität in den DevTools und testen Sie Änderungen mit Lab- und Feldtools.
Nachdem Sie die Priorität und die Erkennungszeit der LCP-Ressource optimiert haben, sollte die Netzwerkabfolge so aussehen (wobei die LCP-Ressource zur selben Zeit beginnt wie die erste Ressource):
2. Verzögerung beim Rendering des Elements beseitigen
Ziel dieses Schritts ist es, dafür zu sorgen, dass das LCP-Element sofort nach dem Laden der Ressource gerendert werden kann, unabhängig davon, wann das passiert.
Der Hauptgrund dafür, dass das LCP-Element sofort nach Abschluss des Ladevorgangs der Ressource nicht gerendert werden könnte, ist, dass das Rendering aus einem anderen Grund blockiert wurde:
- Das Rendern der gesamten Seite wird durch Stylesheets oder synchrone Scripts in der
<head>blockiert, die noch geladen werden. - Das Laden der LCP-Ressource ist abgeschlossen, das LCP-Element wurde dem DOM jedoch noch nicht hinzugefügt. Es wird auf das Laden von JavaScript-Code gewartet.
- Das Element wird von einem anderen Code ausgeblendet, z. B. von einer A/B-Testbibliothek, die noch festlegt, an welchem Test der Nutzer teilnehmen soll.
- Der Hauptthread ist aufgrund von langen Aufgaben blockiert und das Rendering muss warten, bis diese langen Aufgaben abgeschlossen sind.
In den folgenden Abschnitten wird erläutert, wie Sie die häufigsten Ursachen für unnötige Verzögerungen beim Rendern von Elementen beheben können.
Stylesheets reduzieren oder das Rendering blockieren
Stilblätter, die aus dem HTML-Markup geladen werden, blockieren das Rendern aller nachfolgenden Inhalte. Das ist gut, da Sie in der Regel kein unformatiertes HTML rendern möchten. Wenn das Stylesheet jedoch so groß ist, dass es deutlich länger dauert als die LCP-Ressource, wird das LCP-Element nicht gerendert, selbst nachdem die Ressource fertig geladen wurde, wie in diesem Beispiel gezeigt:
Sie haben folgende Möglichkeiten, das Problem zu beheben:
- Fügen Sie das Style-Sheet inline in den HTML-Code ein, um die zusätzliche Netzwerkanfrage zu vermeiden.
- die Größe des Stylesheets reduzieren.
Im Allgemeinen wird das Einfügen des Stylesheets nur empfohlen, wenn es klein ist, da eingefügte Inhalte im HTML-Code nicht vom Caching bei nachfolgenden Seitenladevorgängen profitieren können. Wenn ein Stylesheet so groß ist, dass es länger zum Laden braucht als die LCP-Ressource, ist es wahrscheinlich kein guter Kandidat für das Einbetten.
In den meisten Fällen können Sie dafür sorgen, dass das Stylesheet das Rendering des LCP-Elements nicht blockiert, indem Sie es verkleinern, sodass es kleiner als die LCP-Ressource ist. So sollte sichergestellt werden, dass es bei den meisten Besuchen nicht zu Engpässen kommt.
Hier einige Empfehlungen, wie Sie die Größe des Stylesheets reduzieren können:
- Ungenutztes CSS entfernen: Mit den Chrome DevTools können Sie CSS-Regeln finden, die nicht verwendet werden und potenziell entfernt (oder verschoben) werden können.
- Nicht kritisches CSS verzögern: Teilen Sie Ihr Stylesheet in Stile auf, die für das erste Laden der Seite erforderlich sind, und Stile, die verzögert geladen werden können.
- CSS reduzieren und komprimieren: Achten Sie bei wichtigen Stilen darauf, deren Übertragungsgröße so weit wie möglich zu reduzieren.
JavaScript, das das Rendering blockiert, verzögern oder inline einfügen
Es ist fast nie erforderlich, dem <head> Ihrer Seiten synchrone Scripts (Scripts ohne die Attribute async oder defer) hinzuzufügen. Dies hat fast immer negative Auswirkungen auf die Leistung.
Wenn JavaScript-Code so früh wie möglich beim Laden der Seite ausgeführt werden muss, sollten Sie ihn inline einfügen, damit das Rendern nicht durch das Warten auf eine weitere Netzwerkanfrage verzögert wird. Wie bei Stylesheets sollten Sie Scripts jedoch nur dann inline einfügen, wenn sie sehr klein sind.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Serverseitiges Rendering verwenden
Beim serverseitigen Rendering (Server-Side Rendering, SSR) wird die clientseitige Anwendungslogik auf dem Server ausgeführt. Dabei wird auf HTML-Dokumentanfragen mit dem vollständigen HTML-Markup geantwortet.
Aus Sicht der LCP-Optimierung hat SSR zwei Hauptvorteile:
- Ihre Bildressourcen sind über die HTML-Quelle zugänglich (wie in Schritt 1 oben beschrieben).
- Für die Darstellung des Seiteninhalts sind keine zusätzlichen JavaScript-Anfragen erforderlich.
Der Hauptnachteil von SSR ist, dass zusätzliche Serververarbeitungszeit erforderlich ist, was die TTFB verlangsamen kann. Dieser Kompromiss lohnt sich in der Regel, da Sie die Serververarbeitungszeiten selbst steuern können, während die Netzwerk- und Gerätefunktionen Ihrer Nutzer nicht in Ihrem Einflussbereich liegen.
Eine ähnliche Option wie SSR wird als Static Site Generation (SSG) oder Prerendering bezeichnet. Dabei werden Ihre HTML-Seiten in einem Build-Schritt und nicht bei Bedarf generiert. Wenn das Pre-Rendering mit Ihrer Architektur möglich ist, ist es im Allgemeinen die bessere Wahl für die Leistung.
Lange Aufgaben aufteilen
Auch wenn Sie der vorherigen Empfehlung gefolgt sind und Ihr JavaScript-Code weder das Rendern blockiert noch für das Rendern Ihrer Elemente verantwortlich ist, kann er die LCP verzögern.
Am häufigsten tritt dieses Problem auf, wenn auf Seiten große JavaScript-Dateien geladen werden, die im Hauptthread des Browsers geparst und ausgeführt werden müssen. Selbst wenn Ihre Bildressource vollständig heruntergeladen wurde, kann es also möglicherweise noch warten, bis ein anderes Skript ausgeführt wurde, bevor sie gerendert werden kann.
Alle modernen Browser rendern Bilder im Hauptthread. Das bedeutet, dass alles, was den Hauptthread blockiert, zu unnötigen Verzögerungen beim Rendern von Elementen führen kann.
3. Dauer des Ressourcenladevorgangs verkürzen
Ziel dieses Schritts ist es, die Zeit zu verkürzen, die für die Übertragung der Bytes der Ressource über das Netzwerk auf das Gerät des Nutzers benötigt wird. Im Allgemeinen gibt es vier Möglichkeiten:
- Reduzieren Sie die Größe der Ressource.
- Reduzieren Sie die Entfernung, die die Ressource zurücklegen muss.
- Reduzierung von Konflikten um die Netzwerkbandbreite.
- Die Netzwerkzeit wird vollständig entfernt.
Größe der Ressource reduzieren
Die LCP-Ressource einer Seite (falls vorhanden) ist entweder ein Bild oder ein Web-Schriftschnitt. In den folgenden Leitfäden wird ausführlich beschrieben, wie Sie die Größe beider Arten verringern können:
- Optimale Bildgröße bereitstellen
- Moderne Bildformate verwenden
- Bilder komprimieren
- Schriftgröße im Web reduzieren
Verringern Sie die Entfernung, die die Ressource zurücklegen muss.
Sie können nicht nur die Größe einer Ressource reduzieren, sondern auch die Ladezeiten, indem Sie Ihre Server möglichst nah an Ihren Nutzern platzieren. Am besten eignet sich dafür ein Content Delivery Network (CDN).
Bild-CDNs sind besonders hilfreich, da sie nicht nur die Entfernung verringern, die die Ressource zurücklegen muss, sondern auch die Größe der Ressource im Allgemeinen reduzieren. Dabei werden alle Empfehlungen zur Größenreduzierung automatisch für Sie implementiert.
Konkurrenz um die Netzwerkbandbreite reduzieren
Selbst wenn Sie die Größe der Ressource und die zurückgelegte Strecke reduziert haben, kann das Laden einer Ressource trotzdem viel Zeit in Anspruch nehmen, wenn Sie viele andere Ressourcen gleichzeitig laden. Dieses Problem wird als Netzwerkkonflikt bezeichnet.
Wenn Sie Ihrer LCP-Ressource eine hohe fetchpriority zugewiesen und das Laden so bald wie möglich gestartet haben, wird der Browser sein Bestes tun, um zu verhindern, dass Ressourcen mit niedrigerer Priorität mit ihr konkurrieren. Wenn Sie jedoch viele Ressourcen mit einem hohen fetchpriority laden oder nur viele Ressourcen im Allgemeinen laden, kann sich dies darauf auswirken, wie schnell die LCP-Ressource geladen wird.
Netzwerkzeit vollständig entfernen
Die beste Möglichkeit, die Dauer der Ressourcenauslastung zu verkürzen, besteht darin, das Netzwerk vollständig aus dem Prozess herauszunehmen. Wenn Sie Ihre Ressourcen mit einer effizienten Cache-Kontrollrichtlinie bereitstellen, werden sie Besuchern, die diese Ressourcen ein zweites Mal anfordern, aus dem Cache bereitgestellt. Die Dauer der Ressourcenladezeit wird so praktisch auf null reduziert.
Wenn Ihre LCP-Ressource eine Webschriftart ist, sollten Sie nicht nur die Größe der Webschriftart reduzieren, sondern auch überlegen, ob Sie das Rendering bei der Ressourcenauslastung der Webschriftart blockieren müssen. Wenn Sie für font-display einen anderen Wert als auto oder block festlegen, ist der Text während des Ladevorgangs immer sichtbar und LCP wird bei einer zusätzlichen Netzwerkanfrage nicht blockiert.
Wenn Ihre LCP-Ressource klein ist, kann es sinnvoll sein, die Ressourcen als Daten-URL einzufügen. Dadurch wird auch die zusätzliche Netzwerkanfrage vermieden. Die Verwendung von Daten-URLs ist jedoch mit Einschränkungen verbunden, da die Ressourcen nicht im Cache gespeichert werden können und in einigen Fällen aufgrund der zusätzlichen Kosten für die Decodierung zu längeren Rendering-Verzögerungen führen kann.
4. Zeit bis zum ersten Byte reduzieren
Ziel dieses Schritts ist es, die erste HTML-Datei so schnell wie möglich zu senden. Dieser Schritt wird zuletzt aufgeführt, da Entwickler oft darüber am wenigsten Kontrolle haben. Es ist jedoch auch einer der wichtigsten Schritte, da er sich direkt auf jeden nachfolgenden Schritt auswirkt. Im Frontend kann nichts passieren, bis das Backend das erste Byte des Inhalts liefert. Alles, was Sie tun können, um die TTFB zu beschleunigen, verbessert auch alle anderen Lademesswerte.
Eine häufige Ursache für eine langsame TTFB für eine ansonsten schnelle Website sind Besucher, die über mehrere Weiterleitungen, z. B. über Anzeigen oder gekürzte Links, auf Ihre Website gelangen. Minimieren Sie immer die Anzahl der Weiterleitungen, die ein Besucher abwarten muss.
Eine weitere häufige Ursache ist, dass im Cache gespeicherte Inhalte nicht von einem CDN-Edge-Server verwendet werden können und alle Anfragen bis zum Ursprungsserver weitergeleitet werden müssen. Dies kann passieren, wenn Besucher eindeutige URL-Parameter zu Analysezwecken verwenden, auch wenn sie nicht zu unterschiedlichen Seiten führen.
Eine ausführliche Anleitung zur Optimierung der TTFB findest du im Leitfaden zur Optimierung der TTFB.
Aufschlüsselung des LCP in JavaScript überwachen
Die Zeitangaben für alle oben genannten LCP-Unterelemente sind in JavaScript über eine Kombination der folgenden Leistungs-APIs verfügbar:
Der Vorteil der Berechnung dieser Zeitwerte in JavaScript besteht darin, dass Sie sie an einen Analyseanbieter senden oder in Ihre Entwicklertools protokollieren können, um die Fehlerbehebung und Optimierung zu vereinfachen.
Im folgenden Screenshot wird beispielsweise die Methode performance.measure() aus der User Timing API verwendet, um dem Timing-Track im Chrome DevTools-Steuerfeld „Leistung“ Balken hinzuzufügen.
Die Visualisierungen im Timings-Track sind besonders hilfreich, wenn Sie sie zusammen mit den Tracks Netzwerk und Hauptthread betrachten. So sehen Sie auf einen Blick, was in diesen Zeiträumen sonst noch auf der Seite passiert.
Sie können die LCP-Unterelemente nicht nur im Zeit-Track visualisieren, sondern auch mit JavaScript berechnen, welchen Prozentsatz jeder Teil der gesamten LCP-Zeit ausmacht. Anhand dieser Informationen können Sie feststellen, ob Ihre Seiten die zuvor beschriebenen empfohlenen prozentualen Aufschlüsselungen erfüllen.
Dieser Screenshot zeigt ein Beispiel, in dem die Gesamtzeit jedes LCP-Teilelements sowie sein Prozentsatz an der Gesamt-LCP-Zeit in der Console protokolliert wird.
Beide Visualisierungen wurden mit dem folgenden Code erstellt:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
Sie können diesen Code unverändert für das lokale Debugging verwenden oder so ändern, dass diese Daten an einen Analyseanbieter gesendet werden, damit Sie besser nachvollziehen können, wie sich die LCP auf Ihren Seiten für echte Nutzer zusammensetzt.
Zusammenfassung
LCP ist komplex und der Zeitpunkt kann von einer Reihe von Faktoren beeinflusst werden. Wenn Sie jedoch bedenken, dass es bei der LCP-Optimierung in erster Linie darum geht, die Auslastung der LCP-Ressource zu optimieren, kann das die Dinge erheblich vereinfachen.
Grundsätzlich lässt sich die LCP-Optimierung in vier Schritten zusammenfassen:
- Achten Sie darauf, dass das Laden der LCP-Ressource so früh wie möglich beginnt.
- Das LCP-Element muss gerendert werden können, sobald die Ressource geladen ist.
- Reduzieren Sie die Ladezeit der LCP-Ressource so weit wie möglich, ohne die Qualität zu beeinträchtigen.
- Reichen Sie das erste HTML-Dokument so schnell wie möglich ein.
Wenn Sie diese Schritte auf Ihren Seiten ausführen können, können Sie davon ausgehen, dass Sie Ihren Nutzern eine optimale Ladezeit bieten. Dies sollte sich in Ihren LCP-Werten widerspiegeln.