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. LCP misst genau genommen die Zeitspanne zwischen dem Starten des Seitenladevorgangs durch den Nutzer und dem Rendern des größten Bild- oder Textblocks im Darstellungsbereich.
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 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. 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 darauf konzentrieren, was echte Nutzer erleben, und nicht darauf, was ein labbasiertes Tool wie Lighthouse oder lokale Tests zeigen. 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 neben dem CrUX-LCP der Seite oder des Ursprungs der lokale LCP 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 oben 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 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 den gesamten Ursprung
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. Außerdem kann sie davon abhängen, wie Besucher zu diesen Seiten gelangen. 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.
Anhand der vier verschiedenen Kategorien von CrUX-Daten können Sie feststellen, ob ein LCP-Problem spezifisch für diese Seite oder ein allgemeineres Problem auf Websiteebene ist. 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 Beginn der Navigation des Besuchers zu einer Seite (z. B. Klicken auf einen Link) und dem Empfang der ersten Bytes des HTML-Dokuments. 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. 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 viel Arbeit erforderlich ist, um aussagekräftige Inhalte zu rendern. Dies 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-Bereich von PageSpeed Insights finden Sie einige Tipps zur Verbesserung des LCP. Prüfen Sie zuerst, ob der angegebene LCP weitgehend mit den von CrUX bereitgestellten realen Nutzerdaten ü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 den 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 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 Zeiträume, aus denen sich der LCP zusammensetzt:
Mit diesen Teilbereichen beschäftigen wir uns als Nächstes.
LCP-Aufschlüsselung
Die LCP-Optimierung kann eine komplexere Aufgabe sein, wenn PageSpeed Insights keine Antwort darauf liefert, wie Sie diesen Messwert verbessern können. Bei komplexen Aufgaben ist es im Allgemeinen besser, sie in kleinere, überschaubarere Aufgaben aufzuteilen und jede davon getrennt anzugehen.
In diesem Abschnitt wird eine Methode vorgestellt, mit der sich der LCP in seine wichtigsten Teilkomponenten unterteilen lässt. Anschließend werden konkrete Empfehlungen und Best Practices zur Optimierung der einzelnen Teile präsentiert.
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)
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 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, können Sie die gesamte LCP-Zeit in die folgenden Teilbereiche unterteilen:
- 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 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.
- 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.
Die LCP jeder Seite besteht aus diesen vier Unterkategorien. Zwischen ihnen gibt es keine Lücke oder Überschneidung und sie summieren sich zur vollständigen 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. Es ist jedoch auch wichtig, dass Sie 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:
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, dass Sie alle diese Teilelemente 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.
Von den vier Unterteilen enthalten zwei das Wort „Verzögerung“ im 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. Wenn du aber in einem der „Verzögerungs“-Abschnitte viel unnötige Zeit verbringst, wird es sehr schwierig sein, das Ziel von 2,5 Sekunden konstant zu erreichen.
So können Sie sich die Aufschlüsselung der LCP-Zeit vorstellen:
- Der überwiegende 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 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. Mit anderen Worten: Wenn die LCP-Ressource später als die erste Ressource geladen wird, besteht Optimierungspotenzial.
Im Allgemeinen gibt es zwei Faktoren, die sich darauf auswirken, wie schnell eine LCP-Ressource geladen werden kann:
- 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 durch Scannen der HTML-Dokumentantwort finden:
- 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, der zum Rendern eine Webschriftart benötigt. Die Schriftart wird im HTML-Markup mit
<link rel="preload">oder über einenLink-Header geladen.
Hier sind einige Beispiele, in denen die LCP-Ressource nicht durch das Scannen der HTML-Dokumentantwort gefunden werden kann:
- Das LCP-Element ist ein
<img>, das der Seite mit JavaScript dynamisch hinzugefügt wird. - Das LCP-Element wird mit einer JavaScript-Bibliothek verzögert geladen, die seine
src- odersrcset-Attribute ausblendet (oft 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. Das bedeutet in der Regel, dass Netzwerkanfragen abgeschlossen werden müssen, bevor die LCP-Ressource gefunden 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. 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. Das kann passieren, wenn die Prioritätsheuristik des Browsers für das Vorladen nicht erkennt, dass die Ressource wichtig ist, oder wenn andere Ressourcen als wichtiger eingestuft werden.
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 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. 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 Ihre Netzwerkabfolge so aussehen (die LCP-Ressource beginnt gleichzeitig mit der ersten 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 nicht sofort nach dem Laden der Ressource gerendert werden kann, ist, dass das Rendering aus einem anderen Grund blockiert wird:
- 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 beschrieben, wie Sie die häufigsten Ursachen für unnötige Verzögerungen beim Rendern von Elementen beheben.
Rendering-blockierende Stylesheets reduzieren oder inline einfügen
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 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, das Problem zu beheben:
- das Stylesheet inline in den HTML-Code einfügen, um die zusätzliche Netzwerkanfrage zu vermeiden, oder
- 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 das Laden länger dauert als die LCP-Ressource, ist es wahrscheinlich kein guter Kandidat für das Einbetten.
In den meisten Fällen lässt sich das Blockieren des Renderings des LCP-Elements durch das Stylesheet am besten verhindern, indem die Größe des Stylesheets so reduziert wird, dass 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 minimieren und komprimieren: Reduzieren Sie die Übertragungsgröße für wichtige Stile so weit wie möglich.
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 (SSR) wird die clientseitige Anwendungslogik auf dem Server ausgeführt und 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 ist die statische Websitegenerierung (SSG) oder das Vorab-Rendering. 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. Das bedeutet, dass selbst wenn Ihre Bildressource vollständig heruntergeladen wurde, möglicherweise noch gewartet werden muss, bis die Ausführung eines anderen Scripts abgeschlossen ist, bevor das Bild 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.
- Verringern 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 Anleitungen erfahren Sie ausführlich, wie Sie die Größe von:
- 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
Auch wenn Sie die Größe der Ressource und die Entfernung, die sie zurücklegen muss, reduziert haben, kann das Laden einer Ressource sehr 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 im Allgemeinen laden, kann sich das auf die Geschwindigkeit auswirken, mit der 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 dann nicht im Cache gespeichert werden können. In einigen Fällen kann es aufgrund der zusätzlichen Dekodierungskosten zu längeren Renderverzögerungen kommen.
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 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 alle nachfolgenden Schritte 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 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 bis zum Ursprungsserver weitergeleitet werden müssen. Das kann passieren, wenn Besucher eindeutige URL-Parameter für Analysen verwenden, auch wenn sie nicht zu verschiedenen Seiten führen.
In diesem Leitfaden finden Sie konkrete Informationen zur Optimierung des TTFB.
LCP-Aufschlüsselung 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 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 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.
Die Optimierung der LCP lässt sich grob in vier Schritte unterteilen:
- 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.