Percieved Rendertime oder gefühlte Ladezeit

Percieved Rendertime oder gefühlte Ladezeit

Über die Optimierung von Ladezeiten existiert schon viel Information in Englischer Sprache. Methoden gibt es viele, z. B. die Minimierung von Objekten (Anzahl, Größe), Verwendung von Kompression bei Skripten, optimierter Nutzung des Browsercaches, Verwendung von HTTP1.1 und vieles mehr. Viele Entwickler, Designer und Developer nutzen heutzutage Tools wie YSlow, Firebug oder HTTPWatch, um die Ladezeiten während der Entwicklung zu kontrollieren oder mal in der Liveumgebung zu testen.
Das ist alles schön und gut, weil es dazu beiträgt, dass die Webseiten schnell geladen werden. Eines jedoch können diese Tools nicht abbilden. Einen – wenn nicht den wichtigsten – Faktor berücksichtigen diese Applikationen nicht.

Die „percieved Rendertime“ – die gefühlte Ladezeit. Es handelt sich dabei um die Zeit, die es braucht, um das Browserfenster zu füllen und dem User das Gefühl zu geben, er könne nun mit seinem Vorhaben (dem Grund seines Webseitenbesuches) beginnen.

Was es damit auf sich hat ist nicht so schnell und einfach erklärt. Ich will es aber dennoch anhand von Beispielen erklären. Herhalten als schlechte Beispiele müssen die Denic.de und die Deutsche-Bank.de.

Bevor ich aber mit den schlechten Beispielen anfange, möchte ich ein relativ einfaches Beispiel zeigen, welches die percieved Rendertime verdeutlicht. Spiegel online wird vermutlich jeder der Leser kennen. Die Webseite ist so optimiert, dass der Besucher recht schnell das Gefühl bekommt „fertig geladen“ bekommt, obwohl die Webseite mit all ihren „3rd Party“ Inhalten bei weitem noch nicht fertig geladen ist.

In dem kleinen Screenshot markiert die grüne Fläche den Teil, der sehr schnell nach dem Aufruf erscheint und einen Standard Laptop screen (800 Pixel Höhe) . Der Rest (incl. Banner) wird erst später geladen.

spiegel_2

Recht undeutlich auf dem Bild aber erkennbar der „Börsen“ und „Wetter“ Bereich.

Im Gegensatz zum Spiegel arbeitet die Deutsche Bank nicht „pro gefühlte Ladezeit“. Ein Screenshot nach 3 Sekunden Ladezeit (und ich habe eine schnelle Anbindung) zeigt deutlich das Defizit:

db1_ff3s

Wo ist der Haupt-Eye-catcher?

Schön zu sehen – alle anderen Grafiken sind bereits geladen. In diesem Fall handelt es sich bei dem Eye-Catcher um eine relativ große Flash Datei. Verständlich, dass diese noch laden muss. Zwei Optionen gäbe es, um mir das Gefühl zu geben die Seite ist schon fertig geladen:

a) eine Grafik (Standbild) anbieten, welche durch das Flash ersetzt wird
b) eine Fortschrittanzeige einblenden – um mir zu zeigen, dass noch irgendwas passiert.

Zur Erinnerung: 40% aller Deutschen kriechen noch langsam durch das Internet. Und der ein oder andere Deutsche Bank Kunde wohnt sicher auf dem Land (ich kenne einen auf Norderney).

Gehe ich zur Analyse tiefer in die Daten und schaue mir die Ladereihenfolge an, wird schnell klar: Auch dort gibt es Optimierungsmöglichkeiten (anklicken zum Vergrößern):

db_waterfall1

kugel_blau.swf ist das zuletzt geladene Objekt

Mit 1,5 Mb zudem sehr mächtig dimensioniert – d. h. ohne Alternativgrafik wird ein User mit geringer Bandbreite sehr lange den großen leeren Bereich sehen. (Lange warten würde auch ein Businessmensch im ICE von Köln nach Frankfurth mit UMTS Verbindung).

Als Regel könnte man hier aufstellen: Die wichtigen visuellen Objekte im DOM tree so Platzieren, dass sie frühzeitig geladen werden.

Ein zweites Beispiel für Percieved Rendertime habe ich auf der neuen Denic Seite gefunden. Zufällig. Ich öffnete meine Browser – es wurde meine Standardseite geladen (about:blank) und ich gab in die Adresszeile www.denic.de ein. Dann passierte aber erst mal gar nichts – ich sah nur in der Statusleiste dass sich etwas tut. Das warten ging so 5-6 Sekunden bis dann „schwupp“ alles da war. Hätte ich eine andere Seite offen gehabt, hätte ich die alte Seite noch gesehen.

Steve Souders nennt dieses Phänomen „white screen“. Verursacht wird es durch Javascripte, die im <head> Bereich der Webseite eingebunden wurden und nur sequenziell vom Browser geladen werden. Eins nach dem anderen. Sind diese Javascripte nun sehr groß, oder benötigen eine große Renderzeit, dauert es bis die Webseite weiter geladen wird.

de

Beispiel: Denic.de - gemessen mit einem DSL Durchsatz von 3.400 mbit/s

Die Grafik zeigt schön, wie sehr das jquery Javascript ein Weiterladen der Seite blockiert. Denic macht meines Erachtens gleich mehrere Fehler – und verlangsamt dadurch die Ladezeit der Webseite dramatisch:
1.) Jquery auf der Startseite ! (wird es dort überhaupt benötigt ?? Ich konnte keine Funktion erkennen) – Sollte es nicht besser auf der Seite erst geladen werden wo es benötigt wird ? So lädt jeder (JEDER) Besucher von Denic die kompletten 102 Kb herunter, ohne dass er sie möglicherweise benötig. Außer dass Ressourcen verschwendet werden, wird auch noch der Server unnötig belastet, die Bandbreite belastet und der Besucher belastet.

2.) Unkomprimierte Auslieferung der Scripte (CSS, Javascript) – die Webseite von Denic ist insgesamt ca. 270 kb schwer. Allein ca. 180 kb sind Javascript und CSS Dateien. Der Rest sind eh schon komprimierte  Binärdaten (Bilder). Durch die Verwendung von gzip oder mod_deflate könnten ca. 80% der Datenmenge eingespart werden,  d. h. Ressourcen werden verschwendet, der Server unnötig belastet (Socketbelegung), die Bandbreite belastet und am wichtigesten der Besucher belastet.
3.) Javascripte werden in Header eingebunden. Dadurch entsteht der „white screen“ Effekt. Da kein „onload“ oder „domready“ Event gesetzt ist, können die Javascripte auch als letztes referenziert werden (wenn Sie denn wirklich unbedingt benötigt werden). Dann scheint Webseite fertig geladen und der User kann sein wunderbares Browseerlebnis beginnen.

Es macht also durchaus Sinn, sich Gedanken zu machen, wie etwas wo eingebunden wird. Das kann neben einem glücklichen Webseitenbenutzer auch noch Strom sparen, die Server generell entlasten und …..gute Rankings in den Suchmaschinen geben…..(kleiner Scherz)

2 thoughts on “Percieved Rendertime oder gefühlte Ladezeit

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.