Eine detaillierte Anleitung zum Aufschlüsseln des LCP und Identifizierung wichtiger verbesserungswürdiger Bereiche
Der Largest Contentful Paint (LCP) ist einer der drei Core Web Vitals-Messwerte. Er gibt an, wie schnell der Hauptinhalt einer Webseite geladen wird. LCP misst insbesondere die Zeit zwischen dem Laden der Seite durch den Nutzer bis zum Rendern des größten Bilds oder Textblocks im Darstellungsbereich.
Für eine gute Nutzerfreundlichkeit sollten Websites einen LCP-Wert von maximal 2, 5 Sekunden für mindestens 75% der Seitenaufrufe anstreben.
Eine Reihe von Faktoren kann beeinflussen, wie schnell der Browser eine Webseite laden und rendern kann. Verzögerungen haben einen erheblichen Einfluss auf den LCP.
Es kommt selten vor, dass eine schnelle Korrektur eines einzelnen Bereichs einer Seite zu einer bedeutenden Verbesserung des LCP führt. Zur Verbesserung des LCP müssen Sie sich den gesamten Ladevorgang ansehen und darauf achten, dass jeder Schritt optimiert ist.
Informationen zum LCP-Messwert
Vor der Optimierung des LCP sollten Entwickler herausfinden, ob und in welchem Umfang sie ein LCP-Problem haben.
Der LCP kann mit verschiedenen Tools gemessen werden, die nicht alle auf dieselbe Weise messen. Um den LCP echten 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 können Ihnen eine Fülle von Informationen liefern, um den LCP zu erklären und zu verbessern. Beachten Sie jedoch, dass Labortests allein nicht unbedingt repräsentativ für Ihre tatsächlichen Nutzererfahrungen sind.
LCP-Daten, die auf echten Nutzern basieren, können über RUM-Tools (Real User Monitoring), die auf einer Website installiert sind, oder den Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) zur Verfügung gestellt werden, der für Millionen von Websites anonyme Daten von echten Chrome-Nutzern erfasst.
CrUX-LCP-Daten von PageSpeed Insights verwenden
PageSpeed Insights bietet im oberen Abschnitt mit der Überschrift Ermitteln, was Ihre tatsächlichen Nutzer erleben Zugriff auf CrUX-Daten. Detailliertere Lab-basierte Daten finden Sie im unteren Abschnitt Leistungsprobleme diagnostizieren. Wenn für Ihre Website CrUX-Daten verfügbar sind, konzentrieren Sie sich immer zuerst auf die echten Nutzerdaten.
PageSpeed Insights zeigt bis zu vier verschiedene CrUX-Daten an:
- Mobile Daten für This URL
- Desktop-Daten für This URL
- Mobile Daten für den gesamten Ursprung
- Desktopdaten für den gesamten Origin
Sie können diese mit den Steuerelementen oben und rechts oben in diesem Abschnitt aktivieren oder deaktivieren. Wenn für eine URL nicht genügend Daten für die Anzeige auf URL-Ebene, aber für den Ursprung vorhanden sind, 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. Er kann sich auch darauf auswirken, wie Besucher zu diesen Seiten navigieren. Startseiten werden in der Regel von neuen Nutzern besucht und sind daher oft „kalt“ ohne zwischengespeicherten Inhalt geladen. Daher sind die langsamsten Seiten einer Website oft die langsamsten Seiten.
Wenn Sie sich die vier verschiedenen Kategorien von CrUX-Daten ansehen, können Sie besser nachvollziehen, ob das LCP-Problem spezifisch für diese Seite oder ein allgemeines websiteweites Problem ist. Außerdem sehen Sie, bei welchen Gerätetypen LCP-Probleme auftreten.
Zusätzliche PageSpeed Insights-CrUX-Messwerte 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.
TTFB gibt die Zeit an, während der ein Besucher mit der Navigation zu einer Seite beginnt (z. B. durch Klicken auf einen Link), bis die ersten Bytes des HTML-Dokuments empfangen wurden. Eine hohe TTFB kann das Erreichen eines 2, 5-Sekunden-LCP-Wertes schwierig oder sogar unmöglich machen.
Eine hohe TTFB kann an mehreren Serverweiterleitungen, Besuchern, die weit vom nächsten Websiteserver entfernt sind, Besuchern mit schlechten Netzwerkbedingungen oder der Unfähigkeit, zwischengespeicherten Inhalt aufgrund von Suchparametern zu verwenden, vorliegen.
Sobald das Rendern einer Seite beginnt, gibt es möglicherweise einen anfänglichen Paint (z. B. die Hintergrundfarbe) und anschließend einige Inhalte (z. B. die Kopfzeile der Website). Das Erscheinungsbild des ursprünglichen Inhalts wird per FCP gemessen. Die Differenz zwischen FCP und anderen Messwerten kann sehr deutlich sein.
Ein großer Unterschied zwischen TTFB und FCP kann darauf hindeuten, dass der Browser viele Assets herunterladen muss, die das Rendering blockieren. Es kann auch ein Zeichen dafür sein, dass viel Arbeit erforderlich ist, um aussagekräftige Inhalte zu rendern – ein klassisches Zeichen für eine Website, die stark auf clientseitiges Rendering angewiesen ist.
Ein großes Unterschied zwischen FCP und LCP weist darauf hin, dass die LCP-Ressource entweder nicht sofort für den Browser zur Priorisierung verfügbar ist (z. B. Text oder Bilder, die von JavaScript verwaltet werden, anstatt im ursprünglichen HTML-Code verfügbar zu sein) oder dass der Browser andere Aufgaben erledigt, bevor er den LCP-Inhalt anzeigen kann.
PageSpeed Insights Lighthouse-Daten verwenden
Im Lighthouse-Abschnitt von PageSpeed Insights finden Sie einige Tipps zur Verbesserung des LCP. Überprüfen Sie jedoch zuerst, ob der angegebene LCP weitgehend mit den tatsächlichen Nutzerdaten von CrUX übereinstimmt. Wenn zwischen Lighthouse und CrUX sich nicht einigen, liefert CrUX wahrscheinlich ein genaueres Bild Ihrer Nutzererfahrung. Achten Sie darauf, dass die CrUX-Daten für Ihre Seite und nicht für den gesamten Ursprung gelten, bevor Sie Maßnahmen ergreifen.
Wenn sowohl in Lighthouse als auch in CrUX LCP-Werte angezeigt werden, die verbessert werden müssen, kann der Lighthouse-Bereich hilfreiche Tipps zur Verbesserung des LCP bieten. Verwenden Sie den LCP-Filter, um nur für den LCP relevante Audits wie folgt aufzurufen:
Neben den Optimierungsmöglichkeiten finden Sie auch Diagnosedaten, die weitere Informationen zur Diagnose des Problems enthalten können. Die Diagnose Largest Contentful Paint zeigt eine nützliche Aufschlüsselung der verschiedenen Timings an, aus denen der LCP besteht:
Diese Teilabschnitte werden wir uns als Nächstes näher ansehen.
LCP-Aufschlüsselung
Die Optimierung im Hinblick auf den LCP kann eine komplexere Aufgabe sein, wenn PageSpeed Insights euch keine Antwort auf die Verbesserung dieses Messwerts liefert. Bei komplexen Aufgaben ist es im Allgemeinen besser, diese in kleinere, besser überschaubare Aufgaben zu unterteilen und jede einzeln zu behandeln.
In diesem Abschnitt wird eine Methodik vorgestellt, mit der Sie den LCP in seine wichtigsten Teilabschnitte unterteilen können. Anschließend 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 Möglichkeiten zur Verbesserung des LCP ermitteln möchten, sollten Sie sich jedoch 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, zeigen diese beiden Anfragen – insbesondere die Zeiten, zu denen die LCP-Ressource beginnt und endet –, ob deine Seite für LCP optimiert ist.
Um die LCP-Ressource zu ermitteln, können Sie Entwicklertools wie PageSpeed Insights (siehe oben), Chrome-Entwicklertools oder WebPageTest verwenden, um das LCP-Element zu bestimmen. Dort können Sie die vom Element geladene URL (gegebenenfalls auch wieder) mit einer Netzwerkabfolge aller Ressourcen abgleichen, die von der Seite geladen werden.
In der folgenden Visualisierung werden diese Ressourcen beispielsweise in einem Netzwerk-Wasserfalldiagramm bei einem typischen Seitenaufbau hervorgehoben, bei dem für das LCP-Element eine Bildanfrage zum Rendern erforderlich ist.
Bei einer gut optimierten Seite möchten Sie, dass Ihre LCP-Ressourcenanfrage so früh wie möglich mit dem Laden beginnt und das LCP-Element so schnell wie möglich gerendert wird, nachdem der Ladevorgang der LCP-Ressource abgeschlossen ist. Um zu visualisieren, ob eine bestimmte Seite diesem Prinzip folgt, kannst du die gesamte LCP-Zeit in die folgenden Unterabschnitte aufteilen:
- Time to First Byte (TTFB)
- Die Zeitspanne zwischen dem Start des Seitenaufbaus durch den Nutzer bis zum Empfang des ersten Byte der HTML-Dokumentantwort im Browser.
- Verzögerung beim Laden der Ressource
- Die Zeit zwischen der TTFB und dem Beginn des Ladens der LCP-Ressource im Browser. Wenn für das LCP-Element keine Ressourcenlast zum Rendern erforderlich ist (z. B. wenn das Element ein Textknoten ist, der mit einer Systemschrift gerendert wird), ist 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 Ressourcenlast zum Rendern erforderlich ist, ist diese Zeit 0.
- Verzögerung beim Rendern von Elementen
- Die Zeit zwischen dem Abschluss des Ladevorgangs der LCP-Ressource und dem vollständigen Rendern des LCP-Elements.
Der LCP-Wert jeder Seite besteht aus diesen vier Unterkategorien. Es gibt keine Lücken oder Überschneidungen und sie entsprechen der gesamten LCP-Zeit.
Der LCP-Wert jeder Seite kann in diese vier Unterabschnitte unterteilt werden. Es gibt keine Überschneidungen oder Lücken zwischen ihnen. Diese bilden zusammen die volle LCP-Zeit.
Bei der Optimierung des LCP ist es hilfreich, diese Teilabschnitte einzeln zu optimieren. Vergessen Sie aber nicht, dass Sie alle Kampagnen optimieren müssen. In einigen Fällen verbessert eine auf einen Teil angewendete Optimierung den LCP nicht, sondern die eingesparte Zeit wird lediglich auf einen anderen Teil verschoben.
Wenn Sie beispielsweise in der vorherigen Netzwerkabfolge die Dateigröße unseres Bildes durch mehr Komprimierung reduzieren oder in ein besseres Format wie AVIF oder WebP wechseln, wird die Ladedauer der Ressource verkürzt. Der LCP würde aber nicht verbessert werden, da die Zeit einfach in den Unterteil Element-Rendering-Verzögerung verschoben würde:
Der Grund dafür ist, dass das LCP-Element auf dieser Seite verborgen ist, bis der JavaScript-Code geladen ist, und dann alles auf einmal eingeblendet wird.
Dieses Beispiel verdeutlicht, dass Sie alle diese Teilabschnitte optimieren müssen, um die besten LCP-Ergebnisse zu erzielen.
Optimale Zeiten für Teilabschnitte
Um jeden Teil des LCP zu optimieren, ist es wichtig zu verstehen, wie diese Teilabschnitte auf einer gut optimierten Seite idealerweise aufgeschlüsselt werden.
Von den vier Teilabschnitten haben zwei Teile das Wort „Verzögerung“ im Namen. Das ist ein Hinweis darauf, dass Sie diese Zeiten so nah wie möglich an null kommen sollen. Die anderen beiden Teile sind Netzwerkanfragen, die von Natur aus einige Zeit in Anspruch nehmen.
Beachten Sie, dass diese Zeitaufschlüsselungen Richtlinien und keine strengen Regeln sind. Wenn die LCP-Zeiten auf Ihren Seiten konstant innerhalb von 2,5 Sekunden liegen, spielt es keine Rolle, wie groß die relativen Anteile sind. Wenn Sie jedoch viel unnötige Zeit in einer dieser Phasen verbringen, wird es sehr schwierig sein, das Ziel von 2,5 Sekunden dauerhaft zu erreichen.
Eine gute Aufschlüsselung der LCP-Zeit sieht so aus:
- Der Großteil der LCP-Zeit sollte für das Laden des HTML-Dokuments und der LCP-Quelle aufgewendet werden.
- Wenn eine der beiden Ressourcen vor dem LCP nicht geladen wird, kann dies verbessert werden.
Die einzelnen Teile optimieren
Da Sie nun wissen, wie die einzelnen LCP-Teilzeiten auf einer gut optimierten Seite aufgeteilt werden sollen, können Sie mit der Optimierung Ihrer eigenen Seiten beginnen.
In den nächsten vier Abschnitten finden Sie Empfehlungen und Best Practices für die Optimierung der einzelnen Teile. Sie werden der Reihe nach präsentiert, beginnend mit den Optimierungen, die wahrscheinlich die größten Auswirkungen haben.
1. Verzögerung beim Laden von Ressourcen beseitigen
Ziel in diesem Schritt ist es, dafür zu sorgen, dass die LCP-Ressource so früh wie möglich mit dem Laden beginnt. Während eine Ressource theoretisch frühestens direkt nach der TTFB beginnen könnte, kann es in der Praxis immer eine gewisse Verzögerung geben, bevor Browser tatsächlich mit dem Laden von Ressourcen beginnen.
Als Faustregel gilt: Der Ladevorgang Ihrer LCP-Ressource sollte mit der ersten von dieser Seite geladenen Ressource beginnen. Oder anders ausgedrückt: Wenn die LCP-Ressource erst nach der ersten zu laden beginnt, besteht die Möglichkeit einer Verbesserung.
Im Allgemeinen gibt es zwei Faktoren, die beeinflussen, wie schnell eine LCP-Ressource geladen werden kann:
- Wenn die Ressource erkannt wird.
- Die Priorität der Ressource.
Nach der Ressourcenerkennung optimieren
Damit die LCP-Ressource so früh wie möglich geladen wird, muss die Ressource in der ersten HTML-Dokumentantwort vom Preload-Scanner des Browsers erkannt werden. In den folgenden Fällen kann der Browser die LCP-Ressource beispielsweise erkennen, indem er die Antwort des HTML-Dokuments scannt:
- Das LCP-Element ist ein
<img>-Element und seinesrc- odersrcset-Attribute sind im ersten 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. Die Schriftart 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 nicht durch Scannen der HTML-Dokumentantwort erkannt werden kann:
- Das LCP-Element ist ein
<img>, das der Seite dynamisch mithilfe von JavaScript hinzugefügt wird. - Das LCP-Element wird langsam mit einer JavaScript-Bibliothek geladen, die die
src- odersrcset-Attribute (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, bevor die LCP-Ressource erkannt und geladen werden kann. In der Regel muss dafür auf den Abschluss der Netzwerkanfragen gewartet werden. Das ist nie optimal.
Um unnötige Verzögerungen beim Laden der Ressource zu vermeiden, sollte Ihre LCP-Ressource in der HTML-Quelle sichtbar sein. Falls 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
Selbst wenn die LCP-Ressource über das HTML-Markup erkannt werden kann, wird der Ladevorgang möglicherweise noch nicht bei der ersten Ressource gestartet. Dies kann passieren, wenn die Prioritätsheuristik des Scanners vor dem Laden des Browsers nicht erkennt, dass die Ressource wichtig ist, oder wenn festgestellt wird, dass andere Ressourcen wichtiger sind.
Du kannst beispielsweise dein LCP-Bild mit HTML verzögern, wenn du für das <img>-Element loading="lazy" festlegst. Wenn Sie Lazy Loading verwenden, wird die Ressource erst geladen, nachdem das Layout bestätigt hat, dass sich das Bild im Darstellungsbereich befindet. Der Ladevorgang kann daher später beginnen als sonst.
Auch ohne Lazy Loading werden Bilder von Browsern nicht anfangs mit der höchsten Priorität geladen, da sie keine Ressourcen sind, die das Rendering blockieren. Mit dem Attribut fetchpriority für Ressourcen, die von einer höheren Priorität profitieren könnten, können Sie dem Browser mitteilen, welche Ressourcen am wichtigsten sind:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Wenn du glaubst, dass es sich dabei wahrscheinlich um das LCP-Element deiner Seite handelt, empfiehlt es sich, fetchpriority="high" für ein <img>-Element festzulegen. Wenn Sie jedoch für mehr als ein oder zwei Bilder eine hohe Priorität festlegen, ist die Prioritätseinstellung bei der Reduzierung des LCP-Werts nicht hilfreich.
Sie können auch die Priorität von Bildern verringern, die möglicherweise zu Beginn der Dokumentantwort angezeigt werden, 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 bestimmten Ressourcen eine geringere Priorisierung gewähren, können Ressourcen, die sie stärker benötigen, mehr Bandbreite zur Verfügung stellen – aber seien Sie dabei mit Bedacht. Prüfen Sie immer die Ressourcenpriorität in den Entwicklertools und testen Sie Änderungen mit Labor- und Field Tools.
Nachdem Sie die Priorität und die Erkennungszeit Ihrer LCP-Ressourcen optimiert haben, sollte Ihre Netzwerkabfolge so aussehen (die LCP-Ressource beginnt zeitgleich mit der ersten Ressource):
2. Verzögerung beim Rendern von Elementen beseitigen
Mit diesem Schritt soll dafür gesorgt werden, dass das LCP-Element sofort gerendert werden kann, nachdem die Ressource geladen wurde, und zwar unabhängig davon, wann das der Fall ist.
Der Hauptgrund dafür, dass das LCP-Element unmittelbar nach dem Laden der Ressource nicht gerendert werden könnte, ist, dass das Rendering aus einem anderen Grund blockiert ist:
- Das Rendern der gesamten Seite wird aufgrund von Stylesheets oder synchronen Skripts im
<head>blockiert, die noch geladen werden. - Der Ladevorgang der LCP-Ressource ist abgeschlossen, das LCP-Element wurde dem DOM jedoch noch nicht hinzugefügt, da noch auf das Laden von JavaScript-Code gewartet wird.
- Das Element wird durch anderen Code ausgeblendet, z. B. eine A/B-Testbibliothek, die noch bestimmt, in welchem Test sich der Nutzer befinden soll.
- Der Hauptthread wird aufgrund langer Aufgaben blockiert und das Rendern muss warten, bis diese langen Aufgaben abgeschlossen sind.
In den folgenden Abschnitten wird erläutert, wie Sie mit den häufigsten Ursachen für unnötige Verzögerungen beim Rendern von Elementen umgehen können.
Stylesheets reduzieren oder inline das Rendering blockieren
Aus dem HTML-Markup geladene Stylesheets blockieren das Rendern des gesamten nachfolgenden Inhalts, was gut ist, da Sie im Allgemeinen kein HTML ohne Formatierung rendern sollten. Wenn das Stylesheet jedoch so groß ist, dass das Laden deutlich länger dauert als die LCP-Ressource, dann verhindert es, dass das LCP-Element gerendert wird, auch wenn die Ressource fertig geladen ist, wie in diesem Beispiel gezeigt:
Sie haben folgende Möglichkeiten, das Problem zu beheben:
- Fügen Sie das Stylesheet direkt in den HTML-Code ein, um die zusätzliche Netzwerkanfrage zu vermeiden.
- die Größe des Stylesheets.
Im Allgemeinen wird die Inline-Anzeige nur dann empfohlen, wenn Ihr Stylesheet klein ist, da Inline-Inhalte im HTML-Code nicht von der Zwischenspeicherung 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 Inline-Element.
In den meisten Fällen lässt sich am besten sicherstellen, dass das Stylesheet das Rendering des LCP-Elements nicht blockiert, indem Sie seine Größe reduzieren, sodass es kleiner als die LCP-Ressource ist. So wird sichergestellt, dass es bei den meisten Besuchen nicht zu einem Engpass kommt.
Hier sind einige Empfehlungen, wie Sie die Größe des Stylesheets reduzieren können:
- Nicht verwendeten CSS-Code entfernen: Verwenden Sie die Chrome-Entwicklertools, um CSS-Regeln zu finden, die nicht verwendet werden und möglicherweise entfernt oder aufgeschoben werden können.
- Nicht kritisches CSS zurückstellen: Teilen Sie Ihr Stylesheet in Stile auf, die für den anfänglichen Seitenaufbau erforderlich sind, und in Stile, die verzögert geladen werden können.
- CSS reduzieren und komprimieren: Bei wichtigen Stilen sollten Sie die Übertragungsgröße so weit wie möglich reduzieren.
JavaScript zurückstellen oder inline rendern, das das Rendering blockiert
Es ist fast nie erforderlich, synchrone Skripts (Skripts ohne das Attribut async oder defer) in die <head> Ihrer Seiten einzufügen, denn dies wirkt sich fast immer negativ auf die Leistung aus.
Wenn JavaScript-Code so früh wie möglich beim Seitenaufbau ausgeführt werden muss, empfiehlt es sich, ihn inline einzufügen, damit das Rendering nicht durch Warten auf eine andere Netzwerkanfrage verzögert wird. Wie bei Stylesheets sollten Sie jedoch nur Inline-Skripts verwenden, wenn diese 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 Ihre clientseitige Anwendungslogik auf dem Server ausgeführt und auf Anfragen von HTML-Dokumenten wird mit dem vollständigen HTML-Markup geantwortet.
Bei der Optimierung des LCP haben SSR zwei Hauptvorteile:
- Ihre Bildressourcen sind über die HTML-Quelle auffindbar (wie in Schritt 1 oben beschrieben).
- Für die Darstellung Ihrer Seiteninhalte sind keine zusätzlichen JavaScript-Anfragen erforderlich.
Der größte Nachteil von SSRs ist, dass dadurch zusätzliche Serververarbeitungszeit erforderlich ist, was Ihre TTFB verlangsamen kann. In der Regel lohnt sich dies jedoch, da Sie die Verarbeitungszeiten der Server im Gegensatz zu den Netzwerk- und Gerätefunktionen Ihrer Nutzer selbst steuern können.
Eine ähnliche Option wie bei der SSR wird als statische Websitegenerierung (SSG) oder Pre-Rendering bezeichnet. Bei diesem Vorgang werden Ihre HTML-Seiten nicht on demand, sondern in einem Build-Schritt generiert. Wenn Pre-Rendering mit Ihrer Architektur möglich ist, ist es im Allgemeinen in Bezug auf die Leistung besser geeignet.
Lange Aufgaben aufteilen
Auch wenn Sie den Hinweis von vorhin befolgt haben und Ihr JavaScript-Code weder das Rendering blockiert noch für das Rendern Ihrer Elemente verantwortlich ist, kann er dennoch den LCP verzögern.
Am häufigsten geschieht dies, wenn Seiten große JavaScript-Dateien laden, die im Hauptthread des Browsers geparst und ausgeführt werden müssen. Selbst wenn Ihre Bildressource vollständig heruntergeladen wurde, kann sie also erst gerendert werden, wenn ein nicht zusammenhängendes Skript vollständig ausgeführt wurde.
Heutzutage rendern alle Browser Bilder im Hauptthread. Das bedeutet, dass alles, was den Hauptthread blockiert, auch zu unnötigen Verzögerungen beim Rendern von Elementen führen kann.
3. Ladedauer der Ressourcen verkürzen
Mit diesem Schritt soll die Zeit reduziert werden, die für die Übertragung der Byte der Ressource über das Netzwerk auf das Gerät des Nutzers benötigt wird. Im Allgemeinen gibt es dazu drei Möglichkeiten:
- Verringern Sie die Größe der Ressource.
- Reduzieren Sie die Entfernung, die die Ressource zurücklegen muss.
- Reduzieren Sie Konflikte bezüglich der Netzwerkbandbreite.
- Die Netzwerkzeit wird vollständig eliminiert.
Größe der Ressource reduzieren
Die LCP-Ressource einer Seite (falls vorhanden) ist entweder ein Bild oder eine Webschrift. In den folgenden Leitfäden erfahren Sie, wie Sie die Größe beider Elemente reduzieren können:
- Optimale Bildgröße bereitstellen
- Moderne Bildformate verwenden
- Bilder komprimieren
- Schriftgröße im Web reduzieren
Reduzieren Sie die Strecke, die die Ressource zurücklegen muss
Sie können nicht nur die Größe einer Ressource reduzieren, sondern auch die Ladezeiten reduzieren, indem Sie Ihre Server so nah wie möglich an Ihren Nutzern platzieren. Am besten lässt sich das mit einem Content Delivery Network (CDN) umsetzen.
Besonders Bild-CDNs sind besonders hilfreich, weil sie nicht nur die Entfernung, die die Ressource zurücklegen muss, reduzieren, sondern auch die Größe der Ressource reduzieren. Alle früheren Empfehlungen zur Größenreduzierung werden automatisch implementiert.
Konflikte bezüglich der Netzwerkbandbreite reduzieren
Auch wenn Sie die Größe der Ressource und die zurückgelegte Entfernung reduziert haben, kann das Laden einer Ressource sehr lange dauern, wenn viele andere Ressourcen gleichzeitig geladen werden. Dieses Problem wird als Netzwerkkonflikt bezeichnet.
Wenn Sie für Ihre LCP-Ressource einen hohen fetchpriority festgelegt haben und so bald wie möglich mit dem Laden begonnen haben, wird der Browser versuchen, zu verhindern, dass Ressourcen mit niedrigerer Priorität mit ihr konkurrieren. Wenn Sie jedoch viele Ressourcen mit einem hohen fetchpriority laden oder allgemein viele Ressourcen laden, kann sich dies darauf auswirken, wie schnell die LCP-Ressource geladen wird.
Netzwerkzeit vollständig eliminieren
Die beste Möglichkeit, die Ressourcenlast zu verkürzen, besteht darin, das Netzwerk vollständig vom Prozess zu streichen. Wenn Sie für Ihre Ressourcen eine effiziente Cache-Kontrollrichtlinie verwenden, werden die Ressourcen von Besuchern, die sie ein zweites Mal anfordern, aus dem Cache bereitgestellt. Dadurch wird die Ladedauer der Ressourcen praktisch auf null gesetzt.
Wenn es sich bei Ihrer LCP-Ressource um eine Webschriftart handelt, sollten Sie zusätzlich zur Reduzierung der Schriftgröße für das Web auch überlegen, ob Sie das Rendering der geladenen Webschriftarten blockieren müssen. Wenn Sie für font-display einen anderen Wert als auto oder block festlegen, ist der Text während des Ladens 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. Dadurch wird auch die zusätzliche Netzwerkanfrage beseitigt. Die Verwendung von Daten-URLs bringt jedoch Einschränkungen mit sich, da die Ressourcen dann nicht im Cache gespeichert werden können. In einigen Fällen kann das aufgrund der zusätzlichen Kosten für die Decodierung zu längeren Renderingverzögerungen führen.
4. Zeit bis zum ersten Byte verkürzen
Das Ziel dieses Schritts ist es, die ursprüngliche HTML so schnell wie möglich zu liefern. Dieser Schritt wird zuletzt aufgeführt, da Entwickler oft die geringste Kontrolle darüber haben. Sie ist jedoch auch einer der wichtigsten Schritte, da sie sich direkt auf jeden nachfolgenden Schritt auswirkt. Im Frontend kann nichts passieren, bis das Backend das erste Byte des Inhalts ausliefert. Alles, was Sie unternehmen können, um Ihre TTFB zu beschleunigen, verbessert also auch alle anderen Lastmetriken.
Eine häufige Ursache für eine langsame TTFB für eine ansonsten schnelle Website sind Besucher, die über mehrere Weiterleitungen gelangen, z. B. über Anzeigen oder gekürzte Links. Minimieren Sie immer die Anzahl der Weiterleitungen, die ein Besucher warten 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. Dies kann passieren, wenn Besucher zu Analysezwecken eindeutige URL-Parameter verwenden, die nicht zu unterschiedlichen Seiten führen.
Genaue Anleitungen zur Optimierung der TTFB finden Sie im Leitfaden zur Optimierung von TTFB.
LCP-Aufschlüsselung in JavaScript beobachten
Die Zeitinformationen für alle zuvor besprochenen LCP-Teilabschnitte sind in JavaScript über eine Kombination der folgenden Performance 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 sie bei der Fehlerbehebung und Optimierung zu unterstützen.
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 Balken hinzuzufügen.
Visualisierungen im Track Timing sind besonders hilfreich, wenn sie neben den Tracks Netzwerk und Hauptthread betrachtet werden, da Sie auf einen Blick sehen können, was sonst noch auf der Seite während dieser Zeitspannen passiert.
Du kannst nicht nur die LCP-Teilabschnitte im Timing-Track visualisieren, sondern auch mithilfe von JavaScript berechnen, wie viel Prozent der einzelnen Teilabschnitte an der gesamten LCP-Zeit ausmachen. Anhand dieser Informationen können Sie feststellen, ob Ihre Seiten die oben beschriebenen empfohlenen Aufschlüsselungen in Prozent erfüllen.
Dieser Screenshot zeigt ein Beispiel, bei dem die Gesamtzeit jedes LCP-Teilabschnitts sowie der Prozentsatz der gesamten LCP-Zeit in der Konsole protokolliert werden.
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 die lokale Fehlerbehebung verwenden oder ihn so ändern, dass die Daten an einen Analyseanbieter gesendet werden. So erhalten Sie einen besseren Überblick über die Aufschlüsselung des LCP-Werts auf Ihren Seiten für echte Nutzer.
LCP-Aufschlüsselungen mit der Web Vitals-Erweiterung im Blick behalten
Die Web Vitals-Erweiterung protokolliert die LCP-Zeit, das LCP-Element und diese vier Unterabschnitte in der Konsole, damit du dir diese Aufschlüsselung ganz einfach ansehen kannst.
Zusammenfassung
Der LCP ist komplex und sein Zeitplan kann von einer Reihe von Faktoren beeinflusst werden. Wenn Sie jedoch bedenken, dass bei der Optimierung des LCP in erster Linie die Last der LCP-Ressource optimiert werden soll, kann dies erheblich vereinfachen.
Grundsätzlich kann die Optimierung des LCP in vier Schritten zusammengefasst werden:
- Sorgen Sie dafür, dass die LCP-Ressource so früh wie möglich mit dem Laden beginnt.
- Sorgen Sie dafür, dass das LCP-Element gerendert werden kann, sobald die Ressource geladen ist.
- Reduzieren Sie die Ladezeit der LCP-Ressource so weit wie möglich, ohne Abstriche bei der Qualität zu machen.
- Stellen Sie das ursprüngliche HTML-Dokument so schnell wie möglich bereit.
Wenn Sie diese Schritte auf Ihren Seiten ausführen können, sollten Sie sicher sein können, dass Sie Ihren Nutzern ein optimales Ladeerlebnis bieten, was sich in Ihren tatsächlichen LCP-Werten widerspiegeln sollte.