Vorwärts Männer, wir müssen zurück: Komprimieren oder Abbauen?
Mit der Kompression von Javascripten habe ich in letzter Zeit ein wenig Erfahrung gesammelt, aus gegebenem Anlass sozusagen. Dean Edwards sammelt hierzu nocheinmal die Fakten, und hat ein paar gute Tips parat. Es bleibt aber eine Krux: Komprimierung ist super, besser ist es jedoch, von Anfang an mit kleinerem Datenaufkommen arbeiten zu können (das kann man dann immer noch komprimieren). Mit dem Mißverständnis, seit »Web2.0« könne man mit ein wenig Javascript auf Webseiten so ziemlich alles veranstalten, haben zwei wesentlich Fehler Einzug in die Aufgabenstellung am Frontend genommen:
- Javascriptanwendungen als Beigabe zu sowieso schon großen Websites – geparrt mit dem Glauben, nur weil man etwas machen könne, sei es auch gut einfach und sinnvoll: hier noch ein Widget, da noch ein Gimmick, über den “Sinn” wird sich dabei kaum oder zuwenig Gedanken gemacht.
- Unterschätzung einiger wichtiger Faktoren in diesem Zusammenhang: wie schränkt die extensive Nutzung von Javascript die Liste der Zielbrowser ein beispielsweise, oder welchen Aufwand bedeutet ist, selbige Liste trotz JS groß zu halten; wie wirken die genannten Widgets innerhalb des Auftritts und wie werden sie angenommen.
Und so weiter, leider. Da für den Auftraggeber derlei Programmierung oft Voodoo ist, kann er keine Abschätzungen zu diesen Fragen vornehmen, für ihn ist alles immer ganz einfach. Am Ende ist die Seite dann aber zu groß. Ergo: man muss immer schon sehr frühzeitig zum Ausdruck bringen, welche Folgen der massive Einsatz von Javascripten hat und den Aufwand-Nutzen-Faktor stets in Frage stellen. Denn: wenn’s am Ende nicht klappt sind selten die Auftraggeber die Schuldigen…
Hat man den vorzeitigen Einfluss versäumt, vergeigt oder einfach nicht gehabt, kann man immer noch darauf zählen, dass die Zeit die Wunden heilt. Mit anderen Worten: man bietet zur Behebung von Problemen wie bspw. übermäßiger Seitengröße an, die kleinen Javascriptspielereien wieder zurückzubauen. Letztendlich sind es ja nur Spielereien, und eh’ der Auftraggeber seine eigenen inhaltlichen Anteile in Frage stellt, wird er freudig zustimmen. Natürlich muss man ein wenig aufpassen, dass nicht andere mit den Rückbaumaßnahmen beauftragt werden.
6 Kommentare
René
01.09.2007, 04:23 Uhr
Das Problem bei einer immer grösser werdenden Anzahl von Web 2.0 Seiten, die mit Javascripten oft überladen sind, ist, das entweder der Seitenaufbau übermäßig lang dauert oder wie in meinem Fall der IE eine Fehlermeldung ausspuckt und den Browser schliesst.
Wenn man nun noch anfängt zu komprimieren, dürfte der IE noch mehr Probleme bekommen.
Nico Brünjes
02.09.2007, 13:36 Uhr
Hmm, mit einer gzip-Komprimierung und auch mit den Hash-Tools die Dean Edwards vorschlägt hat IE (wie meine Erfahrung zeigt) wenig Schwierigkeiten. Unter IE7 sinkt die Ladezeit sogar erheblich.
Marc
10.09.2007, 01:53 Uhr
gzip Komprimierung ist mit Sicherheit nicht schlecht, aber vorher sollte man mal ausmisten, nicht jeder Javascript Code wird wirklich auf jeder Seite auch gebraucht…
Thomas
10.12.2007, 23:28 Uhr
Ich bin nach wie vor der Meinung, dass Javascript auf vielen Webseiten eingestzt wird wo es gar nicht nötig ist. Java Script kann u.U. mehr Probleme machen als es Nutzen bringt. Im Moment wird so oft das Web 2.0 ausgelobt, aber im Endeffekt sind es ganz einfach nur Webseiten. Man darf bei diesen ganzen “Spielereien” nie vergessen, dass nicht jeder die Scripte auf seinem Rechner aktiviert hat.
Ruben
12.01.2008, 06:42 Uhr
Hallo,
da muss ich Rene recht geben, die Heutige Web 2.0 fasse wird recht mi Javascripten zugebommt..
Simone
13.06.2008, 01:17 Uhr
Javascript ist in den meisten Fällen unnötig und wird meist nur für “Spielereien” eingesetzt die man nicht braucht. User die Javascript abgeschaltet haben klicken oft wieder weg. Das Web 2.0 ist nur ein “Modebegriff”. Dean ist in diesem Bereich wirklich sehr fit, aber man sollte die Problematik bei der Wurzel packen: Wenn es nicht anders geht ist die Verwendung von javascript OK, aber nur dann.