Besseres Messen von Webseite-Ladegeschwindigkeit mit Paint- & User-Timings

Hat man sich in der Vergangenheit bereits einmal mit der Optimierung von Webseite-Ladegeschwindigkeit beschäftigt, wurde meist unweigerlich auch auf Googles kostenloses PageSpeed-Insights-Tool (PSI, einfach.st/gpsi) zurückgegriffen – sozusagen um auch den „offiziellen“ Blick des Suchmaschinengiganten auf die Geschwindigkeit der eigenen Seite mit zu berücksichtigen. Kritiker monieren hier zu Recht, dass – neben der Tatsache, dass hier zum Teil Optimierungsempfehlungen geliefert werden, die schlicht nicht umsetzbar sind (ich als Seitenbetreiber kann ja nicht die Caching-Dauer des Facebook-Pixels beeinflussen) –, beispielsweise eine Bewertung der Form „89/100“ relativ wenig über die eigentliche Ladegeschwindigkeit einer Webseite aussagen kann. Und noch viel weniger kann diese Zahl reflektieren, wie schnell ebendiese Webseite gefühlt lädt. Eine einzelne Zahl kann dies schlicht nicht leisten.

Paint-Timings: Mehrere Schritte bis zum vollständigen Seitenaufbau

Die Paint-Timing API (http://einfach.st/w3paint), deren Spezifikation im September 2017 veröffentlicht und durch das Chrome-Browser-Team im März 2018 mit dem Chrome 65 Release implementiert wurde, erlaubt den Zugriff auf verschiedene Paint-Zustände. Darüber hinaus finden aktuell folgende Metriken entsprechend Anwendung:

1. Time to First Paint (FP) – der Punkt, an dem der Browser irgendeinen beliebigen Inhalt anzeigt. Dies kann im Grunde jedes Element sein, z. B. eine einzelne Linie, ein Punkt etc. – oder auch das Ausspielen der Hintergrundfarbe.
2. Time to First Contentful Paint(FCP) – der Punkt, an dem der Browser einen ersten, wirklichen Inhalt aus dem DOM anzeigt. In der Regel ist das entweder ein Text oder ein Bild.
3. Time to First Meaningful Paint (FMP) – bezeichnet den Zeitpunkt, an dem der Benutzer den wichtigsten Inhalt (das „Hero-Element“) einer jeweiligen URL als fertig geladen empfindet.
4. Time to Interactive (TTI) – der Zeitpunkt, an dem die Webseite gemeinhin als bedienbar gilt.

Die spannendste Render-Metrik ist derzeit wohl die Time to First Meaningful Paint, reflektiert sie doch am besten, wie schnell – pro Seitentyp/Template – das für den Besucher wichtigste Element angezeigt wird. Hier wird häufig von dem sogenannten Hero-Element gesprochen, also dem für den Besucher wichtigsten Element. Besucht jemand beispielsweise YouTube, so ist das für ihn mit Abstand wichtigste Element das jeweilige Video; alle anderen Elemente sind weniger relevant und könnten demnach auch mit Zeitverzug geladen werden.

Paint-Timings in der Chrome Developer Console darstellen

Die in den Chrome Browser integrierte Developer Console (unter Windows z. B. erreichbar mit der Tastenkombination Strg + Shift + i) erlaubt eine komfortable Darstellung der oben genannten Messpunkte. Dazu wechseln Sie einfach in den Tab „Performance“, wählen dort die Optionen „Screenshots“ sowie „Enable advanced paint instrumentation“ an und laden im Anschluss die gewünschte Seite neu.

Nach Abschluss des Ladevorgangs navigieren Sie nun in der linken Navigation zum Punkt „Frames“ und klappen diesen auf. Dort finden sich nun, anlog zur Zeitachse oben im Bild, die einzelnen Messpunkte grafisch aufbereitet.

PerformanceObserver im Chrome Browser

Für eine kontinuierliche und nicht nur punktuelle Messung von Paint-Timings kann beispielsweise Google Analytics verwendet werden. Dabei ist der gemeinhin bekannte Google-Analytics-Standardcode um den sogenannten PerformanceObserver zu erweitern, was in der Praxis folgendermaßen aussieht:

Was geschieht hier im Detail?

1. Einbinden des asynchronen Google-Analytics-Standard-Snippets (inkl. Spezifizierung der Account-ID in der Form UA-XXXX-Y sowie Messen eines Seitenaufrufs).
2. Registrierung einer Instanz des PerformanceObservers, welcher in der Folge auf die Standardevents „First Paint“ sowie „First Contentful Paint“ reagieren und diese als Events in der Kategorie „Performance Metrics“ speichern wird.
3. Das alles geschieht, bevor das erste Stylesheet (CSS) aufgerufen wird, hier exemplarisch in der vorletzten Zeile dargestellt.

Ein kurzer Hinweis zum Thema Kompatibilität: Das Chrome-Team hat den PerformanceObserver ab Version 64 implementiert, sprich Vorgängerversionen können hier keine Daten erfassen. Die Browser von Microsoft (Internet Explorer sowie Edge) bieten (noch) keinerlei Unterstützung. Im Firefox 57 (Quantum) funktioniert das Ganze auch, in den Vorversionen wiederum nicht.

PerformanceObserver mittels Google-Tag-Manager

Viele Webseiten-Betreiber verwenden mittlerweile allerdings gar keine native Template-Integration von Google Analytics mehr, sondern setzen vielmehr auf eine zentralisierte Tag-Management-Lösung, wie zum Beispiel den Google-Tag-Manager. Von dieser Lösung ausgehend werden dann, meist abhängig von URLs oder anderen, internen Regeln, alle notwendigen Tracking-Pixel ins Template integriert und entsprechend ausgelöst. Mit ein wenig Überzeugungsarbeit bzw. einigen Code-Anpassungen kann der PerformanceObserver natürlich auch über den Google-Tag-Manager ausgespielt werden:

Der versierte Tag-Manager-Benutzer weiß natürlich schon, dass neben dem Code dennoch, wie auch für alle anderen Pixel-Events entsprechend, die Tag-, Variable- und Trigger-Configuration weiterhin notwendig ist.

Verwenden von individuellen Messpunkten

Die W3C User Timing-Spezifikation (http://einfach.st/w3user) bietet zudem eine API, um benutzerdefinierte Metriken in Templates zu integrieren und damit noch granularer zu messen. Dies geschieht über zwei Hauptfunktionen:

• performance.mark zeichnet die Zeit (in Millisekunden) seit navigationStart auf
• performance.measure erfasst das Delta zwischen zwei einzelnen Markern

Auch hier ein kurzer Hinweis zum Thema Kompatibilität: Die User Timing API ist allen aktuellen Browsern verfügbar. In den folgenden Beispielen wird daher die native API verwendet, im Live-Code sollte dennoch immer auf Kompatibilität geprüft oder ein Wrapper verwendet werden. Eine gute Polyfill gibt es von Pat Meenan unter einfach.st/github4.

Die User-Timing API ist insgesamt relativ einfach gehalten, dennoch kann es manchmal schwierig sein zu wissen, wann entsprechende Marker Sinn machen. Das liegt primär an der komplexen Funktionsweise des jeweiligen Browsers und vor allem an der Art und Weise, wie beispielsweise CSS und synchrone JavaScripte das Parsen und Rendern möglicherweise blockieren. Es soll an dieser Stelle auch nicht unerwähnt bleiben, dass die folgenden Beispiele insgesamt deutlich vereinfacht wurden. In vielen Fällen ist nicht sofort offensichtlich, warum eine Webseite beispielsweise erst mit einer Verzögerung beginnt, entsprechende Inhalte zu rendern. Der Teufel steckt häufig sprichwörtlich im Detail.

Anwendungsfall #1: Stylesheets blocken nicht mehr die Ausgabe

Das Laden eines Stylesheets blockiert das Rendern der gesamten Seite. Für den Besucher passiert zu diesem Zeitpunkt rein gar nichts. Dies gilt sowohl für alle gängigen Browser als auch für dynamisch geladene CSS. Daher empfiehlt es sich zu messen, wann alle Stylesheets (sofern mehr als eines vorhanden ist) fertig prozessiert und den „Blocking“-Zustand verlassen haben. Dies kann folgendermaßen passieren:

Ein ähnliches Vorgehen ist beispielsweise auch für JavaScript denkbar, hier ist allerdings zu beachten, dass Messpunkte durch etwaige asynchrone Skripte oder solche, die im Footer (nachträglich) geladen werden, möglicherweise nicht mehr akkurat ausfallen.

Anwendungsfall #2: Das Hero-Element wird dem Besucher angezeigt

Wie eingangs erwähnt, konzentrieren sich Besucher in der Regel auf ein oder evtl. mehrere kritische Designelemente auf der Seite – das sogenannte Hero-Element. Auch die zugehörige Ladezeit lässt sich mittels Markern entsprechend erfassen:

Die Änderung hier ist die kombinierte Verwendung des onload-Events innerhalb des <img>-Tags gemeinsam mit dem inline-Skript. Nur dadurch wird genau erfasst, wann das Bild tatsächlich gerendert wird. Das onload-Event liefert die Renderzeit, wenn der Bilddownload länger dauert als die blockierenden Ressourcen. Der inline-Marker spiegelt die Renderzeit wider, wenn das Bild schnell heruntergeladen wird, aber blockierende Ressourcen (wie zuvor genannte CSS/JS) verhindern, dass das Bild angezeigt wird.