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.