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 2, 5 Sekunden oder weniger für mindestens 75% der Seitenaufrufe erreichen.
Es gibt eine Reihe von Faktoren, die sich darauf auswirken können, wie schnell der Browser eine Webseite laden und rendern kann. Verzögerungen bei einem dieser Faktoren können sich erheblich auf die LCP auswirken.
Selten kann die schnelle Korrektur eines einzelnen Teils einer Seite zu einer deutlichen Verbesserung des LCP-Werts führen. Um den LCP-Wert zu verbessern, müssen Sie den gesamten Ladevorgang im Auge behalten und darauf achten, dass jeder Schritt optimiert ist.
LCP-Messwert
Vor der Optimierung des LCP sollten Entwickler herausfinden, ob und in welchem Umfang ein LCP-Problem vorliegt.
Der LCP kann mit verschiedenen Tools gemessen werden, die nicht alle auf dieselbe Weise messen. Um den LCP echter Nutzer zu verstehen, sollten wir uns ansehen, was echte Nutzer erleben und nicht, was ein laborbasiertes Tool wie Lighthouse oder lokale Tests zeigt. Diese laborbasierten Tools bieten eine Fülle von Informationen zur Erklärung von LCP und helfen Ihnen, den LCP zu verbessern. Beachten Sie jedoch, dass Labortests allein unter Umständen nicht ganz 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 von PageSpeed Insights verwenden
Mit PageSpeed Insights erhalten Sie im oberen Bereich Finden Sie heraus, was Ihre tatsächlichen Nutzer erleben auf CrUX-Daten. Detailliertere Lab-basierte Daten finden Sie im unteren Bereich Leistungsprobleme diagnostizieren. Wenn für Ihre Website CrUX-Daten verfügbar sind, konzentrieren Sie sich zuerst auf die Daten der echten Nutzer.
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 das gesamte Objekt Origin
Sie können diese in den Steuerelementen oben und rechts oben in diesem Abschnitt aktivieren und 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 in der Regel von neuen Nutzern besucht und werden daher häufig „kalt“ geladen, also ohne zwischengespeicherte Inhalte. Daher sind sie 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 von PageSpeed Insights verwenden
Wenn Sie den LCP optimieren möchten, sollten Sie auch die Timings First Contentful Paint (FCP) und Time to First Byte (TTFB) verwenden. Diese sind gute Diagnosemesswerte, die wertvolle Einblicke in den LCP liefern.
Der TTFB ist die Zeitspanne zwischen dem Beginn der Navigation des Besuchers zu einer Seite (z. B. Klicken auf einen Link) und dem Empfang der ersten Bytes des HTML-Dokuments. Bei einem hohen TTFB kann es schwierig oder sogar unmöglich sein, ein LCP von 2,5 Sekunden zu erreichen.
Eine hohe TTFB kann auf mehrere Serverweiterleitungen, Besucher weit entfernt vom nächstgelegenen Websiteserver, Besucher mit schlechter Netzwerkverbindung oder der Unfähigkeit zurückzuführen sein, im Cache gespeicherte Inhalte aufgrund von Suchparametern 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 dem FCP gemessen. Die Differenz zwischen FCP und anderen Messwerten kann sehr aussagekräftig 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 von CrUX übereinstimmt. 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. Verwenden Sie den LCP-Filter, um nur für LCP relevante Audits anzuzeigen:
Neben den Verbesserungsmöglichkeiten finden Sie auch Diagnoseinformationen, 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 Zeitangaben, aus denen sich der LCP zusammensetzt:
Auf diese Teilabschnitte gehen wir als Nächstes näher ein.
Aufschlüsselung nach LCP
Die Optimierung für den 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 zu unterteilen und jede davon separat zu bearbeiten.
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. Wenn Sie jedoch Möglichkeiten zur Verbesserung des LCP ermitteln möchten, sollten Sie sich zuerst nur zwei ansehen:
- Das ursprüngliche HTML-Dokument
- Die LCP-Ressource (falls zutreffend)
Während sich andere Anfragen auf der Seite auf den LCP auswirken können, geben diese beiden Anfragen – insbesondere die Zeiten, zu denen die LCP-Ressource beginnt und endet – Aufschluss darüber, ob Ihre Seite für LCP optimiert ist.
Sie können Entwicklertools wie PageSpeed Insights, Chrome DevTools oder WebPageTest verwenden, um die LCP-Ressource zu ermitteln. Dort können Sie die vom Element geladene URL (falls zutreffend) mit einer Netzwerkabfolge aller von der Seite geladenen Ressourcen abgleichen.
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 so schnell wie möglich gerendert werden, nachdem die LCP-Ressource geladen wurde. Um zu visualisieren, ob eine bestimmte Seite diesem Prinzip folgt oder nicht, können Sie die gesamte LCP-Zeit in die folgenden Unterabschnitte 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 von Ressourcen
- Die Zeit zwischen dem TTFB und dem Zeitpunkt, zu dem der Browser mit dem Laden der LCP-Ressource beginnt. Wenn für das LCP-Element keine Ressourcen zum Rendern geladen werden müssen (z. B. wenn es sich um einen Textknoten handelt, der mit einer Systemschriftart gerendert wird), beträgt diese Zeit 0.
- Dauer des Ressourcenladevorgangs
- Die Zeit, die zum Laden der LCP-Ressource 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 Rendern von Elementen
- Die Zeit zwischen dem Abschluss des Ladens der LCP-Ressource und dem LCP-Element vollständig gerendert werden.
Die LCP jeder Seite besteht aus diesen vier Unterkategorien. 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 führt eine Optimierung an einem Teil nicht zu einer Verbesserung des LCP, sondern verlagert die eingesparte Zeit nur auf 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:
Dies liegt daran, dass auf dieser Seite das LCP-Element ausgeblendet ist, bis der JavaScript-Code geladen ist und dann alles auf einmal angezeigt wird.
Dieses Beispiel veranschaulicht, dass Sie alle diese Teilelemente optimieren müssen, um die besten LCP-Ergebnisse zu erzielen.
Optimale Zeiträume für Unterelemente
Um jeden Teil des LCP zu optimieren, ist es wichtig zu wissen, welche Aufschlüsselung dieser Teilbereiche idealerweise auf einer gut optimierten Seite erfolgen sollte.
Zwei der vier Teilabschnitte haben das Wort „Verzögerung“. in ihren Namen. Das ist ein Hinweis darauf, dass Sie diese Zeiten so nah wie möglich an null heranbringen sollten. Die anderen beiden Teile umfassen Netzwerkanfragen, die naturgemäß 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 es keine Rolle, wie hoch die relativen Anteile sind. Aber wenn Sie unnötige Zeit in einem der "Verzögerungen" wird es sehr schwierig, ständig das Ziel von 2,5 Sekunden zu erreichen.
Sie können sich die Aufschlüsselung der LCP-Zeit wie folgt vorstellen:
- Der überwiegende Großteil der LCP-Zeit sollte für das Laden des HTML-Dokuments und der LCP-Quelle aufgewendet werden.
- Wenn vor dem LCP eine dieser beiden Ressourcen nicht geladen wird, besteht Verbesserungspotenzial.
So optimieren Sie die einzelnen Teile
Nachdem Sie nun wissen, wie die einzelnen LCP-Zeitabschnitte auf einer gut optimierten Seite aufgeschlüsselt werden sollten, können Sie mit der Optimierung Ihrer eigenen Seiten beginnen.
In den nächsten vier Abschnitten werden Empfehlungen und Best Practices für die Optimierung der einzelnen Teile vorgestellt. Sie werden in der Reihenfolge präsentiert, beginnend mit den Optimierungen, die voraussichtlich die größten Auswirkungen haben.
1. Verzögerungen beim Laden von Ressourcen vermeiden
In diesem Schritt soll dafür gesorgt werden, dass die LCP-Ressource so früh wie möglich geladen wird. 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 werden kann:
- Wenn die Ressource gefunden wird.
- Welche Priorität die Ressource erhält.
Optimieren, wenn die Ressource gefunden wird
Damit Ihre LCP-Ressource so früh wie möglich geladen wird, muss sie vom Preload Scanner des Browsers in der ersten HTML-Dokumentantwort erkannt 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 mit einemLink-Header) 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 dynamisch mit JavaScript hinzugefügt wird. - Das LCP-Element wird verzögert mit einer JavaScript-Bibliothek geladen, die die Attribute
srcodersrcset(häufig alsdata-srcoderdata-srcset) verbirgt. - Für das LCP-Element ist ein CSS-Hintergrundbild erforderlich.
In jedem dieser Fälle muss der Browser das Skript ausführen oder das Stylesheet anwenden. Normalerweise wird auf den Abschluss von Netzwerkanfragen gewartet, bevor die LCP-Ressource erkannt und geladen werden 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. In Fällen, in denen nur von einer externen CSS- oder JavaScript-Datei auf die Ressource verwiesen wird, sollte die LCP-Ressource mit einer hohen Abrufpriorität vorab geladen werden, zum Beispiel:
<!-- 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 über das HTML-Markup erkannt werden kann, wird sie noch 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. Wenn Sie Lazy Loading verwenden, wird die Ressource erst geladen, nachdem durch das Layout bestätigt wurde, dass sich das Bild im Darstellungsbereich befindet, sodass der Ladevorgang möglicherweise später als sonst beginnt.
Auch ohne Lazy Loading werden Bilder anfangs von Browsern nicht mit der höchsten Priorität geladen, da sie keine Ressourcen sind, die das Rendering blockieren. 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 mehr als ein oder zwei Bildern eine hohe Priorität zuweisen, ist die Prioritätseinstellung zur Reduzierung des LCP nicht hilfreich.
Sie können auch die Priorität von Bildern senken, die sich zwar früh in der Antwort des Dokuments befinden, aufgrund des Stils aber nicht sichtbar sind, z. B. Bilder in 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. Überprüfe immer die Ressourcenpriorität in den Entwicklertools und teste Änderungen mit Labor- und Feldtools.
Nachdem Sie die Priorität und die Erkennungszeit der LCP-Ressource optimiert haben, sollte Ihre Netzwerkabfolge so aussehen (die LCP-Ressource beginnt gleichzeitig mit der ersten Ressource):
2. Beseitigen Sie Verzögerungen beim Rendern von Elementen.
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. - Die LCP-Ressource ist fertig geladen, aber das LCP-Element wurde dem DOM noch nicht hinzugefügt. Es wird darauf gewartet, dass JavaScript-Code geladen wird.
- 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.
Rendering-blockierende Stylesheets reduzieren oder inline einfügen
Aus dem HTML-Markup geladene Stylesheets blockieren das Rendern aller folgenden Inhalte. Dies ist gut, da Sie in der Regel keinen unformatierten HTML-Code darstellen möchten. Wenn das Stylesheet jedoch so groß ist, dass das Laden deutlich länger dauert als die LCP-Ressource, wird das Rendern des LCP-Elements verhindert – auch nachdem die Ressource vollständig geladen wurde, wie in diesem Beispiel gezeigt:
Sie haben folgende Möglichkeiten, dieses Problem zu beheben:
- Fügen Sie das Stylesheet inline in den HTML-Code ein, um die zusätzliche Netzwerkanfrage zu vermeiden. oder
- die Größe des Stylesheets reduzieren.
Generell wird das Inline-Format nur empfohlen, wenn Ihr Stylesheet klein ist, da Inline-Inhalte im HTML-Code nicht von dem Caching bei nachfolgenden Seitenladevorgängen profitieren können. Wenn ein Stylesheet so groß ist, dass es länger dauert als die LCP-Ressource, ist es wahrscheinlich kein guter Kandidat für die Inline-Funktion.
In den meisten Fällen lässt sich das Blockieren des Renderings des LCP-Elements durch das Stylesheet am besten verhindern, indem Sie die Größe des Stylesheets so reduzieren, dass es kleiner als die LCP-Ressource ist. So sollte sichergestellt werden, dass es bei den meisten Besuchen nicht zu einem Engpass kommt.
Hier einige Empfehlungen zum Reduzieren der Größe des Stylesheets:
- 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, synchrone Skripts (Skripts ohne das Attribut async oder defer) zum <head> Ihrer Seiten hinzuzufügen. Dies wirkt sich fast immer negativ auf die Leistung aus.
In Fällen, in denen JavaScript-Code so früh wie möglich beim Laden der Seite ausgeführt werden muss, ist es am besten, ihn inline einzubetten, damit das Rendering nicht durch Warten auf eine weitere Netzwerkanfrage verzögert wird. Wie bei Stylesheets sollten Sie Inline-Skripts jedoch nur verwenden, 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 in der HTML-Quelle sichtbar, wie in Schritt 1 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. In der Regel lohnt sich dieser Kompromiss jedoch, da Sie die Verarbeitungszeiten über den Server selbst steuern können, die Netzwerk- und Gerätefunktionen Ihrer Nutzer jedoch nicht.
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 Pre-Rendering mit Ihrer Architektur möglich ist, ist es im Hinblick auf die Leistung im Allgemeinen die bessere Wahl.
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.
Der häufigste Grund dafür ist, dass Seiten große JavaScript-Dateien laden, die geparst und im Hauptthread des Browsers ausgeführt werden müssen. Das bedeutet, dass selbst wenn Ihre Bildressource vollständig heruntergeladen wurde, möglicherweise noch gewartet werden muss, bis ein anderes Skript fertig ausgeführt wurde, bevor das Bild gerendert werden kann.
Alle aktuellen Browser rendern Bilder im Hauptthread. Das bedeutet, dass alles, was den Hauptthread blockiert, auch zu einer unnötigen Verzögerung beim Rendern von Elementen führen kann.
3. Ladedauer von Ressourcen reduzieren
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 drei Möglichkeiten, dies zu tun:
- Reduzieren Sie die Größe der Ressource.
- Reduzieren Sie die Entfernung, die die Ressource zurücklegen muss.
- Reduzierung von Konflikten um die Netzwerkbandbreite.
- Es fällt keine Netzwerkzeit an.
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
- Webschriftgröße reduzieren
Reduzieren der 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. Dazu eignet sich am besten 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.
Konflikte bei der Netzwerkbandbreite reduzieren
Selbst wenn Sie die Größe der Ressource und die zurückgelegte Strecke reduziert haben, kann das Laden einer Ressource trotzdem lange dauern, 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 hoher fetchpriority laden oder einfach nur viele Ressourcen laden, kann sich das auf die Geschwindigkeit auswirken, mit der die LCP-Ressource geladen wird.
Keine Netzwerkzeit
Die beste Möglichkeit, die Ressourcenlast zu verkürzen, besteht darin, das Netzwerk vollständig aus dem Prozess zu entfernen. Wenn Sie Ihre Ressourcen mit einer Richtlinie zur effizienten Cache-Steuerung bereitstellen, werden sie bei Besuchern, die diese Ressourcen ein zweites Mal anfordern, aus dem Cache bereitgestellt. Dadurch wird die Ladedauer der Ressourcen 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 Rendern 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 inline einzufügen, wodurch auch die zusätzliche Netzwerkanfrage entfällt. 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 können.
4. Zeit bis zum ersten Byte reduzieren
Ziel dieses Schritts ist es, den anfänglichen HTML-Code so schnell wie möglich bereitzustellen. Dieser Schritt wird als letzter aufgeführt, da Entwickler oft am wenigsten Kontrolle darüber haben. Es ist jedoch auch einer der wichtigsten Schritte, da er sich direkt auf jeden nachfolgenden Schritt auswirkt. Auf dem Frontend kann nichts passieren, bis das Backend dieses erste Byte des Inhalts liefert. Daher verbessert alles, was Sie zur Beschleunigung Ihrer TTFB tun können, auch alle anderen Lastwerte.
Eine häufige Ursache für eine lange TTFB bei einer ansonsten schnellen Website sind Besucher, die über mehrere Weiterleitungen gelangen, z. B. über Anzeigen oder verkürzte Links. 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 zurück zum Ursprungsserver geleitet werden müssen. Das kann passieren, wenn Besucher eindeutige URL-Parameter für Analysen verwenden, auch wenn sie nicht zu verschiedenen Seiten führen.
Eine genaue Anleitung zur Optimierung der TTFB findest du im Leitfaden zur Optimierung der TTFB.
Aufschlüsselung des LCP in JavaScript überwachen
Die Zeitinformationen für alle zuvor beschriebenen LCP-Unterabschnitte stehen Ihnen in JavaScript über eine Kombination der folgenden Leistungs-APIs zur Verfügung:
Der Vorteil der Berechnung dieser Zeitwerte in JavaScript besteht darin, dass Sie sie an einen Analyseanbieter senden oder in Ihren Entwicklertools protokollieren können, um das Debuggen und Optimieren zu erleichtern.
Im folgenden Screenshot wird beispielsweise die Methode performance.measure() aus der User Timing API verwendet, um dem Timing-Track im Bereich „Leistung“ der Chrome-Entwicklertools hinzuzufügen.
Die Visualisierungen im Zeitleisten-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 oben 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 ihn 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.
LCP-Aufschlüsselungen mit den Chrome-Entwicklertools beobachten
In den Chrome-Entwicklertools werden die LCP-Zeit, das LCP-Element und diese vier Unterelemente in Echtzeit protokolliert, damit Sie diese Aufschlüsselung sehen können.
Zusammenfassung
LCP ist komplex und sein Timing 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.
Die Optimierung der LCP lässt sich grob in vier Schritte unterteilen:
- Achten Sie darauf, dass die LCP-Ressource so früh wie möglich geladen wird.
- 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.