Mal eine kleine Case-Study zu Performance-Optimierung anhand unserer Webseite für das Frankfurter Open Decvice Lab.

odlsnap

Da wir die Webseite, bis auf das Blog, als One-Pager angelegt haben, also alle Inhalte gleich auf der ersten Seite erreichbar sind, war uns durchaus bewusst, dass die Seite etwas mehr Daten senden wird, als man erwarten würde. Von unterwegs im langsamen Netz war die Performance der Seite allerdings so grottig, dass wir gestern mal unter die Haube geschaut haben, was da los ist.

Zu unserem grossen Erstaunen stellten wir fest, dass die Seite stolze 2.2mb Daten auf 97 Requests aufgeteilt übermittelt, was angesichts dessen, dass da fast nur Textinhalte drauf sind, ziemlicher Overkill ist.

Für die ungewöhnlich hohe mb Zahl war schnell der Grund gefunden: Eines der Sponsoren-Logos war trotz geringer Pixeldimension 599kb groß, offenbar, weil es im CMYK Farbraum gespeichert wurde. Dieses jpg konnte ohne sichtbaren Qualitätsverlust auf 21kb reduziert werden - 96% Einsparung!

Weil das so gut geklappt hat, haben wir uns die anderen Bild/Logo Daten auch vorgenommen: Und siehe da -- auch hier konnte im Schnitt 37% Dateigröße eingespart werden, im Einzelfall sogar bis zu 94%. Hossa. (Für das Auspressen der Bilder kann ich übrigens imageoptim sehr empfehlen, falls Ihr am Mac arbeitet).

Erste Lektion: Bevor man über Minimierung und Komprimierung von Code nachdenkt, sollte man sich die Bilddateien sehr gut anschauen, da steckt das größte Potential zur Einsparung von Dateigröße.

Verantwortlich für die vielen Requests war jedoch die Art, wie wir google Maps auf der Seite eingebunden haben: Eine inline-Map mit Zoomfunktion und allem ist ja schön und gut, aber brauchen unsere Besucher das wirklich?
Ein Bild der Map mit dahinterliegendem Link auf die die Webseite von googlemaps tut es genauso -- und schon haben wir nur noch 30 Requests und sind nicht mehr darauf angewiesen, dass die externen Scripte und Daten von google schnell ausgeliefert werden.

Auffällig im langsamen Netz war, dass die Seite sehr lange gebraucht hat, bis überhaupt mal etwas zu sehen war. Das spricht in der Regel dafür, dass ein (noch) nicht geladenes Javascript das Rendering der Seite pausiert. Aus diesem Grund packt man mittlerweile alle Javascripte so weit es geht ans Ende der Webseite und nicht an den Anfang. In unserem Falle ist jedoch ein Script im Header stehen geblieben: Das Javascript für den Typekit-Service, der ein paar schöne Webfonts zur Verfügung stellt.
Der Preis dafür: 140kb und 4 Requests.
Auch hier mussten wir uns die Frage stellen, ist es das wert? Macht die Verwendung von Webfonts die Seite irgendwie besser für unsere Besucher? -- Nein.
Vor allem nicht, wenn diese erstmal warten müssen, bevor überhaupt etwas auf der Seite erscheint.
Also haben wir die Webfonts und Typekit rausgeschmissen und stattdessen die Typographie mit Standardfonts, die auf den allermeisten Systemen vorhanden sind und nicht erst (nach)geladen werden müssen, aufgebaut.

Dann haben wir unsere Haupt-CSS Datei angesehen, diese hat trotz Minimierung stolze 197kb! O_o
Da wir das Foundation Framework mit Sass Preprozessor nutzen, war auch hier der Grund schnell gefunden: Im Default-Zustand werden sämtliche Funktionen und Module des Frameworks in das resultierende CSS gepackt, was dieses natürlich ziemlich aufbläst. Sobald man die Seite also fertig hat, sollte man hier noch mal ran und nur die Dinge inkludieren (lassen), die man auch wirklich benötigt, was wir erstmal aus Zeit- (und Bequemlichkeits-) Gründen unterlassen haben.

Mit dieser Handvoll Maßnahmen, die eigentlich echte No-Brainer sind, haben wir die Webseite von 2.2mb auf knapp 680kb und die Requests von 97 auf 29 verringern können.

Das ist eine Reduktion von ~70% bei der Dateigröße und ~70% bei den Requests.

Das Ladeverhalten hat sich spürbar verbessert, vor allem das Entfernen der Typekit-Scripte aus dem Seiten-Head hat es deutlich beschleunigt (siehe Update am Ende des Texts).

Interessant finde ich, dass neben einem echten handwerklichen Fehler (das CMYK JPG) die meisten anderen Punkte konzeptionell hinterfragt werden müssen:

Braucht man externe Services für zb Webfonts? In wie fern nützt das dem Benutzer der Seite?
Sind Widgets wie der googlemap iframe ein wirklicher Mehrwert für den Besucher?

Ebenfalls interessant, dass die Bequmelichkeit, Flexibilität und die Geschwindigkeit, die man als Webseiten-Autor zb bei der Verwendung von CSS-Frameworks bekommt, unmittelbar zu Lasten der Benutzererfahrung geht, wenn man nicht noch Zeit auf Feintuning und tweaken der Frameworks verwendet. Das gilt natürlich auch oder sogar noch stärker, wenn man JS-Bibliotheken wie jQuery einfach mal einbindet, weil man die ja bestimmt immer mal irgendwo gebrauchen kann…

Ich finde das sehr interessant, weil genau diese Punkte, die letztlich das Endergebnis, also was kommt wie wann beim Benutzer an, sehr stark prägen, meiner Erfahrung nach nur sehr selten berücksichtigt werden, wenn ein Webseiten-Auftrag vergeben wird, und sie aus Zeit- und Budgetgründen eher kontraproduktiv erscheinen.

Update:
Die recht binäre Rangehensweise ist natürlich auch nur die halbe Wahrheit. Statt zb Typekit oder googlemaps komplett rauszuschmeissen, kann man auch versuchen, das Laden so zu gestalten, dass es eben nicht den Seitenaufbau unterbricht. Im Quellcode von opendevicelab.com kann man sich das ganz gut ansehen (danke an Sven und Christian für die Hinweise).