Sie haben vielleicht schon einmal den Begriff “Website-Geschwindigkeit” gehört, aber was bedeutet das wirklich? Die Ladezeit einer Website (auch bekannt als Website-Performance) ist die Zeitdauer, die vergeht, vom Moment des Ladens der Website im Browser bis die Website vollständig für den Nutzer geladen ist.
In diesem Artikel zeige ich Ihnen, wie Sie die Core Webvitals in Google Analytics 4 integrieren können.
Pagespeed Metriken (benutzerzentriert) erklärt
Vor langer Zeit war die wichtigste Seitenladegeschwindigkeitsmetrik das “Load event“, das den Moment verfolgt, wenn die gesamte Seite einschließlich aller abhängigen Ressourcen wie Stylesheets und Bilder vollständig geladen ist.
Obwohl das “Load Event” eine wichtige Metrik ist, liefert es keine Informationen über die vorherigen Ladevorgänge.
Hier sind zum Beispiel zwei Websites mit dieser Lademetrik. Eine Website hatte eine optimierte Darstellung, während die andere diese Funktion nicht hatte.
Beide Websites waren zur gleichen Zeit vollständig geladen (1,5 Sekunden), aber ein Website-Besucher wird die erste Website als schneller wahrnehmen. Dies liegt daran, dass sie etwas auf dem Bildschirm sehen oder lesen können, während die Website weiter lädt. Auf der zweiten Website mit nicht optimierter Darstellung kann der Besucher nur warten.
Es verhält sich genauso mit der “Zeit bis zur Interaktion”. Wenn ein Website-Besucher mit einer Website interagieren kann, ohne warten zu müssen, wird er sie als schnellere Website wahrnehmen. Umgekehrt hilft es nicht, wenn eine Website vollständig gerendert ist, aber der Besucher trotzdem 3 Sekunden warten muss, bevor er durchscrollen kann.
Um diese Probleme anzugehen, hat Google “Benutzerzentrierte Leistungsmetriken” eingeführt. Wie der Name schon sagt, konzentrieren sich die neuen Metriken nicht nur auf die Seitenladegeschwindigkeit, sondern auch auf die Wahrnehmung des Benutzers beim Seitenladen.
Kurz gesagt hat Google das Seitenladen in verschiedene Phasen unterteilt:
- Wie schnell der Benutzer mindestens etwas sieht, damit er merkt, dass das Seitenladen begonnen hat.
- Wie schnell der Benutzer den Hauptinhalt der Seite sieht, damit er damit interagieren kann.
- Wie lange der Benutzer warten muss, bis er mit der Website interagieren kann.
- Ob sich Elemente der Website beim Laden erheblich verschieben oder nicht.
Im Allgemeinen berücksichtigt Google all diese Phasen neben dem “Ladeereignis”, um die Leistung der gesamten Seite zu messen.
| Metrik | Beschreibung |
| TTFB | Time to First Byte gibt die Zeit an, die es dauert, bis der Browser eines Benutzers das erste Byte des Seiteninhalts empfängt. |
| FCP | First Contentful Paint misst die Zeit vom Beginn des Ladens der Seite bis zum Zeitpunkt, an dem ein Teil des Seiteninhalts auf dem Bildschirm gerendert wird. |
| LCP | Largest Contentful Paint gibt die Renderzeit des größten sichtbaren Bildes oder Textblocks innerhalb des Viewports an. |
| CLS | Cumulative Layout Shift misst die Gesamtsumme aller einzelnen Layoutverschiebungswerte für jede unerwartete Layoutverschiebung, die während der gesamten Lebensdauer der Seite auftritt. |
| FID | First Input Delay misst die Zeit vom ersten Interagieren eines Benutzers mit einer Seite (d. h. wenn er auf einen Link klickt, auf eine Schaltfläche tippt oder eine benutzerdefinierte JavaScript-gesteuerte Steuerung verwendet) bis zur Zeit, zu der der Browser tatsächlich beginnen kann, Ereignishandler als Reaktion auf diese Interaktion zu verarbeiten. |
| TBT | Total Blocking Time ist die Zeitspanne, während der lange Aufgaben (alle Aufgaben länger als 50 ms) den Hauptthread blockieren und die Benutzerfreundlichkeit einer Seite beeinträchtigen. Es spiegelt wider, wie unempfindlich eine Seite ist, bevor sie vollständig interaktiv wird. TBT misst, was zwischen FCP und TTI passiert. |
| TTI | Time To Interactive gibt an, wie lange es dauert, bis die Seite vollständig interaktiv wird und wird in Sekunden gemessen. |
| Speed Index | Speed Index misst, wie schnell Inhalte während des Seitenladens visuell angezeigt werden. |
| INP | Interaction to Next Paint beobachtet die Latenz aller Interaktionen, die ein Benutzer mit der Seite durchgeführt hat, und gibt einen einzigen Wert an, dass alle (oder fast alle) Interaktionen darunter lagen. |
Man kann die Komplexität dieser benutzerzentrierten Leistungsmetriken durch den Lighthouse-Rechner erahnen. Obwohl CLS eine der Core Web Vitals ist, beeinflusst sie die Gesamtpunktzahl nur um 15%.
Was sind Core Web-Vitals?
Im Moment gibt es 3 Web Vitals, die Google für die wichtigsten gehalten hat.
Largest Contentful Paint (Größter Inhalt geladen)
LCP misst die “wahrgenommene Ladegeschwindigkeit”, indem die Zeit gemessen wird, die es dauert, bis das größte Element im Sichtfenster des Benutzers erscheint. Google empfiehlt, dass 75% Ihrer Seiten einen LCP-Wert unter 2,5 Sekunden erzeugen (segmentiert nach Mobil- und Desktop-Nutzern).
First Input Delay (Erste Eingabeverzögerung)
Der Wert FID misst die ‘Lade Reaktionsfähigkeit’, indem sie die Zeit zwischen der ersten Interaktion des Benutzers und der Auflösung dieser Interaktion misst. Diese Metrik zielt auf große JavaScript-Dateien ab, die nicht überprüft wurden und den Hauptthread des Browsers blockieren, wodurch die Interaktivität mit der Seite verzögert wird. Als Nutzer kann man in dieser Zeitspanne die Seite noch nicht benutzen. Google empfiehlt hier, dass 75% Ihrer Seiten einen FIP-Wert unter 100 ms erzeugen (segmentiert nach Mobil- und Desktop-Nutzern).
Seit März 2024 wird FID als Core Web Vital durch Interaction to Next Paint (INP) ersetzt.
Interaction to Next Paint ( Interaktionsreaktionszeit der Website)
INP beobachtet die Latenz aller Klick-, Tipp- und Tastaturinteraktionen mit einer Seite während ihrer gesamten Lebensdauer und meldet die längste Dauer und ignoriert Ausreißer. Ein niedriger INP bedeutet, dass die Seite durchweg schnell auf die überwiegende Mehrheit der Nutzerinteraktionen reagieren kann. Google empfiehlt, dass 75% Ihrer Seitenlatenzen einen FIP-Wert von unter 200Milisekunden erzeugen (segmentiert nach Mobil-und Desktopnutzern).
Cumulative Layout Shift (Kumulative Layout-Verschiebung)
CLS misst die “visuelle Stabilität”. Es ist eine kombinierte Metrik aus zwei Punkten berechnet wird.
- Wie weit verschieben sich HTML-Elemente während eines Ladevorgangs der Seite
- Wie weit wurde die Gesamtfläche verschoben
Auf diese Weise sind kleine Elemente, die sich stark verschieben, genauso schlecht wie große Elemente, die sich ein wenig verschieben. Google empfiehlt, dass 75 % Ihrer Seiten eine CLS-Bewertung von unter .1 ergeben (segmentiert nach Mobil- und Desktop-Nutzern).
Methoden zur Messung der Core Web Vitals und andere Sitespeed Metriken
Labordaten und Felddaten sind zwei Methoden, die Sie zur Bewertung der Leistung von Websites verwenden können. Im folgenden beschreibe ich, wie die beiden gemessen werden.
Labordaten
Labordaten können mithilfe der folgenden Leistungserfassungsdienste gemessen werden.
- WebPageTest – eines der besten Tools für Labordaten (meiner Meinung nach).
- Pagespeed Insights-Bericht – ein Standardtool von Google, das Lighthouse verwendet und einige Daten aus dem Chrome UX-Bericht enthält.
- Lighthouse – ein Standardtool von Google Chrome.
- GTMetrix – Website-Überwachungstool.
Beachten Sie, dass diese Performancedienste ihre Vor- und Nachteile haben.
| Vorteile | Nachteile |
| Daten können für separate URLs verfolgt werden. | Seitengruppen oder Daten von der gesamten Website können nicht verfolgt werden. |
| Die Leistung von Seiten auf Staging-Websites kann gemessen werden, um den Unterschied zwischen Website-Versionen (vor und nach Bereitstellungen) zu überprüfen. | Die von verschiedenen Diensten gegebenen Ratschläge widersprechen sich oft oder beeinflussen Metriken nicht. |
| Es werden Hinweise zur Optimierung der Ladezeit und Web Vitals gegeben. | Geschätzte Zahlen können zu falschen Eindrücken führen. |
Felddaten
Felddaten umfassen Chrome UX-Berichte und GA-Ereignisse.
Chrome UX-Berichte
Chrome UX-Berichte basieren auf einer kostenlosen Vorlage, die vom Chrome-Team bereitgestellt wird, und enthalten Daten zu Websites aus einer Chrome-Quelle.
Dieser CrUX-Bericht in Lookerstudio ist ein Beispiel für einen Chrome UX-Bericht.
| Vorteile | Nachteile |
| Zugriff auf echte Benutzerdaten zu Metriken, die im Feld gemessen werden können. | Separate URL-Daten oder Seitengruppen können nicht verfolgt werden (nur Ursprung und Domäne). |
| Es können sowohl historische als auch aktuelle Daten eingesehen werden. | Es werden nur monatliche Daten bereitgestellt. |
| Berichte werden nur am zweiten Dienstag des Monats aktualisiert. |
GA4-Ereignisse
Core Web Vitals-Ereignisse (Web-Vitals-Bibliothek) sind Ereignisse, die die Browser-API verwenden und Ereignisse an Google Analytics 4 (oder andere Quellen) senden.
| Vorteile | Nachteile |
| Separate URL-Daten, einige Seitengruppen oder ganze Websites können verfolgt werden. | Entwicklung oder GTM-Implementierung ist erforderlich. |
| Daten können für verschiedene Zeiträume wie monatlich, wöchentlich oder stündlich abgerufen werden. | Es werden viele Ereignisse an GA gesendet, daher wird nicht empfohlen, Daten zu allen Metriken zu senden. |
| Mit einigen Änderungen können Berichte verwendet werden, um Dashboards nach Zeiträumen, Geräten usw. zu erstellen. | Standardereignisse zeigen hauptsächlich Durchschnittswerte an, daher sind sie nicht sehr informativ. |
| Berichte können verwendet werden, um Ereignisse basierend auf Leistung zu segmentieren und zu analysieren. Nachteile: |
Um mehr über unsere Lösung zur Überwachung der Core Web Vitals mithilfe von GA und GTM zu erfahren, lesen Sie unseren Artikel “Core Web Vitals Report in GA4 und Looker Studio“.
Fazit
Zusammenfassend ist die Ladegeschwindigkeit einer Website ein wichtiger Faktor, der die Benutzererfahrung beeinflusst. Sie kann auch das Ranking einer Website in Suchmaschinen beeinflussen. Um die Benutzererfahrung zu verbessern, ist es entscheidend, die Core Web Vitals und andere Metriken zu überwachen. Es ist ebenso wichtig, den Unterschied zwischen Labordaten und Felddaten zu berücksichtigen – das Ziel besteht darin, die Leistung einer Website genau zu bewerten, wie sie von den Benutzern erlebt wird.
Hallo Tobias,
danke für dein tolles Tutorial. Ich habe ein Frage zu der Berechnung des 75% Perzentils.
Verstehe ich es richtig, dass das Perzentil in deinem Beispiel nur übergreifend für alle User Berechnet wird und mir eine nachträgliche Segmentierung, z.B. nur Nutzer mit Chrome Browser oder nur Nutzer mit iPhones damit nicht mehr möglich ist?
Ich erhebe die CWV-Daten in Google Analytics ja nur, um damit auf einer granulareren Ebene Auswertungen machen zu können.
Viele Grüße
Sebastian
Hi Sebastian,
danke für Dein Feedback! In meinem Beispiel ist das erstmal nicht filterbar, da hast du Recht! Aber das lässt sich theoretisch ja über die Abfrage in Google Sheets steuern: Wenn Du Dir dort weitere Dimensionen mit ausgibst pro Bericht, kannst du das später in Datastudio wiederum auch nutzen zur Filterung. Es ist ein kleiner “Datendurchstich” – wenn man das direkt mit allen erdenklicken GA-Dimensionen machen will, würde ich lieber mit Bigquery arbeiten statt mit den Tabellen.
Viele Grüsse
Tobias