In unserem früheren Beitrag sind wir schon auf die Auswirkungen des Google Updates zu den Core Web Vitals eingegangen. Nun gehen wir auf den ersten der drei einzelnen Teil-Aspekte ein, den Largest Contentful Paint (LCP).

In ihrem eigenen Blog beschreiben die Google-Entwickler, was der LCP ist, wie er sich auf das Ranking der Website auswirkt und wie man ihn verbessern kann. Mit dem Largest Contentful Paint (LCP) ist die Ladezeit gemessen, die vergeht, bis das größte Content-Element einer Seite geladen wurde, und dabei gleichzeitig auch auf dem Bildschirm sichtbar ist. Der Begriff „Largest“ bezieht sich dabei nicht auf die Download-Größe des Elements, sondern auf die Größe, die dieses Element auf dem sichtbaren Bildschirm einnimmt. Das können Bilder, Videos, Text-Blöcke oder Elemente mit einem Hintergrund-Image sein. Zum Beispiel zählen dazu Header-Bilder, Logos oder Willkommens-Videos. Bilder im Footer zählen nicht dazu, will diese ja nicht beim Laden sofort zu sehen sind.

Für den LCP sind Werte bis 2,5 Sekunden gut, zwischen 2,5 und 4 Sekunden verbesserungswürdig – und alles ab 4 Sekunden ein schlechter Wert. Welches das größte Content-Element einer Seite ist, entscheidet sich je nach Ladestatus der Seite – denn meist wird das größte Element auch am Schluss geladen.

Zu Beginn der Umsetzungsphase sind jedoch nicht alle Elemente davon betroffen, wohl um erste Erfahrungswerte zu sammeln. Im Laufe der Zeit werden sie dann sicherlich mit aufgenommen. Für den Anfang gezählt werden

• Bildelemente (<img>)
• Bildelemente, die innerhalb von SVG-Code eingebettet sind (<image>). <svg>-Elemente selbst sind aktuell davon ausgenommen
• Thumbnail-Grafiken von Videoelementen (<video>)
• Hintergrundbilder, die mittels CSS geladen werden (background: url(„example.png“))
• Block-Level-Elemente, die viel Text enthalten. Zu den Blockelementen gehören zum Beispiel Paragrafen (<p>), Überschriften (<h1>, <h2> usw.) oder Listen (<ol>, <ul>)

Mögliche Problemfelder:

Langsame Antwortzeit des Servers

Je länger der Browser benötigt, um Content vom Server zu empfangen, desto länger dauert dann auch der Seitenaufbau. Google empfiehlt daher, statt einer kompletten HTML-Datei lieber ein Framework zu verwenden, dass die Inhalte dynamischer an den Browser sendet. Auch wird dazu geraten, die Inhalte über ein Content Delivery Network (CDN) zu leiten, damit die Aufrufe von den jeweils nächstgelegenen Servern bedient werden.

JavaScript und CSS-Stylesheets verzögern das Laden

Bevor der Browser ein Content-Element für den Nutzer darstellen kann, muss das HTML in ein Document Object Model (DOM) übersetzt werden. Allerdings stoppt diese Übersetzung jedes Mal, wenn JavaScripte oder CSS-Stylesheets geladen werden müssen. Hier empfiehlt Google, CSS oder JavaScripte zu minimieren, nicht-kritische Styles oder JS zu verschieben und kritisches CSS zu inlinen.

Ressourcen laden zu langsam

Bilder, Videos oder Content-Blöcke können häufig zu Verzögerungen führen. Daher empfiehlt Google, Bilder in tatsächlich passenden Größen anzubieten und etwa neuere Dateiformate mit höherer Kompression zu nutzen. Auch können JavaScript und CSS-Elemente komprimiert werden. Auch Adaptive Serving kann helfen, so kann z.B. festgelegt werden, dass bei Verbindungsgeschwindigkeiten unterhalb von 4G anstelle eines Videos nur ein kleines Bild geladen wird.

Client-Side Rendering 

Auch Client-Side Rendering, bei dem die Seiten mithilfe von JavaScript-Frameworks wie React oder Angular direkt im Browser gerendert werden, sei eine gute Möglichkeit, den Largest Contentful Paint schneller für den Nutzer darzustellen. 

Was es mt den beiden anderen Teil-Aspekten der Core Web Vitals auf sich hat, erklären wir in den nächsten beiden Beiträgen. Im nächsten Artikel geht es dann um den First Input Delay (FID).