Wenn wir den Pagespeed einer Webseite messen wollen, dann kommen oft Tools wie das Google Pagespeed Insight-Tool, Webpagetest.org oder Pingdom zum Einsatz. Und wenn wir von Pagespeed sprechen, dann nimmt der Faktor Zeit eine zentrale Rolle ein. Während Tools wie Pingdom oder Webpagetest.org die Zeit, die eine Webseite braucht um vollständig zu laden, messen und ausgeben, musste man sich bei Google Pagespeed Insights lange Zeit mit einem Punktesystem zufrieden geben. Das soll keine Kritik am Tool sein. Im Gegenteil: Google Pagespeed Insights schlug wichtige technische Optimierungsaspekte vor, die maßgeblich dazu beitrugen den Pagespeed einer Seite zu erhöhen. Man hatte jedoch keinen Zeitfaktor, an den man sich orientieren konnte.

Mittlerweile zeigt aber auch das Pagespeed-Tool von Google Zeitmessungen an, die auf der Lighthouse-Engine basieren. Lighthouse greift wiederum auf die Daten aus dem Chrome User Experience Report (CrUX) zurück. Aus dem CrUX-Report kommen dann ganz interessante Kennzahlen, die sogenannten “User-centric Performance Metrics”, auf die ich in diesem Artikel näher eingehen möchte.

Chrome User Experience Report

Der Chrome User Experience Report liefert Pagespeed-Kennzahlen auf Basis von echten Nutzerdaten. Diese Daten werden gesammelt, sofern der Nutzer…

• …einen Opt-In für die Synchronisierung der Browser-History durchgeführt hat.
• …nicht Sync Passphrase aktiviert hat.
• …der Nutzung der Daten zugestimmt hat.

Einige dieser Kennzahlen werden auch in den Pagespeed Insights gezeigt (sofern Google hier Daten vorliegen hat). Zudem hat Google bestätigt, dass die Daten aus dem Chrome User Experience Report in die Ranking-Berechnung einfließen (plus einiger anderer unbekannter Pagespeed-Daten).

Was sind die User-centric Performance Metrics?

In meinem Artikel zum Thema “Critical Rendering Path” bin ich darauf eingegangen wie wichtig es ist, dass der sofort sichtbare Bereich einer Webseite bevorzugt geladen werden muss. Dabei gibt es verschiedene Ansätze zur Optimierung des kritischen Rendering-Pfads. Basis für die Ableitung von Optimierungsmaßnahmen ist immer eine Analyse. Wichtig bei der Analyse des Pagespeeds ist nicht nur die Seitenladegeschwindigkeit im Allgemeinen – z.B. “die Seite lädt in 4 Sekunden” – sondern wir brauchen feinere Kennzahlen, die den Aufbau der Webseite in verschiedenen Meilensteinen unterteilen, damit wir so ein detailliertes Bild der Performance bekommen. Angefangen bei der Antwort des Servers an den Browser bis zum vollständigen Laden der Seite. In diesem Fall hätte man beim Pagespeed 2 Meilensteine:

1. Time To First Byte (TTFB)
2. Page Load Time (window.loaded oder document.complete)

Die 2017 vorgestellte Paint-Timing API gibt uns jedoch zusätzliche Meilensteine beim Laden der Webseite, die wir analysieren können. Diese “Paint-Timings” sind Teil des anfangs erwähnten Chrome User Experience Report (CrUX) und bilden die User-centric Performance Metrics:

1. First Paint (FP): Zeitpunkt, an dem der Browser zum ersten Mal ein Pixel ausspielt.
2. First Contentful Paint (FCP): Zeitpunkt, an dem der Browser zum ersten Mal ein Element komplett ausspielt (z.B. Text oder Bild).
3. First Meaningful Paint (FMP): Zeitpunkt, an dem der Browser die Seite so geladen hat, dass der Nutzer das Gefühl hat die Seite wäre vollständig geladen. An diesem Zeitpunkt ist das wichtigste Element vorhanden, welches auch als “Hero Element” bezeichnet wird.
4. Time to Interactive (TTI): Zeitpunkt, an dem die Webseite bereit für Nutzereingaben ist.
5. Long Tasks: Dies sind Ladevorgänge, die im Hintergrund weiterhin ablaufen (länger als 50 Millisekunden), obwohl man mit der Webseite schon interagieren kann.

Für meine Seite würde das visuell folgendes bedeuten:

Im Gesamtbild heißt das:

1. Time To First Byte (TTFB)
2. First Paint (FP)
3. First Contentful Paint (FCP)
4. First Meaningful Paint (FMP)
5. Time to Interactive (TTI)
6. Long Tasks
7. Page Load Time (PLT)

Vorteil von User-centric Performance Metrics

Die 2 wichtigsten Argumente für den Einsatz der UPM sind:

• Die Daten basieren auf echten Nuterdaten und Nutzerzugriffen.
• Setzt man Google Analytics zum Messen der Kennzahlen ein (Details weiter unten), dann werden diese laufend mitgemessen und man kann sich so ein Gesamtbild und einen Gesamttrend verschaffen. Zudem werden alle Seiten getrackt. Punktuelle Analyen und das aufwendige Eingeben mehrerer URLs in den URL-Schlitz von Tools entfallen.

Browser-Unterstützung

Bevor wir ins Detail gehen und uns die technische Implementierung ansehen, sollte man hinsichtlich Browser-Unterstützung folgendes beachten.

• Chrome: Funktioniert ab Version 64
• Internet Explorer: Keine Unterstützung
• Firefox: Funktioniert ab Version 57

User-centric Performance Metrics im Detail

Schauen wir uns die Kennzahlen etwas näher an und was man tun kann um diese zu optimieren.

First Paint (FP)

FP ist der Zeitpunkt, an dem der Browser das erste Pixel ausspielt (irgendetwas direkt nach dem weißen Screen). Das kann ein Punkt sein, die Hintergrundfarbe oder einfach ein Strich.

Wie kann man den FP optimieren?
Siehe dazu die Optimierungsvorschläge weiter unten aus dem FCP-Bereich an. Diese Maßnahmen helfen auch den FP zu optimieren.

First Contentful Paint (FCP)

FCP ist der Zeitpunkt, an dem der Browser zum ersten Mal ein Element komplett ausspielt. Dies ist auch ein ganz wichtiger Zeitpunkt für den Nutzer, der hier eine erste Rückmeldung bekommt, dass sich auf der Seite was tut.

Wie kann man den FCP optimieren?
Für die Optimierung des FCP ist eine schnelle Übertragung der Daten vom Server zum Browser wichtig, damit dieser schnellstmöglich das erste Element ausspielen kann. Dazu sollten folgende Optimierungen vorgenommen werden. Hauptsächlich kommen hier die üblichen Pagespeed-Optimierungen zum Einsatz:

• Bytes minimieren: Wichtigster Punkt ist die Reduzierung der Gesamtdateigröße des herunter zu ladenden Dokuments. Hier sollten Kommentare, Leerzeichen und nicht benötigte Codes aus HTML-, CSS- und JS-Dateien entfernt werden.
• Komprimierung: Um die Dateigrößen weiter zu reduzieren ist Komprimierung ein wichtiger Aspekt. Dazu können Techniken wie GZIP und Brotli eingesetzt werden.
• Schnelles CSS und JavaScript: Wichtig ist zudem, dass CSS und JavaScript so schnell wie möglich zur Verfügung stehen. Asynchrones Laden sollte hier eingesetzt werden, damit diese Dateien das Rendering nicht blockieren.
• HTTP/2: Damit viele Dateidownloads parallel stattfinden können, sollte nach Möglichkeit HTTP/2 eingesetzt werden.
• Caching: Um zu verhindern, dass Dateien jedes Mal neu geladen werden müssen, solltest du HTTP-Caching einsetzen.

First Meaningful Paint (FMP)

FMP ist der Zeitpunkt, an dem der Browser die Seite so geladen hat, dass der Nutzer das Gefühl hat die Seite wäre vollständig geladen. Hier spricht man auch meist vom Laden des Bereichs “Above-the-Fold”, da hier meist auch das wichtigste Element vorzufinden ist (Hero Element). Dies ist aus Sicht des Nutzers auch der wichtigste Meilenstein beim Ausspielen der Seite. Bei einem Blog-Beitrag wäre das Hero Element der komplette Beitrag, bei einer Bilder-Galerie-Seite sind es die Bilder, bei einer YouTube-Seite das Video.

Wie kann man den FMP optimieren?
Für die Optimierung des FMP ist es besonders wichtig, dass der sofort sichtbare Bereich bevorzugt geladen wird. Dabei geht es hauptsächlich um die Optimierung von:

• Critical Rendering Path: Die Optimierung des kritischen Rendering Pfades ist hier essentiell (Above-the-Fold). Viele der oben genannten Aspekte unter FP und FCP zahlen schon darauf ein. Wie du den Critical Rendering Path weiter optimieren kannst, beschreibe ich in meinem Artikel “Critical Rendering Path verstehen”.
• Medien: Bilder sind die Elemente auf der Webseite, die erfahrungsgemäß bei den meisten Webseiten den Pagespeed negativ belasten. Unoptimierte Bilder – vor allem im kritischen Rendering Pfad – können die Webseite deutlich verlangsamen. Hier sollten die Bilder wie hier beschrieben optimiert werden. Das Gleiche gilt allgemein für Medien-Inhalte wie Videos, etc.

Time To Interactive (TTI)

TTI ist der Zeitpunkt, an dem die Webseite bereit für Nutzereingaben ist. An diesem Punkt muss die Webseite noch nicht komplett fertig geladen worden sein. Zum Beispiel kann die Webseite im Hintergrund noch laden, während aber das schon vorhandene Formular benutzt werden kann und auf Benutzereingaben reagiert. Aus technischer Sicht wird TTI ab DOMContentLoaded angefangen zu erfassen.

Wie kann man den TTI optimieren?
Hier spielt vor allem das eingesetzte JavaScript eine entscheidende Rolle:

• Basics: Wie schon unter den Optimierungsansätzen bei FCP genannt, sollte nicht gebrauchter JS-Code entfernt werden. Bestehender JS-Code sollte komprimiert werden.
• async und defer: Bei JavaScript-Dateien sollte zudem geprüft werden, welche Skripte als “async” und welche als “defer” markiert werden können, um hier Verbesserungen herbeizuführen.

Long Tasks

Bei Long Tasks handelt es sich um Ladevorgänge, die länger als 50 Millisekunden brauchen. Die 50-Millisekunden-Regel stammt vom RAIL-Modell.

Bei der Interpretation dieser Kennzahl muss man beachten, dass man die getrackte Zeit nicht mit der Zeitmessung wie bei FP oder FCP gleichstellen kann. FP bspw. beginnt ab dem Zeitpunkt des Ladens der Webseite. Bei Long Tasks handelt es sich um eine Metrik, die die Zeitdauer einzelner Long Tasks darstellt. Hier muss der Beginn des Ladens nicht der Beginn des allgemeinen Seitenladens sein.

Wie kann man Long Tasks optimieren?
Bei Long Tasks muss zunächst geprüft werden welches Skript dies betrifft. Wenn es ein internes Skript ist, so kann es Sinn machen dieses zu splitten. Code der für die aktuelle Seite nicht benötigt wird, sollte auch nicht ausgespielt werden. Code, der erst später benötigt wird, kann z.B. am Ende der Seite gesondert geladen werden. Setzt man auf einer Seite bspw. ein Formular ein und ist dieses das Hero Element so sollte zunächst der JS-Code bevorzugt geladen werden, der für die Nutzung des Formulars erforderlich ist. Anderen Funktionalitäten können gesplittet werden und nachgelagert geladen werden. So vermeidet man große Skripte, die Long Tasks verursachen.

Weiterhin können externe Skripte wie Tracking-Codes oder Third-Party-Tools die Long Tasks negativ beeinflussen. Hier gilt: Nur Skripte einsetzen, die unbedingt notwendig sind. Beim Einsatz mehrerer Tracking-Systeme sollte man sich z.B. Gedanken machen, ob die Fokussierung auf eines davon ausreichen würde.

Analyse der User-centric Performance Metrics

Es gibt verschiedene Möglichkeiten wie man die Kennzahlen näher beleuchten kann. Nachfolgend stelle ich folgende Möglichkeiten vor.

• Paint-Timings in der Chrome Developer Console darstellen
• PerformanceObserver mit Google Analytics
• Google Pagespeed Insights und Lighhouse
• Einsatz von Google BigQuery für FCP der Wettbewerber

Paint-Timings in der Chrome Developer Console darstellen

Die einzelnen Messwerte kann man für jede URL in der Chrome Developer Console sehen. Dazu geht man mit F12 in die Console. Geht dann zum Tab “Performance”, wählt dort die Option “Screenshots” und dann den Punkt “Enable advanced paint instrumentaion (slow)” und lädt die Seite neu. Nachdem die Seite fertig geladen wurde, klickt man links auf “Frames”. Danach sieht man die einzelnen Messwerte grafisch abgebildet.

PerformanceObserver mit Google Analytics

Um die Kennzahlen laufend zu messen, kann man sich die Messwerte in Google Analytics einrichten. Dazu muss man im Google Analytics-Code den PerformanceObserver einrichten. Der Code für FP und FCP sieht dann folgedermaßen aus:

<head>
<!-- Add the async Google Analytics snippet first. -->
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src='https://www.google-analytics.com/analytics.js'></script>
<!-- Register the PerformanceObserver to track paint timing. -->
<script>
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// `name` will be either 'first-paint' or 'first-contentful-paint'.
const metricName = entry.name;
const time = Math.round(entry.startTime + entry.duration);
ga('send', 'event', {
eventCategory: 'Performance Metrics',
eventAction: metricName,
eventValue: time,
nonInteraction: true,
});
}
});
observer.observe({entryTypes: ['paint']});
</script>
<!-- Include any stylesheets after creating the PerformanceObserver. -->
<link rel="stylesheet" href="...">
</head>


Mit diesem Code wird zunächst der Google Analytics Code geladen, um Pageviews zu erfassen. Danach wird der PerformanceObserver registriert, der dann FP und FCP erfasst. Erst im Anschluss sollten CSS-Dateien geladen werden, damit das Tracking funktioniert.

Um FMP messen zu können muss mehr getan werden. Hierzu bedarf es einer API. Für individuelle Messpunkte bietet die W3C User Timing-Spezifikationen auf https://www.w3.org/TR/user-timing/. Dies geschieht über 2 Hauptfunktionen:

• performance.mark
• performance.measure

Für detailliertere Informationen hinsichtlich technischer Implementierung empfehle ich den Artikel dazu von Steve Souders.

Für die Messung von TTI muss ein Polyfill eingesetzt werden:

import ttiPolyfill from './path/to/tti-polyfill.js';
ttiPolyfill.getFirstConsistentlyInteractive().then((tti) => {
ga('send', 'event', {
eventCategory: 'Performance Metrics',
eventAction: 'TTI',
eventValue: tti,
nonInteraction: true,
});
});


Für Longtasks sieht der Code wie folgt aus:

const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
ga('send', 'event', {
eventCategory: 'Performance Metrics',
eventAction: 'longtask',
eventValue: Math.round(entry.startTime + entry.duration),
eventLabel: JSON.stringify(entry.attribution),
});
}
});
observer.observe({entryTypes: ['longtask']});


Neben Google Analytics lässt sich das Ganze auch über den Google Tag Manager implementieren. Wichtig bei der Auswertung: Kombiniere die Daten mit Dimensionen. Erst dann wird es spannend!

Google Pagespeed Insights und Lighhouse

Google Pagespeed Insights liefert unter dem Punkt “Labdaten” ebenfalls einige Werte aus dem CrUX-Report:

Die einzelnen Angaben können wie folgt übersetzt werden:

• Erste Inhalte gezeichnet = First Contentful Paint
• Inhalte weitgehend gezeichnet = First Meaningful Paint
• Zeit bis Interaktivität = Time to Interactive

Einsatz von Google BigQuery für FCP der Wettbewerber

Die Kennzahl FCP aus den User-centric Performance Metrics kann man auch bei Wettbewerber-Domains einsehen. Hierzu muss man über die Google Cloud Plattform mittels Google BigQuery auf die Schnittstelle zugreifen. Zudem kann man die Zahlen direkt in Google Data Studio importieren. Eine Detail-Anleitung wie man das hinbekommt ist hier zu finden.