Performance-Boost (2): Web Vitals verstehen

Bevor wir in die Tools einsteigen, die du für solche Zwecke verwenden kannst, sollten wir ein paar Begrifflichkeiten klären, die uns in diesem Zusammenhang immer wieder über den Weg laufen werden. Deshalb schauen wir uns im Folgenden die Core Web Vitals aber auch weitere Web Vitals im Detail an. Ich zeige dir eine ganze Menge relevanter Metriken, die wir im nächsten Artikel dann mit Messungen genauer unter die Lupe nehmen werden.

Labordaten sind Daten, die ich unter kontrollierten Bedingungen erhebe. Das kann zum Beispiel eine Performancemessung von einer Hardware aus sein, die unter meiner Kontrolle steht und deren Auslastung und Netzwerkanbindung ich gut kenne (beispielsweise mein Notebook an meinem heimischen Internetanschluss). Der Vorteil von Labordaten besteht darin, dass ich eine gute Vergleichbarkeit zwischen verschiedenen Messungen herstellen kann. So kann ich beispielsweise vor und nach der Implementierung eines Features eine identische Messung durchführen, um den Einfluss des Features auf die Seitenperformance zu messen. Was ich mit Labordaten allerdings nicht ohne weiteres abbilden kann, ist die tatsächliche Performance einer Website bei den Seitenbesuchern. Denn diese nutzen unterschiedliche Hardware und Internetanbindungen, sitzen an unterschiedlichen Standorten und navigieren unterschiedlich über eine Internetseite.
 

Felddaten helfen mir hingegen dabei herauszufinden, wie schnell die Seite bei meinen echten Besuchern ist. Denn genau dort werden diese Daten erhoben − beispielweise über die Chrome User Experience Report (CrUX) oder über eigene Implementierungen. Für Letztere kann ich zum Beispiel die Web Vitals mit Hilfe einer Javascript-Bibliothek messen. Mit diesen Daten ist es also möglich zu ermitteln, wie schnell meine Website tatsächlich „in freier Wildbahn“ ist. Den Effekt von Optimierungen sehe ich dabei natürlich nur in langfristigen Trends. Außerdem kann ich diese Daten nur erheben, wenn eine Website schon live ist − während des Entwicklungsprozesses gibt es diese Daten schlicht noch nicht.

Bevor du dich aber daran machst, Daten zu erheben und zu interpretieren, musst du noch wissen, welche Metriken überhaupt angewendet werden sollen. Damit du dir nicht selbst Metriken ausdenken und Tools dafür bauen musst, greifst du dabei am besten auf Altbewährtes zurück.

Wenn man sich mit der Performance-Analyse von Websites beschäftigt, führt in der Regel kein Weg an den Core Web Vitals vorbei. Dabei handelt es sich um drei zentrale Metriken, die von Google im Rahmen der Web Vitals-Initiative definiert wurden, um die User Experience einer Website messbar zu machen. Daher umfassen sie genau genommen nicht nur Metriken rund um das Thema Performance sondern auch das Nutzererlebnis beim Navigieren über die Webseite.

Wir schauen uns im Folgenden diese drei zentralen Metriken an und werfen danach einen Blick auf weitere Web Vitals, die auf die Website-Performance (und die Core Web Vitals) einzahlen.

Mit dem Largest Contentful Paint (kurz: LCP) wird die Zeit bezeichnet, die beim Laden einer Website vergeht, bis das größte Inhaltselement für den Besucher sichtbar ist. Da die Anzeige dieses Elements bei den meisten Websitebesuchern das Gefühl auslöst, dass die Seite „fertig geladen“ wurde, wird dieser Wert für die Beurteilung der Seitenladezeit herangezogen. Auf vielen Websites ist das Element im oberen Seitenbereich, bspw. ein Banner. Google findet es gut, wenn der LCP unter 2,5 Sekunden liegt. Bei uns auf mittwald.de ist das aktuell zum Beispiel dieser rot umrandete Bereich:

Der First Input Delay (kurz: FID) beschreibt die Zeit, die zwischen der ersten Interaktion eines Benutzers mit der Website und dem Beginn der Verarbeitung  durch den Browser vergeht. Dabei wird nicht berücksichtigt, wie lange es dauert, bis die Benutzereingabe auch tatsächlich verarbeitet wurde. Das Ziel ist es, näherungsweise die Interaktivität einer Seite zu beurteilen. Eine Interaktion ist zum Beispiel der Klick auf einen Link oder Button, auf der Website zu scrollen und so weiter.

Wenn ich also nach dem Aufruf einer Seite auf einen Button klicke und der Browser erst mit Verzögerung darauf reagiert, habe ich so einen First Input Delay erlebt. Um zu verstehen, wie dieser Delay gemessen wird, müssen wir ein wenig in die Funktionsweise eines Browsers eintauchen.

Wir müssen zuerst verstehen, was der Main Thread (Hauptprozess) im Browser ist. Innerhalb des Main Threads führt der Browser unter anderem das Javascript der Seite in einzelnen Tasks − also Unterprozessen − aus. Dabei können Tasks nicht parallel laufen, sondern werden nacheinander abgearbeitet. Wenn nun mehrere Tasks in der Warteschlange sind, kommt es zu einer Blockierung. Benötigt ein Task mehr als 50ms, spricht man von einem Long Task. Stellen wir uns einmal vor, unser Browser wäre eine Disco. Wenn ich rein möchte (Interaktion) und der Laden voll ist (laufender Long Task), muss ich warten. Ich warte also so lange, bis jemand die Disco verlässt (Long Task ist abgeschlossen). Nun darf ich eintreten (meine Interaktion wird ab jetzt verarbeitet). Die Zeit, die ich warten musste, beschreibt den FID:

Es gibt natürlich auch den Fall, dass die Disco gerade voll ist (ein Long Task läuft), ich aber noch gar nicht reingelassen werden möchte. Vielleicht habe ich ein paar Freunde getroffen und unterhalte mich noch kurz (ich führe keine Interaktion aus, sondern schaue mir zum Beispiel ein Bild auf der Website genauer an). Wenn ich damit fertig bin und ich direkt eingelassen werden kann, habe ich genau genommen gar nicht warten müssen (es gibt für mich also gar keinen FID).

Führt ein Websitebesucher also eine Interaktion aus, sollte im Idealfall gerade kein (Long) Task mehr laufen, damit die Eingabe direkt verarbeitet werden kann. Wenn gerade noch ein Task läuft, ist es gut, wenn dieser die Eingabeverarbeitung nur für eine kurze Zeit verzögert.

Google ist glücklich, wenn der FID unter 100ms liegt. Dabei müssen wir beachten, dass der FID nur schwer mit Labordaten zu messen ist. Denn wann ein Websitebesucher das erste Mal mit der Website interagiert, können wir nur raten. Oder um bei unserer Metapher zu bleiben: Für manche Disco-Besucher ist es nicht schlimm, wenn gerade kein Platz frei ist, weil sie noch mit etwas anderem beschäftigt sind. Für jemanden, der direkt eingelassen werden möchte, ist eine volle Disco aber nervig.

Da der FID nicht berücksichtigt, wie lange die Verarbeitung der Interaktion benötigt, ist mit dem INP (Interaction to Next Paint) schon die nächste Evolutionsstufe dieser Metrik in der Mache. Da es sich noch um ein experimentelles Feature handelt, sei an dieser Stelle einmal auf diese Dokumentation verwiesen, die den Entwicklungsstand immer aktuell abbilden sollte.

Beim Cumulative Layout Shift (kurz: CLS) handelt es sich um eine Metrik, mit der die (unerwartete) visuelle Veränderung einer Website gemessen wird. Dies kann aus verschiedenen Gründen passieren, beispielsweise, weil ein Bild erst spät nachgeladen wird oder weil auf einmal eine Werbeanzeige auf der Seite erscheint. Falls dabei der bereits sichtbare Content verschoben wird, handelt es sich um einen Layout Shift, der für die User-Experience nachteilig ist. Du hast es sicherlich schon häufiger auf News-Seiten erlebt, dass auf einmal Werbung in den Content geladen wird und du deswegen aus Versehen auf den falschen Link geklickt hast.

Der CLS ist am Ende ein errechneter Wert, der sich daraus ergibt, welcher Teil einer Website einer Veränderung unterliegt und wie groß der betroffene Bereich dabei ist. Da auch diese Metrik immer mal wieder überarbeitet wird, sei hierbei ebenfalls auf die Dokumentation verwiesen, die die mathematischen Grundlagen erklärt. Der CLS ist insofern auch für die Performance einer Website relevant, da ein hoher CLS durch Implementierungen auftreten kann, die auch aus Performance-Sicht ein Problem sind. Setze ich zum Beispiel ein Javascript ein, das nach einer Ausführungszeit von einer Sekunde das Layout verändert, erzeuge ich sowohl einen hohen FID, als auch einen hohen CLS. Aus Sicht von Google sollte der errechnete CLS unter 0,1 liegen.

Neben den Core Web Vitals gibt es noch weitere Messgrößen, die häufig zu Rate gezogen werden oder anderweitig Teil der Berechnung eines Core Web Vitals sind. Darüber hinaus stolpert man im Performance-Kontext noch über zusätzliche Abkürzungen und Beschreibungen, von denen ich euch hier die wichtigsten nennen möchte.

Beim Above-the-fold-Content handelt es sich um den Teil einer Website, der für den Besucher ohne zu scrollen sichtbar ist. Ursprünglich stammt der Begriff aus der Zeitungsbranche und bezeichnet da den Teil, den man bei einer gefalteten Zeitung sofort sehen kann − also den oberen Teil der Titelseite mit der Hauptstory. Gleichsam gibt es das Gegenstück below the fold, mit dem der Inhalt bezeichnet wird, für den man erst einmal scrollen muss.

Im gleichen Atemzug ist auch oft die Rede vom Critical CSS. Dabei handelt es sich um das CSS, was für die Darstellung des Above-the-fold-Contents zwingend notwendig ist. Dieses CSS sollte (bzw. muss) früh geladen werden und darf das Rendering durch den Browser auch blockieren − andernfalls kann es zu einem FOUC (s. u.) kommen. Das CSS für den Below-the-fold-Content sollte hingegen spät geladen werden und das Rendering des Above-the-fold-Contents nicht blockieren.

Gleiches gilt natürlich auch für eingebundenes Javascript und Bilder. Auch diese Ressourcen sollten früh geladen werden, wenn sie für den Above-the-fold-Content relevant sind und spät, wenn sie nur below the fold benötigt werden. Der LCP befindet sich natürlich immer im Above-the-fold-Content.

Der First Paint beschreibt Zeit, die vergeht, bis sich der erste Pixel im Viewport verändert − also sich irgendetwas in der Ansicht im Browser verändert. Da zu diesem Zeitpunkt für den Benutzer nur klar wird, dass sich „irgendetwas“ tut, ist es für die User Experience nur bedingt relevant.

Beim First Contentful Paint handelt es sich um die Zeit, die vergeht, bis der Browser das erste Inhaltselement der Seite darstellen kann − bspw. ein Text oder Bild. Im Gegensatz zum Largest Contentful Paint (LCP), kann das irgendetwas sein − vielleicht auch nur die Hintergrundfarbe. Da Benutzer aber nicht unbedingt warten, bis eine Seite vollständig geladen ist, kann dieser Wert für die Berechnung des FID (First Input Delay) relevant sein, da man ab diesem Zeitpunkt damit rechnen muss, dass der Benutzer anfängt zu klicken.

Der First Meaningful Paint war der Vorgänger des Largest Contentful Paint und sollte (näherungsweise) die Zeit bis zur Darstellung des ersten relevanten Inhaltselements ermitteln, häufig auch Hero Element genannt. Meistens sind das Elemente mit CTAs (Call To Action), wie ein „30 Tage kostenlos testen“. Eine automatisierte Ermittlung davon stellte sich aber als schwer bis unmöglich heraus, der mittlerweile auf den LCP angewendet wird − welcher bei modernen Webseiten oft auch der FMP wäre.

Bei der Time to Interactive handelt es sich um die Zeit die vergeht, bis der Browser nichts Weltbewegendes mehr macht − also keine große Rechenlast mehr da ist und fast keine Daten mehr nachgeladen werden. Im Grund ist zu diesem Zeitpunkt die vollständige Interaktivität der Seite hergestellt. Konkret: In einem Zeitfenster von fünf Sekunden gibt es keine Long Tasks mehr, es werden maximal 2 GET-Requests ausgeführt und der First Contentful Paint (FCP) ist schon da. Grundsätzlich kann es einem Benutzer auch schon vorher gelingen, Eingaben zu machen (siehe FID), die auch ausgeführt werden (daher gibt es noch die Total Blocking Time).

Die Total Blocking Time (TBT) gibt alle addierten Zeitfenster zwischen dem FCP und der TTI an, in denen der Browser nicht auf Benutzereingaben reagieren konnte, weil gerade ein Long Task lief − also eine Blockierung des Main Threads für mehr als 50 ms bestand. 

Um die Time to first Byte geht es für uns als Hoster sehr oft. Denn die TTFB beschreibt die Zeit, die zwischen der Anfrage des Browsers für ein Dokument und dem ersten empfangenden Byte an Daten im Browser vergeht. Realitätsnäher ausgedrückt: Wie viel Zeit vergeht, wenn ich im Browser eine Adresse eingebe und auf Enter drücke, bis mein Browser vom Server die ersten Daten erhält. 

 Dazwischen liegen einige Dinge, die ggf. passieren müssen:
 

1. DNS-Auflösung
2. Aushandlung einer verschlüsselten Verbindung (HTTPS bzw. SSL / TLS)
3. Übertragung der Anfrage
4. Verarbeitung der Anfrage auf der Serverseite (PHP, MySQL, etc.)
5. Senden des Ergebnisses an den Browser
    

Auf diese Schritte (die − zugegeben − auch schon vereinfacht sind), zahlen jeweils verschiedenste Punkte ein. Beispielsweise die Netzwerkverbindung (Latenz, Bandbreite usw.), bestehende Caches (Browser, DNS, serverseitig / im eingesetzten CMS / Shopsystem), Art der Verschlüsselung usw.

Neben all den Maßnahmen, die wir bereits ergreifen, hängt natürlich auch viel vom eingesetzten CMS oder Shopsystem und der Konfiguration ab, beispielsweise die Nutzung der eingebauten Caches oder eines Caching-Plugins, um unnötige Rechenzeit zu vermeiden. Nicht zuletzt wird auch der schnellste Server keine TTFB von unter 100 ms erreichen, wenn in PHP ein sleep(1); eingebaut ist.  

Bei einem FOUC (Flash of Unstyled Content) und FOUT (Flash of Unstyled Text) handelt es sich nicht um Messmetriken zur Performance, sondern eher zur User-Experience (wie es auch beim CLS der Fall ist). Wird zum Beispiel eine CSS-Anweisung zu spät geladen, werden Elemente eventuell kurz nicht richtig positioniert oder dargestellt (= Flash of Unstyled Content). Dadurch kann es natürlich auch zu einem Layout-Shift kommen. Werden Fonts zu spät geladen kann es passieren, dass sich die Schriftart auf der Seite plötzlich noch ändert, obwohl eigentlich schon „alles angezeigt wird“ (= Flash of Unstyled Text). Performance-Tools wie Lighthouse weisen solche Probleme daher in der Regel auch aus. Ich führe diese Metriken auf, weil man bei der Optimierung einer Website auch immer im Blick behalten sollte, dass man nicht kompromisslos auf Performance optimiert und dabei die User-Experience gänzlich aus den Augen verliert.

Erfahre im nächsten Teil der Serie, wie du z. B. mit Lighthouse und Pagespeed Insights noch mehr für die Performance deiner Projekte tun kannst.

Und wenn du noch auf der Suche nach superschnellem Hosting bist, klick doch hier mal rein.