Core Web Vitals
Wenn es darum geht, die Geschwindigkeit einer Webseite zu messen, dann trifft man unter anderem auf den Begriff der "Core Web Vitals" von Google, siehe "Google Search Consol" (GSC). Diese wurden 2021 eingeführt. Mittlerweile gelten sie als weiterer Rankingfaktor, weshalb man sich unbedingt mit ihnen befassen sollte. Doch was genau verbirgt sich dahinter?
Unter den "Core Web Vitals" versteht man eine Kombination aus 3 individuellen Metriken:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Mit diesen Metriken werden die Geschwindigkeit (Ladezeit), die Reaktionsschnelligkeit und visuelle Stabilität beim Laden einer Seite analysiert und anschließend der "Core Web Vitals"-Bericht erstellt.
Daraus geht für jede URL eine Bewertung hervor:
- Gut
- Optimierung erforderlich
- Langsam
Diese Bewertung wiederum ist notwendig für den "Bericht zur Nutzerfreundlichkeit". Ohne diese Bewertung kann eine URL nicht im "Bericht zur Nutzerfreundlichkeit" angezeigt werden.
An dieser Stelle sei erwähnt, dass die Daten aus dem "Core Web Vitals"-Bericht meist erst nach einigen Tagen in den "Bericht zur Nutzerfreundlichkeit" importiert werden. Dementsprechend kann die Bewertung einer URL dort etwas verzögert angezeigt werden.
Eine "Core Web Vitals"-Bewertung mit "gut" ist Voraussetzung für den Status "gut" im "Bericht zur Nutzerfreundlichkeit".
Doch schauen wir uns die "Core Web Vitals einmal im einzelnen an!
Was sind die Core Web Vitals?
Largest Contentful Paint (LCP)
Diese Metrik gibt an, wie schnell eine Seite auf einem Bildschirm (Smartphone, Tablet, Desktop) lädt und der Besucher den für ihn sichtbaren Bereich der Seite sieht, ohne dass er die Seite scrollt. Es wird also die Geschwindigkeit (Ladezeit) gemessen.
First Input Delay (FID)
Diese Metrik gibt an, wie schnell eine Website auf Benutzereingaben (wie z.B. das Tippen auf eine Schaltfläche oder das Eingeben von Daten in ein Feld) reagiert. -> Reaktionsschnelligkeit (Interaktivität)
Cumulative Layout Shift (CLS)
Diese Metrik gibt an, ob sich das Layout (Darstellung) der Seite verschiebt, so dass dies die Webseitennutzung durch den Besucher beeinträchtigt. Ferner gibt es die Anzahl der Verschiebungen an, die der Besucher sieht. Es wird also die visuelle Stabilität auf der Seite gemessen (Layoutverschiebung).
Grenzwerte (thesholds) für die einzelnen Bewertungen
| Gut | Optimierung erforderlich |
Langsam | |
| LCP | ≤ 2.5 s | 2.5 - 4 s | > 4 s |
| FID | ≤ 100ms | 100 - 300ms | > 300ms |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
Hinweis: Da "Mobile Web" und "Desktop Web" unterschiedliche Einschränkungen für Benutzer haben (z.B. Gerät, Größe des Ansichtsfensters, Netzwerkverbindung u.v.m.), werden beide Versionen unabhängig voneinander analysiert. Dementsprechend gibt es die Werte für Mobilgeräte als auch für Desktop-Rechner.
Wie Core Web Vitals messen?
Folgende Anbieter können die Core Web Vitals anzeigen
- Google Search Console
- Google PageSpeed Insights
- Semrush Site Audit
- GTmetrix
- Lighthouse
Ferner gibt es folgende Möglichkeiten
- Chrome DevTools
- Chrome UX Report
- Web Vitals Extension
Bitte beachten! Es kann sein, dass einige Tools Fehler anzeigen, während andere keine Fehler anzeigen. Beispielsweise zeigt die "Google Search Console" die Leistung einer Seite basierend auf den realen Nutzungsdaten aus dem CrUX-Bericht an, während Lighthouse die sogenannten "Labordaten" verwendet. Da "Labordaten" in einer kontrollierten Umgebung gesammelt werden, können damit Leistungsprobleme während der Entwicklungsphase einer Webseite behoben werden. Engpässe in der realen Welt werden möglicherweise nicht erfasst. Somit sind die Informationen, die jeder Bericht liefert, unterschiedlich.
Schlechte Core Web Vitals?
Was ist, wenn eine Seite die angegebenen Leistungsmesswerte von "Core Web Vitals" nicht erreicht?
Noch immer sind der Inhalt einer Seite und seine Übereinstimmung mit der Information, die ein Benutzer sucht, sicherlich ein sehr starkes Signal für das Ranking. Gute Leistungsmesswerte nutzen nichts, wenn die Informationen auf einer Webseite niemanden interessieren und eine Seite deshalb gar nicht erst angeklickt wird. Auf der anderen Seite sollten die "Core Web Vitals" aber auch nicht so schlecht sein, dass Besucher die Webseite sofort wieder verlassen, weil sie beispielsweise ewig lädt.
Core Web Vitals optimieren!
Um die Metriken einer Website zu verbessern, sind Kenntnisse in der Webentwicklung erforderlich. Es kann deshalb sinnvoll sein, sich an einen Fachmann zu wenden, wenn man diese Kenntisse nicht hat. Im Folgenden werden einige Tipps zu möglichen Ursachen für schlechte "Core Web Vitals" sowie deren Optimierung gegeben.
Largest Contentful Paint (LCP) optimieren
Mögliche Ursachen für schlechte LCP-Werte
- Langsamer Server / lange Antwortzeit
- JS und CSS blockieren das Rendern
- Langsam ladende Ressourcen wie Bilder, Videos, Widgets, SocialMedia-Buttons, Newsletter...
Optimierungsmaßnahmen
- Geeigneten Server mit moderner und schneller Technik verwenden
- JS und CSS-Dateien zusammenfassen und komprimieren sowie nicht benötigte Dateien entfernen
- Asynchrones Laden von Ressourcen
- Bilder und Videos hinsichtlich Anzahl, Größe und Format optimieren. "Lazy load" verwenden
- Platzhalter anstatt Videos anzeigen
- http-Requests minimieren
- Caches nutzen
- Content Delivery Network (CDN) nutzen, wenn die Webseite viele internationale Besucher hat
- Unnötige Widgets und Co. erst später nachladen
First Input Delay (FID) optimieren
Mögliche Ursachen für schlechte FID-Werte
- Lange Hauptthread-Aufgaben im JavaScript
- Lange JS-Ausführungszeit
- Große JavaScript-Pakete
- JavaScript, welches das Rendering blockiert
Optimierungsmaßnahmen
- Anzahl der geladenen Skripte reduzieren
- Längere Tasks in kleinere Tasks aufteilen
- Ausführungszeit von JavaScipt reduzieren
- Third-party Tags: Wenn möglich, laden on demand
Cummulative Layout Shift (CLS) optimieren
Mögliche Ursachen für schlechte CLS-Werte
- Bilder, Videos und Iframes ohne Größenangaben
- Werbeanzeigen, die das Layout verschieben
- Cookie-Banner
- Webfonts, die FOIT bzw. FOUT verursachen
Optimierungsmaßnahmen
- Bilder, Videos und Iframes mit Größenatrributen versehen
- Inhalte nicht überlagern
- CSS-Eigenschaft "font-display" nutzen
- Fonts preloaden. Achtung: Performance verschlechtert sich
Weitere Performance-Werte
Außer den "Web Core Vitals" gibt es eine Reihe weiterer Performance-Werte, die bei der Analyse einer Seite von Nutzen sind.
Total Blocking Time (TBT)
"Total Blocking Time" (Gesamtsperrzeit) misst die Gesamtzeit, in der eine Seite blockiert wird. In dieser Zeit kann der Benutzer nicht mit der Seite interagieren. Diese Metrik wurde von Lighthouse eingeführt. Sie kann als Ersatz für die FID-Metrik angesehen werden, wie sie beispielsweise in PageSpeed Insights verwendet wird.
TBT hat einen großen Einfluss auf die Bewertung einer Seite und ist damit eine der wichtigsten zu optimierenden Metriken. Durch deren Optimierung kann die Reaktionsfähigkeit einer Seite wirkungsvoll verbessert werden.
Genaugenommen ist "Total Blocking Time" die Gesamtzeit zwischen "First Contentful Paint" (FCP) und "Time to Interactive" (TTI), bei der der Main-Thread lange genug blockiert war, um die Reaktionsfähigkeit der Eingabe zu verhindern. Der Main-Thread wird vom Browser verwendet, um HTML zu analysieren, das DOM zu konstruieren, CSS und JS auszuführen, sowie Benutzerereignisse zu verarbeiten und weitere Aufgaben auszuführen. Der Main-Thread gilt als "blockiert", wenn einer der Tasks länger als 50ms andauert. Ein laufender Task kann vom Browser nicht unterbrochen werden. Solange der Main-Thread blockiert ist, kann eine Webseite nicht auf Eingaben von Benutzern reagieren (z.B. Mausklicks, Tastaturklicks, ... usw.).
Die Zeiten, welche die 50ms jeweils überschreiten, werden als Sperrzeiten (Blockierzeiten) bezeichnet. Aus ihrer Summe ergibt sich die Gesamtsperrzeit einer Seite.
Grenzwerte für "Total Blocking Time" (TBT)
| Gut | Mäßig | Schlecht | |
| TBT | < 300ms | 300 - 600ms | > 600ms |
Optimierungsmaßnahmen
Um die "Total Blocking Time" (TBT) zu minimieren, gibt es mehrere Möglichkeiten. Im Prinzip greifen hier die gleichen Verbesserungsmaßnahmen (JS-Optimierung) wie für die "First Input Delay"-Metrik. Details siehe oben auf der Seite unter der Überschrift "Core Web Vitals optimieren!"!
Unterschied zwischen "Total Blocking Time" und "First Input Delay"
Wie bereits erwähnt wurde, ist "Total Blocking Time" (TBT) ein Ersatz für "First Input Delay" (FID), welches zu den "Core Web Vitals" gehört. FID ist eine Feldmetrik, für deren Messung echte Benutzerdaten herangezogen werden. Diese stammen aus dem Chrome User Experience Report (CrUX), dessen Daten von echten Chrome-Benutzern gesammelt werden.
Unterschied zwischen "Total Blocking Time" und "Time to Interactive"
"Time to Interactive" (TTI) ist ein weiterer Wert, der sich auf die Interaktivität einer Seite bezieht:
- TTI signalisiert, wenn eine Seite vollständig interaktiv ist
- TTI betrachtet eine Seite als vollständig interaktiv, sobald der Main-Thread mind. 5s frei von langen Tasks (Aufgaben) war
TBT hingegen gibt genau an, welche JS-Aufgaben am längsten zur Ausführung benötigt haben.
Time To First Byte (TTFB)
"Time to First Byte" (TTFB) ist die Gesamtzeit vom Start einer Anfrage (Request) bis zum Erhalt des ersten Bytes der Antwort. Sie ist die Summe aus Weiterleitungsdauer (Redirect Duration) + Verbindungsdauer (Connection Duration) + Backend-Dauer (Backend-Duration). Diese Metrik ist einer der Schlüsselindikatoren für die Webperformance.
Erklärungen
- Redirect Duration: Zeit für Weiterleitung von example.com zu www.example.com, oder http zu https, oder zu einer mobilen Version oder einer Sprachversion einer Seite
- Connection Duration: Zeit, die benötigt wird, um eine Verbindung zum Server herzustellen, um die Anforderung an die Seite zu senden. Die Verbindungsdauer ist meist die Kombination aus Sperrzeit, DNS-Zeit, Verbindungszeit und Sendezeit der Anfrage.
- Backend Duration: Nach der Anfrage generiert der Server eine Antwort für die Seite. Die Zeit, die dazu benötigt wird, wird als Backend-Dauer bezeichnet.
Optimierungsmaßnahmen
- Optimierung des Codes
- Nutzung von Caching
- Aktualisieren der Serverhardware
- Feinabstimmung der Webserverkonfiguration
First Paint
Als "First Paint" bezeichnet man den Zeitpunkt, an dem der Browser mit dem Rendern einer Seite beginnt. Der Browser zeigt dann lediglich eine leere Seite an. Für den Besucher der Webseite ist das ein Indikator dafür, dass die Seite nun geladen wird. Ansonsten hat "First Paint" keine weitere Relevanz.
First Contentful Paint (FCP)
"First Contentful Paint" misst, wie schnell Besucher einer Webseite das erste Inhaltselement angezeigt bekommen. Hierbei kann es sich z.B. um Überschriften, Texte, Bilder ... usw. handeln.
Genaugenommen ist "First Contentful Paint" die Gesamtzeit vom Beginn des Ladens einer Seite bis zum Rendern von Inhalten auf dem Bildschirm. Inhalt der schnell ausgeliefert wird (niedrige FCP-Zeit), trägt zu einer positiven Nutzererfahrung bei.
DOM Interactive Time
Als "DOM Interactive Time" bezeichnet man den Zeitpunkt, an dem der Browser das Laden und Parsen von HTML abgeschlossen hat, und die DOM-Baumstruktur erstellt wurde. DOM = Document Object Model
DOM Content Loaded Time
Als "DOM Content Loaded Time" bezeichnet man den Zeitpunkt, an dem das DOM bereit ist, und es keine Stylesheets gibt, die die JS-Ausführung blockieren.
Falls keine Stylesheets die JS-Ausführung blockieren und auch kein Parser JavaScript blockiert, dann ist "DOM Content Loaded Time" übrigens dasselbe wie "DOM Interactive Time".
Wichtig: Es ist wichtig, dass die Stil- und Skriptreihenfolge optimiert und das Parsen von JavaScript verzögert wird. Ansonsten kann es zu Verzögerungen beim Rendern kommen.
Alternative Ausdrücke: DOM Loaded, DOM Ready
Onload Time
Unter "Onload Time" versteht man den Zeitpunkt, an dem die Verarbeitung einer Seite abgeschlossen ist und somit alle Ressourcen (z.B. CSS, Bilder, ... usw.) heruntergeladen wurden. Dann löst die Seite das JS-Triggerereignis "windows.onload" aus.
Allerdings kann es JavaScript geben, das nachfolgende Anforderungen für weitere Ressourcen auslöst. "Onload Time" kann eine Seite deshalb unter Umständen langsamer als auch schneller angeben als sie in Wirklichkeit ist. "Fully Loaded Time" ist da aussagekräftiger.
Fully Loaded Time
Als "Fully Loaded Time" versteht man den Zeitpunkt, nachdem alle der folgenden Ereignisse eingetreten sind:
- First Contentful Paint hat "gefeuert"
- Onload hat "gefeuert"
- Netzwerk und CPU sind im Leerlauf (5,25s)
In älteren Berichten wird die vollständig geladene Zeit gemessen, wenn:
- Onload hat "gefeuert"
- Netzwerk ist inaktiv (2s)
Es gibt eine feste Zeit von 30s, nachdem Onload "gefeuert" wurde.
Wenn die oben genannten Bedingungen erfüllt sind, verwendet beispielsweise GTmetrix die maximalen Werte von
- First Paint
- First Contentful Paint
- Onload Time
- Largest Contentful Paint
- Total Time to Interactive
- Last request captured
Im Wesentlichen wartet GTmetrix mit dem Abschluss eines Tests, bis Ihre Seite die Datenübertragung beendet, was zu konsistenteren Seitenladezeiten führt.
Dennoch kann es zu verschiedenen Problemen kommen, auf die an dieser Stelle nicht näher eingegangen werden soll. Die "Fully Loaded Time" ist deshalb möglicherweise kein optimaler Indikator für die vom Benutzer wahrgenommene Performance. Man sollte sich deshalb besser auf die Optimierung der 6 Leistungsbewertungsmetriken konzentrieren.
"Fully Loaded Time" in Legacy-Berichten
Legacy-Berichte (veraltet) haben eine etwas andere Definition für die "Fully Loaded Time", da sie die Metrik "Time to Interactive" nicht messen. Unter "Fully Loaded Time" versteht man hier den Zeitpunkt nach 2 Sekunden Netzwerkinaktivität nachdem das Onload-Ereignis ausgelöst wurde.
Aufgrund der unterschiedlichen Definitionen wird die "Fully Loaded Time" in einem Legacy-Bericht möglicherweise nicht mit der Zeit im neuen Bericht (z.B. von GTmetrix) übereinstimmen.
