Ember.js 1.1 im Einsatz

Seite 3: Performante Apps und Fazit

Inhaltsverzeichnis

Ember.js ist eine gute Möglichkeit, eine Webapplikation performant zu gestalten. Dabei sollte man allerdings nicht die guten alten Caching-Optionen des Webs außer Acht lassen. Kein Bit ist so schnell wie ein Bit, das überhaupt nicht ausgeliefert werden muss! Eine Webapplikation unterliegt dabei der gleichen Auslieferungslogik wie eine klassische Desktop-Applikation, die auch nicht jeden Tag vom Hersteller per Post neu an den Kunden auszuliefern und von ihm neu zu installieren ist.

Jeder moderne Webbrowser benutzt einen lokalen Cache, um Grafiken oder HTML-Seiten für den späteren Gebrauch wieder zu verwenden. Meistens wird der Browser dafür beim Webserver nachfragen, ob eine bestimmte Datei noch aktuell ist. Dabei kommen ETags zur Versionierung oder Zeitangaben für einen Zeitvergleich zum Einsatz. Wenn sich die Datei nicht verändert hat, gibt der Server den HTTP-Statuscode 304 (Not Modified) zurück. In dem Fall kann der Browser die Datei aus dem Cache benutzen. Gerade beim Gebrauch von Smartphones, die über 3G oder 4G surfen, ist der Geschwindigkeitsgewinn enorm.

Geht man vom Grundgedanken einer normalen Applikation aus, müsste der Browser den Stand der Dateien überhaupt nicht ständig beim Webserver nachfragen. Wer als Anbieter eine Version der Software nach intensivem Testen als stabil einstuft, kann die Datei per Konfiguration des Webservers mit einem Expires:- oder Cache-Control: max-age=-Header ausliefern. Dann muss der Browser beim erneuten Aufruf der Applikation (die für ihn nichts anderes als eine normale Webseite ist) keinen Kontakt zum Server aufnehmen. Er kann anhand des Zeitstempels im Header eigenständig überprüfen, ob eine Datei noch aktuell ist.

Es gibt keine für alle gültige Daumenregel für einen sinnvollen Expires:-Wert. Bei der Mehrzahl der Webapplikationen sind beispielsweise 24 Stunden unproblematisch, oft sind gar sieben Tage möglich. Der Gewinn dadurch liegt dann nicht nur beim Kunden, sondern auch beim Betreiber des Webservers, der weniger Server benötigt und dadurch Geld sparen kann. Ein optimales Caching endet allerdings nicht bei JavaScript und HTML-Dateien. Lädt die Ember.js-Applikation die Daten mit Ember-Data vom Server als JSON-Dateien, gilt dabei der gleiche Grundgedanke. Im schlimmsten Fall sollte man auf jeden Fall mit dem Statuscode 304 arbeiten, da sich der Traffic so stark reduzieren lässt.

Wer gerne mit opinionated Frameworks arbeitet und neu mit dem Thema Webapplikationen anfängt, ist bei Ember im Vergleich zu den anderen Frameworks am besten aufgehoben. Allein am Thema saubere URLs beißt man sich sonst schnell die Zähne aus. Mit Ember-Data gibt es zusätzlich eine Datenschnittstelle, die sich perfekt in das restliche Framework einbinden lässt.

Stefan Wintermeyer
ist auf Webperformance spezialisiert, Gründer und Geschäftsführer der AMOOMA GmbH und Autor des Ruby-on-Rails-Buchs http://ruby-auf-schienen.de.
(jul)