Dein wichtigster Touchpoint zur Digitalbranche.
Dein wichtigster Touchpoint zur Digitalbranche.
SEO - Suchmaschinenoptimierung
Core Web Vitals: 5 Tipps zur Optimierung für den Mobile First Index
© Solen Feyissa

Core Web Vitals: 5 Tipps zur Optimierung für den Mobile First Index

Ein Gastbeitrag von Eugen Grinschuk | 21.12.20

Alle sprechen von PageSpeed und deren Optimierung. User Experience ist ebenfalls ein Begriff. Doch, was ist die Page Experience? Was sind die Core Web Vitals? Und warum sind sie so wichtig?

Was ist die Page Experience? Und was zählt dazu?

Die Page Experience ist die Erfahrung der User mit deiner Webseite. Das heißt, Google bewertet verschiedene Aspekte bezüglich der Nutzererfahrung. Denn Google möchte den Usern möglichst gute und relevante Ergebnisse liefern. Hierzu gehört auch die Erfahrung mit der Webseite. Durch die Core Web Vitals möchte Google die Sicherheit und die positive Nutzererfahrung mit der Web-Seite garantieren – auch für diejenigen, die mobil unterwegs sind. 

Zu den Core Web Vitals, die Google im Mai 2020 eingeführt hat, gehören: 

  • Ladezeit (Largest Contentful Paint (LCP) – Core Web Vitals)
  • Interaktivität (First Input Delay (FID) – Core Web Vitals)
  • Visuelle Stabilität (Cumulative Layout Shift (CLS) – Core Web Vitals)
  • Mobilfreundlichkeit einer URL
  • Sicherer und sauberer Website Code (Safe Browsing)
  • Nutzung der HTTPS-Verschlüsselung
  • Verzicht auf Interstitial-Nutzung (aggressive Unterbrechungen)

Die eingeführten Core Web Vitals sind nicht unbedingt neue Ranking-Faktoren, sondern sie sind vielmehr kumuliert, aus den bisherigen Ranking-Signalen. Auch wenn Google sich stark zurückhält bezüglich der Ranking-Faktoren, werden einige doch offiziell angekündigt, die vermutlich auch in die Page Experience einfließen werden. Ferner werden die Ranking-Faktoren bezüglich HTTPS-Verschlüsselung, Mobile PageSpeed sowie die mobile Nutzerfreundlichkeit offiziell als Faktor im Suchalgorithmus angekündigt. 

Was sind die Core Web Vitals?

Bei den Core Web Vitals handelt es sich dabei um neue Bezeichnungen aus den kumulierten und bereits bestehenden Rankingfaktoren:

  • Ladezeit (Largest Contentful Paint (LCP) – Core Web Vitals)
  • Interaktivität (First Input Delay (FID) – Core Web Vitals)
  • Visuelle Stabilität (Cumulative Layout Shift (CLS) – Core Web Vitals)

Sie sollten als eine Art Kernmetrik für die Bewertung der Performance von Web-Seiten gelten. Google möchte die Metriken jährlich hinsichtlich der Nutzerfreundlichkeit und des Nutzerverhaltens evaluieren und gegebenenfalls anpassen. 

Largest Contentful Paint (LCP) – Was ist das?

Der Largest Contentful Paint (LCP) gibt die Zeit an, bis das größte Element gerendert wurde, welches dann auch schlussendlich auf dem Bildschirm sichtbar ist. Das können große Bilder im Text sein, Logos, Header-Bilder, Videos oder andere große Elemente. Wichtig ist, dass nur diejenigen Elemente gewertet werden, die für den User auch sichtbar sind. 

Wenn du eine große Datei hast, welche zum Schluss geladen wird und diese befindet sich im Header oder im sichtbaren Bereich (above the fold), dann wird dies von Lighthouse gezählt. Befindet sich diese große Datei allerdings im Footer, dann wird dies Lighthouse nicht werden, weil es für den User nicht auf den ersten Blick sichtbar ist, bis er hinunterscrollt. Im ersten Step soll sich die API auf ein paar wenige HTML Elemente beschränken, vermutlich auch, um die ganzen Metriken zuerst auf deren Tauglichkeit zu testen.

Laut Google Developers werden die folgenden Elemente in LCP berücksichtigt:

  • Bildelemente
  • Bildelemente, die innerhalb von SVG-Code eingebettet sind. Die Elemente selbst sind im Moment noch vom LCP ausgenommen
  • Thumbnail-Grafiken von Videos
  • Hintergrundbilder, die via CSS geladen werden
  • Block-Level-Elemente, die viel Text enthalten. Hierzu zählen zum Beispiel Paragrafen, Überschriften und auch Listen

Largest Contentful Paint (LCP) – die Optimierung

Wie kannst du nun, nachdem du weißt was der LCP genau ist, diesen optimieren beziehungsweise die Zeit bis zum Largest Contentful Paint reduzieren? An den folgenden Bereichen kannst du arbeiten:

  • Die Antwortzeit des Servers optimieren. Notfalls über einen Wechsel zu einem besseren beziehungsweise schnelleren Webhoster wechseln (SSD Webhosting)
  • Die Ladezeit von Ressourcen wie Bilder und Videos optimieren. Die Bilder kannst du in der tatsächlich benötigten Größe hochladen und vorher noch komprimieren (zum Beispiel mit dem WordPress Plugin: Shortpixel oder via Web tinypng). Für Videos und Bilder könntest du ein CDN verwenden
  • Kritisches CSS kannst du „inline“ einbinden, nicht kritisches CSS via defer laden lassen. Auch hier gibt es für WordPress Plugins wie zum Beispiel Autoptimize. Den kritischen CSS Pfad kannst du zum Beispiel via Web generieren lassen
  • Auch vorladen, mittels rel=“preload“. Hier könnten es ebenfalls Bilder, Videos, Skripte oder CSS-Dateien sein, die vorgeladen werden sollten. Als Plugin könnte hier ebenfalls Autoptimize eingesetzt werden

Ein guter Score für LCP ist unter 2,5 Sekunden. Zwischen 2,5 und 4 Sekunden ist eine Optimierung zu empfehlen und über 4 Sekunden ist eine Optimierung dringend notwendig. Eine sehr ausführliche Hilfe bietet auch Google im Bereich LCP Optimierung an.


First Input Delay (FID) – Was ist das?

Wie der Name schon sagt, handelt es sich beim First Input Delay (FID) um die Eingangsverzögerung. Damit wird die Reaktionsfähigkeit von Webseiten gemessen. Ist dieser Wert niedrig, heißt es für Google, dass die Seite verwendbar ist und die Nutzererfahrung damit vermutlich höher ausfällt. Das bedeutet, dass der First Input Delay die Zeit zwischen der ersten Interaktion des Benutzers (zum Beispiel Klick auf Link, Button, Eingabe und absenden des Formulars, etc.) und der Zeit, bis der Browser dann tatsächlich auf diese Interaktion reagiert. Ein guter Wert für den FID sind 100 Millisekunden. Zwischen 100 und 300 Millisekunden ist eine Optimierung notwendig und darüber hinaus ist es nicht gut und du solltest es dringend optimieren. 

Du kannst die Verzögerung mit PageSpeed Insights von Google oder auch mit gtmetrix testen und analysieren. 

First Input Delay (FID) – die Optimierung

Um die Verzögerung überhaupt erst ausfindig zu machen, musst du diese analysieren und prüfen, wo es eigentlich hakt. Manchmal können es nur einzelne Unterseiten sein, die bestimmte Elemente enthalten, welche auf anderen Unterseiten nicht zu finden sind. Für die Analyse von FID kannst du hier die folgenden Tools verwenden:

  • PageSpeed Insights
  • Gtmetrix
  • Chrome User Experience Report
  • Google Search Console Backend (Core Web Vials-Bericht) 

Wenn du nun eine Analyse gemacht hast, wie die First Input Delay Werte der einzelnen Unterseiten sind, kannst du die entsprechenden Seiten nun optimieren. Bei der Optimierung kannst du an den folgenden Elementen ansetzen und diese optimieren:

Code von Drittanbietern reduzieren

Entweder entfernst du Plugins, die du nicht mehr brauchst oder prüfst, ob es bestimmte Plugins gibt, die einzelne Funktionen vereinen. Oder du integrierst bestimmte Code Teile in die entsprechenden Dateien und entfernst die Plugins anschließend. 

Reduziere die Ausführungszeit von JavaScript 

Auch hier kann das Plugin Autoptimize für WordPress helfen. Async JavaScript könnte hier ebenfalls Abhilfe schaffen. Bitte beachte, dass du hier bezüglich JavaScript sehr vorsichtig sein musst und die einzelnen Einstellungen – vor allem bei Autoptimize – stets mehrmals in unterschiedlichen Abständen testen solltest. Denn es könnte sonst dazu führen, dass bestimmte Funktionen der Seite nicht mehr funktionieren. Gerade wenn es wichtige Funktionen wie der Checkout bei Shops, mobiles Menü und so weiter sind, wird es kritisch.  

Die Arbeit der Haupt-Threads minimieren 

Analysiere die Haupt-Threads und finde heraus, welche es sind. Diese kannst du dann minimieren, indem du den Hauptthread zum Beispiel teilen kannst. Du kannst hierfür Caching Tools verwenden, JavaScript Dateien vereinen oder später laden lassen, dasselbe gilt für CSS-Dateien. Nutze für Bilder die „NextGen“ Bildformate wie zum Beispiel WebP. 

Anzahl der Anfragen (Server Requests) und deren Übertragungsgröße kleinhalten

Die Anzahl der Server Requests kannst du mit mittels gtmetrix sehr gut messen. Optimieren und reduzieren kannst du es mit einem Caching Plugin wie W3c Cache, WordPress Super Cache oder WPRocket. Außerdem kannst du nicht benötigte Plugins entfernen, bestimmte Teile selbstständig in die entsprechenden Dateien hinzufügen und Dateien zusammenführen. Auch hier kann dir Autoptimize sehr gut helfen, eventuell auch in Kombination mit async JavaScript, sofern du WordPress als CMS verwendest. Die Anzahl der Server Requests lässt sich in der Regel leicht und schnell reduzieren. Wichtig ist, dass wenn du Plugins verwendest, welche Dateien kombinieren, wie zum Beispiel Autoptimize wirklich kritisch prüfst, ob alles funktioniert. Das ist mit Abstand der aufwendigste Teil, aber auch der Wichtigste. Du kannst bestimmte JavaScript Dateien aus der Optimierung ausschließen, wenn du herausgefunden hast, welche hier störend sind.

Cumulative Layout Shift (CLS) – Was ist das?

CLS bedeutet Cumulative Layout Shift. Auch das ist eine neue Kennzahl im Bereich der Core Web Vitals. Speziell misst diese Kennzahl die Verschiebung des Layouts, was auch zu einer schlechteren User Experience führen kann. 

Eine Layout-Verschiebung liegt dann vor, wenn ein sichtbares Element seine eigentliche Position im Layout ändert. Das kann sein, weil bestimmte Ressourcen asynchron geladen werden. Wenn die Elemente nicht aufeinander abgestimmt sind, kann es sein, dass Elemente, die später kommen, zu früh geladen und damit verschoben werden. Oder Elemente werden nachgelagert zuerst in das DOM geladen. Auch damit werden Veränderungen am Layout vorgenommen. Dabei kann man zwischen einer erwarteten Layout-Verschiebung und einer unerwarteten Layout-Verschiebung unterscheiden. Die Unerwartete Verschiebung ist für die Nutzer natürlich schlecht und man sollte dies vermeiden. Und es gibt die erwartete Layout-Verschiebung, wenn der User zum Beispiel auf ein Element klickt. Oder wenn eine Animation kommt und die ist für den User nicht überraschend. Der CLS misst hier die unerwarteten Layout-Veränderungen.

Cumulative Layout Shift (CLS) – Die Optimierung 

Wenn du jetzt weißt, worauf es ankommst und was der CLS eigentlich ist, geht es nun darum, diesen zu analysieren und dann zu verbessern. Die Analyse-Tools können die Folgenden sein:

  • PageSpeed Insights Tool
  • Google Search Console
  • Google Chrome Developer Tools
  • Lighthouse

Um dein CLS zu verbessern kannst du folgende Elemente prüfen und optimieren:

Bilder und Videos

Am besten ist es, wenn du bei Bildern und Videos immer Größenangaben machst (width und height). Damit wird der benötigte Platz beim Laden reserviert. Du kannst auch mit einem kleinen CSS Trick (CSS Aspect Ration Boxes) den notwendigen Platz reservieren. Sind Bilder innerhalb von Containern eingebunden und haben bereits eine feste Größe, solltest du sie im CSS auf „height: auto;“ stellen.

Banner

Banner sind ebenfalls wie Bilder zu behandeln. Auch hierfür solltest du feste Größen definieren. Im sichtbaren Bereich sollten sie jedoch weitestgehend vermieden werden, weil sie eine Layout-Verschiebung für das gesamte Dokument bedeuten können. 

Webfonts

Bei den Schriftarten unterscheidet man zwischen FOUT (Flash Of Unstyled Text) und FOIT (Flash Of Invisible Text). Bei FOUT wird die Schrift durch eine neue ersetzt. Bei FOIT wird ein „unsichtbarer Text“ angezeigt, bis die tatsächliche Schrift verfügbar ist. Um beides zu vermeiden solltest du „font-display“ auf „optional“ stellen. Oder du nutzt die Font Loading API.

Content und iFrames

Wenn du einen Content hast, sollte dieser nicht durch einen neuen ersetzt werden, außer der User möchte es und hat eine entsprechende Auswahl getroffen. Wenn du Widgets oder iFrames verwendest, dann sollten auch sie, wie die Bilder, feste Größenangaben haben.

Ein guter Wert für CLS ist 0,1. Zwischen 0,1 und 0,25 solltest du bezüglich der Layout-Verschiebung Optimierungen vornehmen und alles über 0,25 braucht dringend eine Optimierung. Eine sehr ausführliche Hilfe bietet auch Google im Bereich CLS Optimierung an.

Wie kannst du die Core Web Vitals messen?

Die verschiedenen Tools, mit denen du deine Core Web Vitals messen kannst, wurden bereits einige Male erwähnt. Das sind unter anderem:

  • PageSpeed Insights
  • Google Search Console
  • Google Chrome Entwickertools
  • Lighthouse
  • gtmetrix 

PageSpeed Insights und gtmetrix zeigen dir die Sachen relativ gut an, gtmetrix noch etwas genauer. Wenn du es mit den Chrome Dev Tools machen möchtest, kannst du wie folgt vorgehen: 

  • zuerst startest du die Entwickler-Tools (drei Punkte im Chrome, weitere Tools, Entwicklertools oder Strg + Shift + I)
  • rufe die Seite auf, die du gerne untersuchen möchtest
  • jetzt startest du die Aufnahme, indem du in den Entwickler-Tools auf den „Record Button“ klickst oder mittels Strg + E
  • dann ladest du die Seite mittels „Reload Button“ oder Strg + Shift + E neu
  • nachdem deine Seite geladen ist, kannst du die Aufnahme stoppen
  • Gehe sicher, dass ganz oben der Reiter „Performance“ ausgewählt ist
  • Du siehst nun die Auswertung und kannst dich entsprechend entlang klicken und alles genauer ansehen. Du siehst unter anderem die verschiedenen Elemente, die ein CLS verursachen und die Tasks, die zu lange dauern und vieles mehr. 

Mit dieser Vorgehensweise hast du eine sehr detaillierte Auswertung und kannst die notwendigen Bestandteile entsprechend optimieren. 

Core Web Vitals: Das Fazit

Natürlich sind die Core Web Vitals wichtig, weil die Nutzererfahrung auf der Web-Seite hoch im Kurs steht. Jedoch ist und bleibt der Content das Wichtigste. Natürlich ist es so, dass wenn zwei identisch gute Web-Seiten sich um eine Spitzenposition streiten, gewinnt diejenige, welche eine bessere Nutzererfahrung bietet, in diesem Falle auch eine bessere Optimierung der Core Web Vitals hat. Die Core Web Vitals geben dir einen Anhaltspunkt, wie gut es aus Sicht von Google um deine Nutzererfahrung bezüglich PageSpeed, Interaktionszeit und Layout-Verschiebung steht. 

Wichtig ist, wenn deine Webseite schnell lädt, dann wird dies oft schon reichen. Nur, wie es immer so ist: Es gibt über 3.00 verschiedene Ranking-Faktoren, jeder davon füllt das Glas mit einem Tropfen. Der eine Tropfen ist größer, der andere kleiner. Dabei solltest du immer den Aufwand gegenüber dem Nutzen sehen und beides ins Verhältnis setzen. Wenn es positiv ist und sich damit rentiert, dann solltest du es umsetzen. Wenn ein Relaunch ansteht, dann solltest du die Optimierung der Core Web Vitals womöglich gleich mit einfließen lassen, um so Synergieeffekte zu nutzen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*
*