am 18. August 2010
Während es Blogs gibt, in denen kritische Kommentare nicht gerne gesehen sind, werden auf phphatesme sogar ganze Contra-Beiträge veröffentlicht, in diesem Fall zu dem Thema JavaScript-Komprimierung.
Die provokante Aussage war, sehr kurz gefasst: JavaScript-Komprimierung sei eine Lösung für ein Problem das man gar nicht hat.
Statt einer einfachen Gegenposition möchte ich – auch unter Zuhilfenahme der zahlreichen Kommentare – aufzeigen welche Gründe und Möglichkeiten es für eine Komprimierung gibt. Ein weites Feld und leider musste bereits während der Bearbeitung einiges aus Platzgründen wieder gestrichen werden.
Warum überhaupt Komprimierung?
Manche Webseiten liefern über 50 Grafiken oder Bilder, deren Gesamtvolumen problemlos den MegaByte-Bereich sprengen. Dazu noch ein gutes dutzend CSS-Dateien, ein paar IFrames und noch etwas Flash. Warum sollen da ausgerechnet ein paar kleine JavaScript-Dateien so problematisch sein?
Zum einen haben wir mit Web 2.0 und immer ausgefeilteren Oberflächeneffekten immer mehr und größere JavaScript-Dateien. Zum anderen ist das Ladeverhalten bei JavaScript-Dateien anders als beispielsweise bei Bildern, die erst nach dem Rendern der Seite parallel angefordert und geladen werden. Ich möchte hier auf einen Blogeintrag verweisen, der zwar ASP.NET behandelt, im ersten Teil aber das Ladeverhalten von JavaScript beispielhaft aufzeigt:
http://www.atashbahar.com/post/Combine-minify-compress-JavaScript-files-to-load-ASPNET-pages-faster.aspx
Nicht vergessen darf man, dass vor jedem “Seitenerlebnis” das geladene JavaScript noch interpretiert werden muss.
Die Komprimierung und Optimierung von JavaScript ist kein Luxus, sondern wird mit der stetigen Zunahme von Funktionalität und der Annäherung der Oberflächen an echte Applikationen noch mehr an Bedeutung gewinnen, damit die immer komplexeren Seiten trotzdem schnell angezeigt werden können.
Auch nicht vergessen darf man mobile Geräte die eben nicht mit DSL-Geschwindigkeit surfen. Grafiken können für eine schnellere Darstellung ausgeschaltet werden, viele Seiten sind ohne JavaScript aber nicht mehr funktional.
Manchmal ist der Platz, den man für sein JavaScript zur Verfügung hat auch aus ganz anderen, banalen Gründen begrenzt, wenn beispielsweise CMS-Systeme nur wenige hundert Bytes für ein Banner oder andere Seitenobjekte samt JavaScript erlauben und sprichwörtlich jedes Zeichen zählt.
Welche Anwendungsfelder gibt es?
“Butzi” hatte es in seinem Kommentar benannt: Obfuscating, Verkleinerung und serverseitig Kompression und Expire.
Obfuscating/ Verschleierung
JavaScript muss lokal vom Browser interpretiert werden. Deshalb ist es unsinnig zu glauben, man könne seinen Code so schützen, dass er irreversibel verschleiert werden kann. Sehr wohl aber kann man Hürden aufbauen in der Hoffnung, dass andere die den eigenen Code verwenden wollen oder aber Schwachstellen in der Seite suchen das Interesse verlieren und sich anderen Seiten zuwenden. Der Aspekt der Sicherheit sollte hier nicht unterschätzt werden.
- Änderung von Namen.
Namen lassen oft auf den Zweck von Code schließen. Werden Variablennamen verkürzt und verlieren damit ihre Bildhaftigkeit – ursprünglich nur um ein paar Bytes zu sparen – verschlechtert das die Lesbarkeit und die direkte Analysemöglichkeit durch andere.
- Rückschlüsse auf dahinterliegendes PHP über Ajax-Aufrufe können so zumindest erschwert werden.
- Etwas banaler, aber nicht ganz ohne Bedeutung: Entfernung aller Kommentare. Kommentare wie “Ready to rumble…” oder “DAU-Kontrolle” mögen ganz putzig sein, nach außen dringen sollten sie in keinem Fall.
Reduzierung der übertragenen Datenmengen
Damit ist sowohl eine Reduzierung der übertragenen Dateien, als auch deren eigentliche Größe gemeint. Beide Ziele können sich widersprechen, im Zweifelsfall sollte aber die Reduzierung der Anzahl der Requests im Vordergrund stehen.
- Entfernen aller unnötigen Whitespaces. Mit einer guten IDE – empfehlen möchte ich natürlich Netbeans – kann ein lesbarer Zustand mit einem Klick wiederhergestellt werden.
- Frameworks sollten nur in einer Version und als kleinere Produktionsversion verwendet werden.
- Zusammenführung von externen JavaScript-Dateien in wenige, größere Dateien um die Anzahl der Requests zu verringern.
- JavaScript darf nicht doppelt vorhanden sein, das mag banal klingen, kommt in der Realität öfters vor – sei es durch das Kopieren ganzer Bereiche oder innerhalb von HTML-Seiten.
Serverseitige Kompression und Expire
Philip hatte es in seinem Kommentar ausgeführt: Serverseitig kann über den Apache die Kompression von Inhalten wie JavaScript aktiviert werden um die zu übertragende Datenmenge zu verringern.
Nach der Entwicklungsphase ändern sich die JavaScript-Dateien selbst nicht mehr und über den Server kann das Expire für JavaScript- und auch CSS-Dateien hoch gesetzt werden.
Zusammen mit den bekannten Caching-Möglichkeiten können hier eine Menge Bytes und Rechenzeit für schlechtere Zeiten gespart werden:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html und http://httpd.apache.org/docs/2.0/mod/mod_expires.html
Tools und Werkzeuge
Alle Theorie ist grau, dafür sind hier ein paar Links zu wichtigen Werkzeugen und Tools aufgeführt. Auch der etwas genauere Blick auf die Ausführungen auf diesen Seiten kann sich lohnen.
Der YUI Compressor. Ein Java-Programm und eine interessante Webseite mit weiterführenden Informationen.
http://developer.yahoo.com/yui/compressor/
Auch diverse Online-Versionen gibt es im Web: http://refresh-sf.com/yui/ oder http://yui.2clics.net/
Der Closure Compiler von Google. Die Konkurrenz zum YUI-Kompressor, auch ein Java-Programm. Google bietet einen “Closure Inspector” als Firebug Plugin um den erzeugten Code debuggen zu können.
http://code.google.com/intl/de-DE/closure/compiler/
Eine Online-Versionen ist unter http://closure-compiler.appspot.com/home zu finden.
Der JavaScript CompressorRater, ein Vergleich gängiger Komprimierer, inklusive Online-Komprimierung durch die Tools JSMin, Dojo shrinksafe, Packer (Version 3.1) und dem YUI Compressor (Version 2.4.2).
http://compressorrater.thruhere.net/
Javascript Compressor. Online-Komprimierung optional mit Base64 Kodierung und dem Verkürzen von Variablennamen.
http://javascriptcompressor.com/
CodeTrimmer ver 2.0 Beta, Online-Komprimierung und Downloadmöglichkeit, geschrieben in JavaScript.
http://www.twinhelix.com/javascript/codetrim/
Der JavaScript Optimizer. Ein Tipp von Jan. Maven-kompatibel, für JavaScript und CSS.
http://js-optimizer.sourceforge.net/
Übersicht über Tools zur CSS-Komprimierung, eigentlich fast off-topic an dieser Stelle, soll aber dennoch nicht unerwähnt bleiben.
http://www.drweb.de/magazin/10-online-werkzeuge-zur-css-komprimierung/
Nicht vergessen: Optimierung beim Programmieren!
Trotz aller Werkzeuge und Tools darf ein Entwickler die Optimierung und Performance seines Codes niemals anderen überlassen. Wer seinen Code unnötig aufbläht oder langsamen Code schreibt hat seine Hausaufgaben nicht gemacht – diese Art der Optimierung ist aber wieder ein ganz anderes Thema.
