Website-Tuning Stage 3: Eine Zusammenfassung

Wie in dem ersten und zweiten Teil der Blogreihe erläutert, kommt es auf optimale, komprimierte und nötige Inhalte an. Viele Ressourcen werden daher nun asynchron geladen, sind komprimiert und zu größeren Teilen minifiziert. Um nun die letzten Prozente herauszukitzeln, haben wir Folgendes getan:

HTML minifizieren
CSS minifizieren
Bilder optimieren
SVG komprimieren
Google Maps entfernen
Webfonts und andere Bibliotheken selber hosten

HTML-Komprimieren und optimieren

Um das HTML zu minifizieren, werden im weitesten Sinne Whitespaces entfernt. Also Zeichen, die während der Entwicklung für die Struktur nötig sind bzw. ungemein helfen. Dem Browser ist es hinterher jedoch weitestgehend egal, wie viele Zeilenumbrüche im Quelltext sind oder wie strukturiert der Quelltext durch die IDE der Wahl eingerückt wurde (durch Tabstops oder mehrere Leerzeichen). Aufgrund dessen werden diese Whitespaces mithilfe eines kleinen Snippets im MODX vor der Ausgabe entfernt:

Des Weiteren wird bei uns zumeist der Quelltext mittels Kommentaren beschrieben, um diesen zu späteren Zeitpunkten auch noch gut verstehen zu können (Dokumentation). Diese Dokumentation ist für den live-Betrieb der Seite nicht erforderlich und wurde ebenso aus dem Quelltext entfernt.

So konnten noch einmal 6 von 19 KB und somit 31% gespart werden.

Weitere Ressurcen optimieren

Das Logo wird als SVG-Grafik eingebunden. Diese ist im weitesten Sinne eine XML-Datei, welche ebenso minifizierbar und komprimierbar ist. Somit wurden die Daten mit dem MIME-Typ „svg+xml/text“ zur nginx-Konfiguration hinzugefügt und die Datei minifiziert.

Google Maps wurde aus der Startseite entfernt. Grund hierfür sind die ca. 45 Requests des Browsers, bis die Seite tatsächlich geladen ist. Das führt dazu, dass einige wichtige Ressourcen parallel mit der Karte geladen werden und sich die Bandbreite teilen müssen und daher langsamer geladen werden. Die Karte braucht durchschnittlich 3-5 Sekunden bei einer guten Internetverbindung, bis keine weiteren Ressourcen mehr nachgeladen werden. Subjektiv betrachtet reagiert in der Zeit der Browser marginal träger, was vermutlich mit der Leistungsfähigkeit des Endgerätes einhergeht. Aufgrund des späten Ladens des CSS gibt es zudem noch ein Darstellungsproblem beim erstmaligen Laden der Seite mit Browsern mit der Webkit-Engine (nur eine halbe Karte wird angezeigt). Netter Nebeneffekt: Die Datenkrake Google bleibt den Besuchern zunächst erspart.

Bilder optimieren

Auf der Startseite von Coding-Pioneers wird ein größeres Bild (Keyvisual) genutzt. Dieses war in der ursprünglichen Größe knapp 1,6 MB groß. In einer kleineren Größe (Breite: 1900 Pixel) hatte es noch 450 KB und macht damit noch rund 50% der Seitengröße (Gesamt: 695 KB) aus. Der Webdienst compressor.io verspricht, Bilder um bis zu 90% zu verkleinern und das ohne Qualitätsverluste. Zu verlieren gab es also nicht viel, wenngleich 90% Verkleinerung nicht erwartet wurden. So konnten am Ende annähernd 100 KB gespart werden (446 KB reduziert auf 345 KB also eine Ersparnis von rund 23%), was also zu einer Gesamtersparnis von etwas über 10% führte.

Was wurde denn nun gespart?

Angefangen haben wir mit einem Prototypen, der in Summe 2,2 MB also grob 2200 KB groß war. Es wurden 70 Ressourcen geladen (zum größeren Teil asynchron durch Google Maps) und das Ereignis „ready“ des DOM wurde nach durchschnittlich 1650 ms ausgelöst.

Durch die Komprimierung müssen von den 930 KB nur 695 KB übertragen werden, das entspricht einer Einsparung von 25%.

Durch das Minifizieren von:

HTML: 19 auf 13 KB (31% Ersparnis), keine Ressourceneinsparung
CSS: 196 auf 88 KB (55% Ersparnis), durch das Zusammenfassen wurden zwei Dateien eingespart, die weniger geladen werden müssen. Hier konnte auch relativ viel eingespart werden, da die Bibliothek des Bootstrap vom Umfang reduziert werden konnte.
JavaScript: 100 KB auf 140 KB, da noch weitere Skripte gebraucht wurden, um andere Möglichkeiten zu eröffnen, dafür wurden zwei Requests gespart. Die Minifizierungsrate fällt hier leider nicht so hoch aus, da die eingebundenen Bibliotheken wie jQuery bereits maximal minifiziert sind.
Bilderkomprimierung: Mithilfe von compressor.io konnten 140 KB gespart werden also einer Gesamtersparnis von etwas über 15%.

In Summe haben wir so von den ursprünglichen 2100 KB gute 1400 KB in der Übertragung sparen können. Durch die Optimierung werden nicht mehr 68 Ressourcen geladen, sondern nur noch 20. Das DOM-Ereignis „Content Loaded“ wird nach 240-400ms vom Browser ausgelöst. Ab dem Moment werden die Daten beim Client gerendert und dargestellt. Darauf folgt dann das Ereignis „Ready“ nach durchschnittlich 1,5 Sekunden. Nun werden Funktionen aufgerufen, wie die jQuery-Funktion „ready“ und damit die letzten Operationen ausgeführt.

Fazit: Performance matters

Was sollten Sie also tun, damit die Seite so schnell wie möglich geladen wird? Hier eine kommentierte Liste zum Abarbeiten:

Serverperformance: Suchen Sie sich einen guten Hoster und Webspace mit SSDs, so können Webseiten spürbar schneller bereitgestellt werden. Ein Webspace-Paket für 0,49 Euro / Monat und 2000 anderen Webseiten auf dem gleichen Server helfen nur bedingt. Gerade als Unternehmen spart man hier an der falschen Stelle!
Optimieren Sie Ihre Bilder: Hier steckt mit das meiste Potenzial, um die Seitengröße schnell auf ein sinnvolles Maß zu bringen (Nur weil heutzutage jedes Smartphone kaum mehr Bilder von unter 4 MB erzeugt, müssen diese nicht direkt so auf die Webseite)
Reduzieren Sie vor der Ausgabe Ihren CSS-Code: Zeilenumbrüche und Einrückungen strukturieren den Code zwar für Sie optimal und Kommentare noch einmal ungemein, aber dem Client (Browser) ist das zumeist vollkommen egal.
Gleiches gilt für Ihren HTML-Code: So lassen sich schnell mal ein paar KB sparen.
Für JavaScript gilt grundsätzlich das gleiche: Hier sind Optimierungen jedoch nicht ganz so trivial.
Schalten Sie die Komprimierung (gzip/mod_deflate) ein: Ihre Webseite wird ca. 30% schneller geladen!
Reduzieren Sie die Anzahl der Dateien bzw. fassen Sie Dateien zusammen, die geladen werden: Jede Datei, die gespart wird, spart einen HTTP-Header und blockiert damit keine anderen Ressourcen. Besonders CSS- und JavaScript-Dateien lassen sich gut zusammenfassen. Auch Bilder lassen sich in sog. Sprites zusammenfassen.
Vermeiden Sie verschiedene Dateiquellen und laden Sie möglichst alles von einem Host. Auch wenn man Webfonts vom Anbieter A, jQuery vom CDN B und andere Bibliotheken von Anbieter C einbindet, sorgt das dafür, dass im Worst-Case drei DNS-Anfragen vor dem vermeidlich schnelleren Laden getätigt werden. Das blockiert den Browser kurzfristig und erhöht zudem die Anzahl der Fehlerquellen.

Wofür das Ganze? Sind wir schon fertig?

Die Seite wird nun insgesamt spürbar schneller geladen, was vor allem den mobilen Nutzern zugute kommt. Google hat hier für die Analyse das Produkt „PageSpeed Insights“ bereitgestellt. Hier räumen wir mit der aktuellen Seite 100 von 100 möglichen Punkten im Desktop-Bereich ab ⇒ PageSpeed Insights von coding-pioneers.com

An einigen Ecken hakt es noch und an anderen Ecken liegt noch einiges an Potential. Hier wird es azyklisch immer mal wieder kleine Ergänzungen geben und wir werden diese mit Code-Snippets für Sie zur Verfügung stellen! Sie haben Fragen, Anmerkungen oder Wünsche – Wir freuen uns über Kommentare!