Google Core Web Vitals Guide

Ladezeiten spielen zukĂŒnftig eine große Rolle fĂŒr erfolgreiches SEO, denn Google plant die EinfĂŒhrung von Ladezeiten als Rankingfaktor. Doch was hat es mit den Core Web Vitals auf sich? Und wie können diese optimiert werden? Dieser Guide bringt Licht ins Dunkel. ZunĂ€chst lernen Sie, was die Google Core Web Vitals sind und wie sie sich zusammensetzen. Anschließend werden die drei Core Web Vital Metriken LCP, FID und CLS im Detail vorgestellt und VerbesserungsansĂ€tze gezeigt.

michael-hammer-bild-fĂŒr-autorenbox

Autor: Michael Hammer
Position: SEO Berater
Aktualisiert: 01

Inhaltsverzeichnis:

Google Core Web Vitals Guide

Ladezeiten spielen zukĂŒnftig eine große Rolle fĂŒr erfolgreiches SEO, denn Google plant die EinfĂŒhrung von Ladezeiten als Rankingfaktor. Doch was hat es mit den Core Web Vitals auf sich? Und wie können diese optimiert werden? Dieser Guide bringt Licht ins Dunkel. ZunĂ€chst lernen Sie, was die Google Core Web Vitals sind und wie sie sich zusammensetzen. Anschließend werden die drei Core Web Vital Metriken LCP, FID und CLS im Detail dargestellt und VerbesserungsansĂ€tze vorgestellt.

michael-hammer-bild-fĂŒr-autorenbox

Autor: Michael Hammer
Position: SEO Berater
Aktualisiert: 01

Was sind Core Web Vitals?

Core Web Vitals sind eine Vielzahl unterschiedlicher Messwerte zur Beurteilung der User Experience einer Website. Sie werden zu drei Metriken zusamengefĂŒhrt:

  • LCP (Largest Contentful Paint)
    Messung der Ladezeit des grĂ¶ĂŸten Bilds oder Textblocks innerhalb des sichtbaren ViewPorts
    Mehr erfahren
  • FID (First Input Delay)
    Messung der Zeitspanne zwischen einer Interaktion eines Nutzers (z.B. Klick auf einen Link oder Button) bis zum Beginn der Verarbeitung von Event Handlern als Reaktion des Browsers
    Mehr erfahren
  • CLS (Cumulative Layout Shift)
    Messung von Layout Verschiebungen wÀhrend des Besuchs auf der Seite. Eine Layout Verschiebung tritt immer dann auf, wenn ein sichtbares Element seine Position von einem gerenderten Frame zum nÀchsten Àndert
    Mehr erfahren

FĂŒr Website Betreiber geben Core Web Vitals Auskunft ĂŒber die User Experience der Website. Die Messung zeigt SchwĂ€chen auf und gibt Auskunft darĂŒber, welche Aspekte der Website verbessert werden sollten.

Core Web Vitals messen

Thema wÀhlen:

PageSpeed Insights

Search Console

Chrome Browser

Chrome User Experience (CrUX) API

Real User Monitoring (RUM)

GrundsĂ€tzlich gibt es viele unterschiedliche Möglichkeiten Core Web Vitals zu messen. Dabei ist es wichtig zu verstehen, wie die einzelnen Messmethoden funktionieren und welche Aussage die Messwerte haben. Das VerstĂ€ndnis nachstehender Unterteilung ist essentiell fĂŒr den erfolgreichen Umgang mit Tools zur Messung von Core Web Vitals.

Zwei verschiedene Arten zur Datenerhebung von Core Web Vitals:

  • Lab Tools = Lab Data
    Die Core Web Vitals Werte aus Lab Tools geben Auskunft ĂŒber die theoretische User Experience eines potentiellen Nutzers. Sie sind hilfreich fĂŒr reproduzierbare Ergebnisse. Nehmen Sie bspw. Änderungen zur Verbesserung von Core Web Vital Werten vor, können Sie Ihre Änderungen mit Hilfe der Lab Tools bewerten.
  • Field Tools = Field Data
    Die Core Web Vitals Werte aus Field Tools (auch Real User Monitoring oder RUM genannt) werden ĂŒber den Chrome User Experience Report (CrUX) gesammelt und geben Auskunft ĂŒber die tatsĂ€chliche User Experience echter Nutzer Ihrer Website. Sie zeigen die gemessene User Experience Ihrer Besucher mit Chrome Browser und sind hilfreich bei der Beurteilung der User Experience von echten Nutzern Ihrer Website.

Wichtig: Nachstehend folgt eine AufzĂ€hlung aller gĂ€ngigen Tools mit denen Messungen durchgefĂŒhrt werden können. Dabei verwendet jedes Tool Lab Tools, Field Tools oder stellt beide Ergebnisse gleichzeitig dar. Bedenken Sie die Unterschiede zwischen Lab Data und Field Data, wenn Sie sich mit den Core Web Vitals Ihrer Website beschĂ€ftigen.

PageSpeed Insights

PageSpeed Insights (PSI) ist das perfekte Werkzeug zum Messen einzelner URLs. Es vereint Lab Data und Field Data und misst gleichzeitig Mobile und Desktop Ladezeiten. Field Data werden mit der Lighthouse 6.0 API generiert, wÀhrend Lab Data aus dem Chrome User Experience Report stammen.

FĂŒr technisch versierte Nutzer bietet sich die PageSpeed Insights API an. Damit können Sie mit etwas Vorarbeit eine Vielzahl unterschiedlicher URLs abfragen und Messwerte in einem gewĂŒnschten Format ausgeben.

Search Console

In der Search Console gibt es inzwischen einen eigenen Bereich zur Messung der User Experience. Die Daten sind gesammelte Field Data aus dem CrUX Report, also gesammelte Daten von echten Nutzern. Der Search Console Core Web Vitals Report gibt Auskunft ĂŒber die LCP, FID und CLS Werte aller URLs mit genĂŒgend vorhandenen Daten echter Nutzer. Hier sehen Sie auf einen Blick, welche Core Web Vital Metrik Probleme verursacht. Mit einem Klick auf die Metrik stellt der Core Web Vital Report die betroffenen URLs dar.

Chrome Browser

Eine weitere praktische Methode zur Messung der Core Web Vitals ist der Chrome Browser. Die erhobenen Daten sind eine besondere Form von Lab Daten – die Testumgebung ist nĂ€mlich Ihr eigenes GerĂ€t und Netzwerk. Um Core Web Vitals mit dem Browser zu messen gehen sie wie folgt vor:

  1. Öffnen Sie den Chrome Browser
  2. Besuchen Sie die Website bzw. URL, die getestet werden soll
  3. Nun muss die Entwicklerkonsole geöffnet werden: DrĂŒcken Sie F12 oder STRG+SHIFT+I core-web-vitals-mit-chrome-messen-dev-tools-oeffnen
  4. Die Entwicklerkonsole ist geöffnet und Sie sehen unterschiedliche Bereiche in der obersten Leiste (Elements, Console, Sources … und Lighthouse). Klicken Sie auf Lighthousecore-web-vitals-mit-chrome-messen-lighthouse-tab-waehlen
  5. Sie befinden sich nun im Lighthouse Tab der Entwicklerkonsole. Dort können Sie noch etwaige Vorstellungen vornehmen, wobei es sich empfiehlt alle Kategorien und als GerÀt Mobile auszuwÀhlencore-web-vitals-mit-chrome-messen-lighthouse-report-settings-waehlen
  6. Klicken Sie den blauen Button „Generate Reportcore-web-vitals-mit-chrome-messen-lighthouse-report-generieren

Die Core Web Vitals finden Sie gleich zu Beginn des Reports im Bereich „Performance“. Außerdem gibt Google, Ă€hliche wie bei PageSpeed Insights, gleich Tipps zur Verbesserung einzelner Punkte. Jeder Punkt kann angeklickt werden und es erscheinen weiterfĂŒhrende Informationen dazu. Übrigens lohnt sich auch ein Blick in die Diagnose. Auch wenn das lt. Google keinen direkten Einfluss auf die Leistungsbewertung hat, beeinflust das indirekt die Ladezeit Ihrer Website.

Tipp: Fall Sie bloß einen kurzen Blick auf die Core Web Vitals werfen möchten, empfiehlt sich die von Google zur VerfĂŒgung gestellte Chrome Extention fĂŒr den Chrome Browser. Hier finden Sie die Core Web Vitals Erweiterung fĂŒr den Chrome Browser.

Chrome User Experience (CrUX) API

Neben PageSpeed Insights gibt es auch weitere Möglichkeiten auf die gesammelten Field Data von Google zuzugreifen. Das ist vorallem dann interessant, wenn man nicht jede URL einzeln bei PageSpeed Insights hinterlegen möchte, sondern bspw. Field Daten fĂŒr alle URLs der eigenen Website sammeln möchte. Hier kommt die CrUX API ins Spiel. GrundsĂ€tzlich gibt es folgende Möglichkeiten auf die CrUX API zuzugreifen:

Real User Monitoring (RUM)

Eine deutlich aufwĂ€ndigere, aber sehr interessante Möglichkeit zur Messung der Ladezeiten ist das Aufsetzen von Real User Monitoring bzw. dem eigenstĂ€ndigen Messen der Core Web Vitals. Das kann aus verschiedenen GrĂŒnden sinnvoll sein:

  • Googles CrUX Report benötigt die ausdrĂŒckliche Zustimmung des Nutzers, somit wird nicht jeder Chrome Nutzer Ihrer Website erfasst. Sie haben hingegen die Möglichkeit diese Einstimmung auf einfachem Weg mit der Cookie Notice einzuholen
  • Googles Daten sind nicht aktuell und somit zeitversetzt. Messen Sie hingegen selbststĂ€ndig, sind die Daten stets up-to-date. Sie können diese Daten noch wĂ€hrend der Dauer des Besuchs eines Nutzers verarbeiten und darauf aufbauende Maßnahmen einleiten
  • Die selbststĂ€ndige Messung erzeugt verwertbare Daten fĂŒr tiefgreifende Analysen. Sie sehen, welche Nutzer schlechte Werte haben oder welcher Bereich Ihrer Website schlecht performt. Kombinierne Sie die Daten mit Ihren Web Analytics Daten wissen Sie welcher Nutzer Performance Probleme hat und wo er sich innerhalb der Customer Journey befindet – natĂŒrlich haben Sie so auch die Möglichkeit ggf. einzugreifen.

Core Web Vitals bewerten

Nach der Messung erfolgt die Bewertung der einzelnen Metriken. Google gibt Auskunft darĂŒber, wann eine Metrik gut, verbesserungswĂŒrdig oder schlecht ist. Die Nachstehende Tabelle zeigt die Bewertung der einzelnen Metriken:

Gut VerbesserungswĂŒrdig Schlecht
LCP Unter 2,5 Sekunden Unter 4 Sekunden Über 4 Sekunden
FID Unter 100ms Unter 300ms Über 300ms
CLS Unter 0,1 Unter 0,25 Über 0,25

Largest Contentful Paint (LCP): Messung der Ladezeit Performance

Thema wÀhlen:

So sieht ein guter LCP Wert aus

Den LCP Wert messen

Wie optimiere ich den LCP?

WeiterfĂŒhrende Informationen

Der Largest Contentful Paint beschreibt die Dauer der Ladezeit und visuellen Darstellung des Above the Fold Contents. Einfach gesagt: Wie lange dauert es bis eine Seite vollstÀndig im Browser dargestellt wird und der Nutzer mit ihr interagieren kann, nachdem Sie aufgerufen wird? Dieser Teil der User Experience wird in den Core Web Vitals mit der LCP Metrik dargestellt.

Wie der Name vermuten lĂ€sst erfolgt die Messung anhand der Renderzeit des grĂ¶ĂŸten Elements der entsprechenden Seite. Dabei ist jedoch ausschließlich das grĂ¶ĂŸte Element im ViewPort des Browsers relevant, dass innerhalb des sogenannten Above the Fold Content liegt. Also dem Teil der Seite, der ohne Nutzerinteraktion auf dem Bildschirm sichtbar ist. Falls bspw. weiter unten auf der Seite und somit außerhalb des Above the Fold Contents ein Video implementiert ist, wirkt sich das zwar selbstverstĂ€ndlich auf die Ladezeit, jedoch nicht auf den LCP Score aus.

Ein guter LCP Wert

Die Ladezeit des LCP Wertes lÀsst sich in drei verschiedene Bereiche unterteilen:

  • Unter 2,5 Sekunden ist ein guter LCP Wert
  • 2,5 – 4 Sekunden ist ein verbesserungswĂŒrdiger LCP Wert
  • Über 4 Sekunden ist ein schlechter LCP Wert

LCP Wert messen

Umfangreiche Informationen zur Messung des LCP und der restlichen Core Web Vitals finden Sie hier.

Nutzen Sie fĂŒr eine kurzfristige Messung folgende Tools:

LCP Wert optimieren

FĂŒr die Optimierung des LCP stehen Ihnen unterschiedliche AnsĂ€tze zur Verbesserung zur VerfĂŒgung. Als Quick Wins haben sich die Optimierung von Bildern und das Setzen einer effizienten Caching Richtlinie etabliert. Aber das ist noch lange nicht alles …

Langsame Antwortzeiten des Servers – TTFB

Sobald ein Nutzer Ihre Website aufruft stellt der Browser eine Anfrage an Ihren Webserver. Der Webserver antwortet und schickt unterschiedliche Dateien an Ihren Browser. Der Browser beginnt den Renderprozess und der Inhalt der Seite baut sich (hoffentlich schnell) auf.

Doch was ist, wenn der Webserver zu lange braucht diese Anfrage zu bedienen? Dann verzögert sich die Ladezeit noch bevor der Browser anfangen konnte die Seite aufzubauen. Um diese Verzögerung zu beschleunigen mĂŒssen Sie die TTFB Werte Ihres Webservers optimieren. Zum GlĂŒck stehen Ihnen hierfĂŒr eine Menge unterschiedlicher AnsĂ€tze zur VerfĂŒgung, von denen die Wichtigstesn nachstehend vorgestellt werden.

Ein CDN Nutzen

Ein Content Delivery Network oder CDN ist besonders fĂŒr internatioale Websites mit Nutzern aus unterschiedlichen LĂ€ndern interessant. Stellen Sie sich vor Ihre Website verzeichnet Nutzer aus ganz Europa oder sogar von mehreren Kontinenten. Der Webserver steht jedoch bei Ihnen in der Firma oder einem Hoster hierzulande. Daraus ergeben sich ganz unterschiedliche Zeiten fĂŒr Requests. Nutzer aus dem DACH Raum freuen sich ĂŒber schnelle Ladezeiten. Auch Nutzer aus den Niederlanden oder Polen werden auf ihre Kosten kommen. Doch was ist mit Nutzern aus Portugal, Estland, China, USA, …? Je grĂ¶ĂŸer die Entfernung des Nutzers zu Ihrem Webserver, desto mehr wirkt sich das auf die Ladezeit aus.

Ein CDN dient dazu statischen Content (Bilder, Grafiken, Videos, …) so zu hosten, dass die Anfrage des Nutzers aus einer möglichst geringen Entfernung bedient wird. Im Optimalfall werden die statischen Inhalte dem Nutzer aus Porutgal von einem portugiesischen Server bereitgestellt, dem Nutzer aus Estland von einem estonischen Server bereitgestellt, dem Nutzer aus den USA … Sie verstehen, worauf das hinauslĂ€uft. Mit einem CDN kann wertvolle Zeit gewonnen werden. ErfahrungsgemĂ€ĂŸ ist ein CDN jedoch wie gesagt besonders fĂŒr Websites mit einem internationalen Publikum interessant.

Mehr ĂŒber CDNs erfahren

Effiziente Caching Richtlinie bereitstellen

Viele Assets Ihrer Website Ă€ndern sich nicht im Laufe der Zeit. Denken Sie bspw. an das Logo – einmal ausgewĂ€hlt bleibt ein Logo meistens ĂŒber mehrere Jahre hinweg gleich. Nutzer mĂŒssen diese Logografik jedoch bei jedem Besuch der Website erneut laden. Das Gleiche gilt fĂŒr Schriften, Videos und Grafiken jeglcher Art. Aber ebenso fĂŒr Code wie JavaScript oder CSS.

Wenn Sie Caching eingerichet haben speichert der Browser die ausgewÀhlten Assets lokal auf dem GerÀt des Nutzers ab. Bei einem erneuten Besuch der Website greift der Browser auf den lokalen Cache, statt den Request an den Webserver zu schicken. Dadurch wird wertvolle Ladezeit gespart, denn in Summe kann gut und gerne 50% der gesamten Last eines einzelnen Requests gecached werden.

Stellen Sie daher sicher, dass entsprechende Assets mit einer Caching Richtlinie versehen sind. Bei einer Zeitdauer von mindestens 180 Tagen wird das Caching von Google als effizient gewertet, bei vielen Assets ist jedoch auch ein Zeitraum von 360 Tagen oder mehr sinnvoll.

Tipp: Es gibt Möglichkeiten alle Assets zu cachen und gleichzeitig dafĂŒr zu sorgen, dass bei Änderungen einzelne Assets bei einem wiederholten Besuch Ihrer Nutzer erneut geladen werden. So sorgen Sie gleichzeitig fĂŒr maximale Einsparungen beim Caching und ĂŒbertragen etwaige Änderungen an einzelnen Assets, bspw. beim Tausch eines Bildes oder Änderungen am Design der Website, dennoch sofort an die Nutzer.

Mehr ĂŒber HTTP Caching erfahren

Einen Service Worker nutzen

Der Begriff Service Worker bezeichnet den Einsatz einer JavaScript Datei, welche separat vom Main Thread lĂ€uft. Ein Service Worker dient dazu Netzwerkanfragen abzufangen und kĂŒmmert sich darum Ressourcen im Cache zu speichern oder diese aus dem Cache abzurufen. Außerdem kann er fĂŒr das Ausliefern von Push Benachrichtungen eingesetzt werden, wie das bei vielen Smartphone Apps der Fall ist.

Ein Service Worker ist hilfreich bei der Cache Kontrolle der Website. Der Service Worker cached einen Teil oder die gesamte HTML Seite und updated diese lediglich bei VerÀnderungen am Content.

Mehr ĂŒber Service Worker erfahren

3rd Party Connections möglichst frĂŒh bereitstellen

Keine moderne Website kommt ohne 3rd Party Assets aus. 3rd Party Connections beschreibt den Abruf von Assets, die nicht auf dem eigenen Web Server liegen.

Meistens handelt es sich dabei um unterschiedliche JavaScript Libraries, z.B. fĂŒr das Web Design. Aber auch der Einsatz von Google Analytics geht mit einer 3rd Party Connection einher, da fĂŒr die FunktionalitĂ€t eine JavaScript Datei von Google benötigt wird. Da diese Assets von einem fremdem Web Server geladen werden hat man als Website Betreiber keinen Einfluss auf deren Inhalt. Sind diese Assets nun besonders groß, verlangsamen sie die Ladezeit der Website – insb., wenn die Funktion des Assets im Above the Fold Content benötigt wird.

Tipp: Abhilfe schafft das preconnect-Element im Link Attribut der Assets. Setzen Sie das preconnect Element im HTML Code, sorgt der Browser fĂŒr eine schnellere Connection zur fremden Domain bzw. deren Web Server beim Aufbau der Seite. Sobald der Rendering Prozess an den Punkt gelangt das Asset zu laden, ist die Verbindung zum Web Server dorthin bereits aufgebaut.

Mehr zum preconnect Element

Tipp 2: Ein weitere Ansatz ist das dns-prefetch Element im Link Attribut der Assets. Im Gegensatz zum preconnect Element geht es hierbei um eine möglichst schnelle Namensauflösung der verlinkten Assets. Denn wĂ€hrend im Quellcode die Domain des Assets verlinkt wird, ruft der Browser diese ĂŒber die IP ab. Zur Beschleunigung dieses Vorgangs kann man dem Browser bereits im Voraus mitteilen die Domain in eine IP umzuwandeln. Der Einsatz von dns-prefetch lohnt sich bei der Nutzung vieler unterschiedlicher Assets von verschiedenen Domains.

Mehr zu dns-prefetch

Render blockiernedes JavaScript und CSS

Einer der grĂ¶ĂŸten Hebel bei der Verbesserung des LCP Werts und gleichzeitig nur schwer komplett umsetzbar. Das liegt am Einsatz und der Funktion von Content Management Systemen, die gerade den grĂ¶ĂŸten Hebel beim Render Blocking kaum zugĂ€nglich machen. An diesem Punkt ist es wichtig sich erneut zu erinnern, dass es um die Optimierung des Contents im Initial ViewPort geht, also innerhalb des Above the Fold Contents. Denn das ist der entscheidende Knackpunkt, warum CMS Systeme große Probleme damit haben – ihnen fehlt die Möglichkeit JavaScript & CSS im ViewPort vom Rest der Seite zu trennen. Dennoch kann man auch hier die eine oder andere Verbesserung erzielen. Außerdem sind die nahchstehenden Punkte besonders interessant bei der Planung eines Website Relaunch.

Den Einsatz von JavaScript und CSS gering halten

Viele Websites sind unnötig kompliziert aufgebaut und könnten das gleiche Resultat mit einem deutlich schlankeren CSS- und JavaScript Code erzielen.

Entweder ist das genutzte CMS System ĂŒberladen oder man greift auf Performance KrĂŒcken wie Page Builder, Plugins etc. zurĂŒck. HĂ€lt man JavaScript und CSS möglichst gering, kann die gleiche User Experience mit drastisch geringerer Last bereitgestellt werden.

Minifying

Die verwendeten CSS und JavaScript Dateien sollten auf jeden Fall minified werden. Minifying beschreibt das Entfernen ungenutzter Zeichen innerhalb des Codes iwe bspw. Kommentare, Formatierungen, ungenutzten Code, kĂŒrzere Variablen etc. Die Funktion des CSS und JavaScripts bleibt erhalten, die DateigrĂ¶ĂŸe wird jedoch verringert.

Falls Sie kein Caching Plugin nutzen, können Sie das auch manuell unter zu Hilfename vieler kostenlosers Tools machen. Suchen Sie einfach nach „html minify“ oder „css minify“ oder schauen Sie hier.

Critical / Non-Critical CSS

Dieser Punkt stellt einen enormen Hebel zur Verbesserung des LCP Wertes dar und ist gleichzeitig nur schwierig zu bewerkstelligen. Wie bereits geschrieben ist es wichtig sich klarzumachen, dass der LCP Wert ausschließlich den Content im ViewPort bewertet. Somit ist auch lediglich CSS fĂŒr genau diesen Teil der Website relevant. Man nennt diesen Code: Critical Code bzw. kritischen Code.

Alle CSS Designs, die erst weiter unten auf der Website dargestellt werden sind somit nicht kritisch und auch nicht relevant fĂŒr die Messung des LCP Wertes. Und hier liegt die Krux begraben: CMS Systeme arbeiten nicht nach einer Unterteilung zwischen ViewPort Content und nicht-Viewport Content. Somit fehlt auch eine Unterteilung zwischen Critical und Non-Critical Code. Web Entwickler erahnen bereits, was getan werden muss: alle CSS Dateien mĂŒssen aufgedröselt und aufgeteilt werden. Die einen sind relevant fĂŒr die Darstellung des ViewPorts, die anderen sind relevant fĂŒr alle anderen Inhalte weiter unten auf der Seite.

Das klingt vielleicht gar nicht weiter schlimm – ist es aber. CSS und JavaScript Code wird ĂŒblicherweise als Gesamtes geschrieben. Sie mĂŒssen die gesamte Logik hinter dem Code aufbrechen und nach Critical Code und Non-Critical Code aufteilen. Das kann sehr aufwĂ€ndig werden. Es gibt zwar Möglichkeiten relevanten Code zu erkennen, jedoch nutzen die meisten Websites bspw. bloß eine einzige CSS Datei. Somit macht man zwar die relevante Datei aus, kann jedoch nicht wirklich was daran Ă€ndern.

Critical CSS Inline darstellen

Falls Sie zu den glĂŒcklichen Webseiten Betreibern ohne CMS gehören oder einen Relaunch Planen, gibt es einen weiteren Tipp zum Critical CSS: Es empfiehlt sich diesen kritischen Code Inline, also innerhalb des Quellcodes, darzustellen. Der restliche Code sollte asynchron ĂŒber das preload-Element nachgeladen werden.

Weitere Informationen zu Inline CSS:

Platzsparende Ressourcen verwenden

Ein allseits bekannter, aber in der Praxis immer noch großer Hebel bei vielen Websites ist die Reduzierung von DateigrĂ¶ĂŸen wie bspw. Bildern und Videos.

Bedenken Sie stets die mögliche Darstellung Ihrer Bilder und Videos auf den GerĂ€ten Ihrer Nutzer. MĂŒssen Sie Ihren Nutzern das Material wirklich hochauflösend in 4k bereitstellen? Falls ja, können Sie die originale QualitĂ€t immer noch zum Downoad anbieten oder Interessenten zukommen lassen. Auf Ihrer Website haben solche Auflösungen jedoch nichts verloren, da zum Einen die wenigsten GerĂ€te mit so einer hohen Auflösung etwas anfangen können und zum Anderen die Platzeinsparungen in keinem VerhĂ€ltnis zum QualitĂ€tverlust stehen. Sie reduzieren ein Bild von 2,5mb auf 100kb und das menschliche Auge erkennt kaum einen Unterschied – fĂŒr den Browser hat sich die Last jedoch um Faktor 25 reduziert.

Es gilt ein gesundes Mittelmaß zu finden. Wenn Sie glauben, dass die höhere QualitĂ€t von Ressourcen die User Experience in einem höheren Ausmaß verbessert, als schlechtere Ladezeiten diese verschlechtern, greifen Sie zu guter QualitĂ€t – das geschieht dann jedoch auf Kosten der Ladezeit und falls die Ressourcen im Above the Fold Content dargestellt werden auch des LCP Wertes.

Weitere Informationen

First Input Delay (FID): Messung der Zeit einer Interaktion

Thema wÀhlen:

So sieht ein guter FID Wert aus

Den FID Wert messen

Wie optimiere ich den FID?

WeiterfĂŒhrende Informationen

Der First Input Delay beschreibt die Dauer der Reaktionszeit des Browser nach der ersten Nutzerinteratkion. Einfach gesagt: Wie lange dauert die Reaktion des Browsers nachdem ein Nutzer zum ersten mal einen Link geklickt hat, einen Button getippt hat usw. Dieser Teil der User Experience wird in den Core Web Vitals mit der FID Metrik dargestellt.

Die Reaktionszeit des Browser auf eine Interaktion des Nutzers hat einen hohen Stellenwert in Bezug auf die User Experience. Schnelle Ladezeiten beim Aufbau einer Website sind schön und gut, aber eine langsame Reaktionszeit von Nutzerinteraktionen ist mindestens ebenso frustrierend. Denn sobald ein Nutzer das GefĂŒhl hat die Website wĂŒrde nicht ordentlich auf seine Interaktionen reagieren, navigiert er sich schnell wieder in die SERPs und klickt das nĂ€chstbeste Suchergebnis in der Hoffnung auf eine bessere User Experience.

Ein guter FID Wert

Die Ladezeit des FID Wertes lÀsst sich in drei verschiedene Bereiche unterteilen:

  • Unter 100 Millisekunden ist ein guter FID Wert
  • 100 – 300 Millisekunden ist ein verbesserungswĂŒrdiger FID Wert
  • Über 300 Millisekunden ist ein schlechter FID Wert

FID Wert messen

Umfangreiche Informationen zur Messung des FID und der restlichen Core Web Vitals finden Sie hier.

Nutzen Sie fĂŒr eine kurzfristige Messung folgende Tools:

FID Wert optimieren

Auch bei der Optimierung des FID Werts können Sie aus unterschiedlichen AnsĂ€tzen wĂ€hlen. Ähnliche Quick Wins wie bei der Optimierung des FCP gibt es hier zwar nicht, dafĂŒr aber auch keine Herkulesaufgaben. Bei der Optimierung des FID geht es eher darum die Fehlerquellen ausfindig zu machen und möglichst effizient zu verbessern.

Lange Tasks ausfindig machen und aufdröseln

Lange Tasks liegen meist an zu großen JavaScript Dateien. Ähnlich wie bei der FCP Optimierung und der Unterteilung zwischen kritischem und nicht-kritischem CSS, kann auch bei einer Nutzerinteraktion zu viel irrelevanter Code vom Browser geladen werden:

  • Wenn ein Nutzer mit Ihrer Website interagiert und die Interaktion die AusfĂŒhrung von JavaScript nach sich zieht, sollte fĂŒr eine bestmögliche Performance lediglich der fĂŒr eben diese Interaktion relevante Teil des JavaScripts ausgefĂŒhrt werden
  • Eine andere Interaktion des Nutzers, die ebenfalls die AusfĂŒhrung von JavaScript nach sich zieht, sollte ebenfalls bloß relevanten Code ausfĂŒhren.

In der RealitĂ€t funktionieren die meisten Websites jedoch anders. Die Interaktionen basieren lediglich auf wenigen unterschieldichen JavaScript Dateien. Diese stellen die FunktionalitĂ€t fĂŒr eine Vielzahl unterschiedlicher Interaktionen bereit. Dadurch werden viele Zeilen JavaScript Code geladen ohne, dass diese fĂŒr die jeweilige Interaktion relevant wĂ€ren. Der Browser des Nutzers verarbeitet unnötigereweise viel JavaSript auf Kosten der Interaktionszeit. Das zahlt sich zwar bei den nĂ€chsten Interaktionen aus, geschieht jedoch auf Kosten der ersten Nutzerinteraktion.

Tipp: Teilt man den verwendeten JavaScript Code auf alle möglichen Nutzerinteraktionen auf und lĂ€dt ihn StĂŒck fĂŒr StĂŒck bei jeder Interaktion nach, kann man große Einsparungen bei der ersten Nutzerinteraktion erzielen.

So finden Sie lange Tasks heraus mit dem Chrome Browser

Interaktionen priorisieren

Die fehlende Priorisierung von JavaScript ist ein hĂ€ufiges Problem vieler Websites. Ein einfaches Beispiel ist JavaScript Code zur Bereitstellung von FunktionalitĂ€t bei der Anmeldung im Benutzerkonto. Dieser Code sollte erst ausgefĂŒhrt werden, sobald ein Nutzer sich in den Anmeldebereich des Benutzerkontos begibt. Gerade viele Shops mit Nutzeraccounts stellen den Code jedoch bereits vor der Anmeldeseite zur VerfĂŒgung und dadurch verlangsamt sich die Interaktionszeit aller Nutzer, aber insb. derer, die gar kein Konto haben und sich auch nicht anmelden möchten. Ihr Browser lĂ€dt und verarbeitet den irrelevanten Code dennoch beim Besuch des Shops.

Ein wichtiges Stichwort hierbei ist der Critical Rendering Path. Dieser beschreibt, wie die einzelnen Schritte des Browsers beim Aufbau der graphischen Darstellung einer Website. Der Browser geht dabei nach einem fest definierten Schema vor:

  • Eine schlechte Priorisierung von JavaScript blockt den Browser auf dem Weg des Critical Rendering Path
  • Eine ordentliche Priorisierung kann diesen Prozess beschleunigen und die Zeit der Nutzerinteraktion verkĂŒrzen, indem fĂŒr die Interaktion irrelevanter Code erst dann nachgeladen wird, wenn er auch tatsĂ€chlich notwendig ist

Denken Sie an die AnmeldefunktionalitÀt. Erst wenn der Nutzer sich in seinem Konto anmelden will sollte die FunktionalitÀt gewÀhrleistet werden, zuvor ist sie lediglich eine unnötige Last und beeintrÀchtigt die Zeit einer Nutzerinteraktion.

Mehr Informationen zum Critical Rendering Path

Einen Web Worker verwenden

Ein Web Worker beschreibt die Möglichkeit JavaScript Code auf mehrere Threads aufzuteilen. Dadurch kann die graphische Darstellung der Website von anderem JavaScript Code getrennt. Der restliche Code lĂ€uft dann parallel in anderen Threads, was sich positiv auf mögliche Blockaden des Main Threads auswirkt. Nicht fĂŒr die Darstellung des User Interface benötigtes JavaScript sollte vom Main Thread getrennt und auf einen anderen Thread ausgelagert werden.

Mehr Informationen zur Nutzung von Web Workern

AusfĂŒhrungszeit von JavaScript reduzieren

Der einfachste Weg fĂŒr eine Reduzierung der JavaScript AusfĂŒhrungszeit zu sorgen ist die Reduzierung des JavaScript Codes. Sie sollten versuchen den Einsatz von JavaScript gering zu halten. Ein vollstĂ€ndiger Verzicht von JavaScript ist allerdings nicht immer möglich und auch nicht nötig. Befolgen Sie einfach die folgenden zwei Hinweise:

  • Laden Sie den restlichen JavaScript Code verzögert nach. DafĂŒr mĂŒssen Sie das JavaScript wie bereits beschrieben auf einzelne Interaktionen aufteilen und zwischen kritischem und nicht-kritischem JavaScript unterscheiden – also zwischen JavaScript, welches innerhalb des Above the Fold Contents benötigt wird und JavaScript, welches erst weiter unten auf der Seite zum Einsatz kommt. Den weiter unten auf der Seite benötigten JavaScript Code können Sie verzögert nachladen, damit er sich nicht auf die
  • Beseitigen Sie ungenutzte oder veraltete Polyfills innerhalb des JavaScripts. Polyfills sind JavaScript Bausteine zur UnterstĂŒtzung der FunktionalitĂ€t des Codes auf Ă€lteren Browsern. Sie können die Ladezeit auf Kosten der FunktionalitĂ€t fĂŒr wenige Nutzer erheblich erhöhen. PrĂŒfen Sie, ob Ihre Nutzer auf diese FunktionalitĂ€t angewiesen sind und entledigen Sie sich unnötiger Pollyfills innerhalb Ihres JavaScript Codes

Mehr Informationen zur Reduktion der AusfĂŒhrungszeit von JavaScript

Weitere Informationen

Cumulated Layout Shifting (CLS): Messung der visuellen StabilitÀt

Thema wÀhlen:

So sieht ein guter CLS Wert aus

Den CLS Wert messen

Wie optimiere ich den CLS?

WeiterfĂŒhrende Informationen

Der Cumulated Layout Shifting beschreibt Layout Verschiebungen wÀhrend der Sitzungsdauer eines Nutzers. Einfach gesagt: Wie oft verschieben sich unerwartet sichtbare Elemente auf einer Seite. Dieser Teil der User Experience wird in den Core Web Vitals mit der CLS Metrik dargestellt.

Unerwartete Verschiebung sichtbarer Elemente sind mitunter die frustrierendste Erfahrung im Alltag von Internetnutzern. Ein allseitsbekanntes Beispiel sind Popup Fenster, die einen Maushover ĂŒber dem X zum Wegklicken erfassen und kurz vor der Nutzerinteraktion die Position Ă€ndern. Der Nutzer klickt das Popup an, statt es wegzuklicken und wird auf die Seite des Werbetreibenden geleitet. Neben gewollten Verschiebungen wie beim Popup Fenster, gibt es auch völlig ungeplante Verschiebungen. Diese geschehen ohne Kenntnis des Websitebetreibers – wirken sich allerdings ebenso negativ auf die User Experience von Nutzern aus.

Ein guter CLS Wert

Die Messung und Einordnung des CLS Wert lÀsst sich in drei verschiedene Kategorien unterteilen:

  • Unter 0,1 ist ein guter CLS Wert
  • 0,1 – 0,25 ist ein verbesserungswĂŒrdiger CLS Wert
  • Über 0,25 ist ein schlechter CLS Wert

CLS Wert messen

Umfangreiche Informationen zur Messung des CLS und der restlichen Core Web Vitals finden Sie hier.

Nutzen Sie fĂŒr eine kurzfristige Messung folgende Tools:

CLS Wert optimieren

Der Grund fĂŒr einen schlechten CLS Wert kann die falsche Dimensionierung von Bildern oder iFrames, dynamisch generierter Content, Probleme bei Fonts bzw. Schriftarten (FOIT/FOUT) und Wartezeiten bei Aktionen, die vor der Aktualisierung des DOMs auf eine Netzwerkantwort entstehen sein. Klingt auf den ersten Blick zwar kompliziert, aber alle genannten Punkte können problemlos optimiert werden.

Falsche Dimensionierung von Bildern

Damit Bilder beim Aufbau der Seite gleich korrekt dimensioniert dargestellt werden muss ihnen stets eine Dimension zugewiesen werden. Dies kann entweder bei der Einbindung im HTML vorgenommen werden


<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />

oder beim Styling im CSS Stylesheet

img {
  aspect-ratio: attr(width) / attr(height);
}

Auf diese Weise wird sichergestellt, dass der zur Darstellung des Bilds benötigte Platz beim Seitenaufbau gleich zu Beginn bedacht wird und keine Verschiebungen zum Nachteil des CLS Scores stattfinden. Ein weiterer Pluspunkt ist, dass Bilder auf allen GerĂ€ten in der vorgesehenen GrĂ¶ĂŸe dargestellt werden.

Falsche Dimensionierung von iFrames

Ein Ă€hnliches Problem wie bei der falschen Dimensionierung von Bildern. Allerdings dienen iFrames dazu anderweitigen oder fremden Content auf der eigenen Website einzubinden, wie bspw. Werbeanzeigen, Youtube Videos, Social Media Posts etc. Das Problem hierbei ist, dass der benötigte Platz nicht immer gleich ist. Zum Beispiel sind einige Social Media Posts lĂ€nger oder kĂŒrzer, mit einem Bild oder Video versehen, usw.

Daher sollte das Element in welches das iFrame platziert wird ebenfalls mit einer festen Dimensionierung versehen werden. Auf diese Weise beugt man CLS Verschiebungen beim Seitenaufruf vor.

Dynamisch generierter Content

Ein weiteres relativ hĂ€ufig aufkommendes Problem, sind CLS Fehler bei dynamischem Content. Ähnlich wie bei einem Social Media Post kann von Werbenetzwerken ausgespielter Content unterschiedliche Formen annehmen, wenn er auf der eigenen Website eingebunden wird. Mal wird ein Video abgespielt, mal eine Animation mit CTA Button, etc.

Auch hier kann CLS Verschiebungen vorgebeugt werden, indem das Element, worin sich der dynamisch generierte Content befindet, mit einer festen Dimension versehen wird.

Schriftarten: FOIT und FOUT

Bei beiden Begriffen geht es um das Thema Schriftarten auf der Website:

  • FOUT = flash of unstyled text / aufblitzen von ungestyltem Text
  • FOIT = flash of invisible text / aufblitzen von unsichtbarem Text

Beide Probleme tauchen regelmĂ€ĂŸig beim Besuch fremder Websites auf sind den meisten Nutzern ein Begriff. Noch wĂ€hrend eine Website lĂ€dt kommt es manchmal dazu, dass die Schriftart sich plötzlich verĂ€ndert oder Text, der bspw. hinter anklickbaren Elementen liegt, fĂŒr einen kurzen Moment sichtbar wird.

Um dieses Problem zu umgehen, sollten alle Schriftarten mit einem sogenannten preload-Tag versehen werden. Dadurch erhöht sich die Wahrscheinlichkeit, dass Fonts noch vor dem First Paint der Website geladen sind und somit keine CLS Fehler entstehen.

Mehr Informationen zum Thema FOIT & FOUT

Weitere Informationen

Artikel zum Thema Core Web Vitals

0 Kommentare

Dein Kommentar

An der Diskussion beteiligen?
Einfach einen Kommentar schreiben
Schreibe einen Kommentar

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