Die einzigst wahre Komprimierung

Auch wenn sich durch das verketten von Variablendefinitionen, das entfernen von Kommentaren und das einsparen von hübscher Formatierung die Dateigrösse bis zu 50% verringert, gibt es eine weitere Methode seine Skripte schneller unter das Volk zu bringen. GZIP hilft nicht nur bei HTML oder bei CSS. Gzip hilft auch bei Javascript und dank Apache sogar ohne sein Script in eine PHP-Datei packen zu müssen. Der wohlmöglich grösste Vorteil dieser Methode ist neben der Komprimierung auf nur 40% der Originaldateigrösse die Möglichkeit das Javascript zu cachen, was den weiteren Verlauf des Besuchs der Seite positiv beeinflusst.

Vorteile:

• Skripte wie z.b. die 50kb grosse prototype.js werden zu angenehmen 17kb häppchen
• Man kann Einfluss auf das Caching des Clients nehmen (Haltezeit, etc.)
• Folgeseiten laden schneller

Nachteile:

• Ältere Browser unterstützen Gzip nicht richtig, jedoch alle Browser der fünften Generation

Überlegungung vor der Implementierung:

• Ist mein Javascript dynamisch (generiert via php o.ä)?
• Benutze ich Skripte die Browser der 5ten Generation sowieso vorrausetzen?
• Ist Apache und PHP für diese Methode konfiguriert?

Erstellt eine PHP Datei mit dem namen "gzip-js.php". Fügt folgenden Code ein und ändert gegebenfalls das Caching oder was euch noch so in den Sinn kommt:

Dann legt diese Datei in den Ordner mit euren Javascripten. In dem gleichen Ordner erstellt eine ".htaccess" Datei mit folgendem Inhalt:

Diese Methode funktioniert nur wenn ihr PHP mit der ZLib kompiliert habt und auto_prepend erlaubt ist, bzw. Apache die Verwendung von .htaccess zulässt.

Code von John Cox (quelle)

Nicht alles aufeinmal..

Browser sind dumm - manche sogar dümmer. Also ziehen wir mal unsere Vorteile daraus. Javascript onload-events werden erst ausgeführt nachdem der DOM-Tree geladen ist und zusätzlich alle Bilder geladen wurden. Desweiteren sollte man berücksichtigen das Browser standardmässig nur 2 bis 4 HTTP Requests aufeinmal machen und jeweils gewartet wird bis diese fertig sind. Nun haben wir aber auf der anderen Seite unsere 10 Javascript-Dateien die wir dem Benutzer gerne liefern würden. Üblicherweise würde man diese nun alle im Head-Bereich mit dem Script-Tag der Reihe nach einfügen. Aber halt..

Diese Methode ist überflüssig und lahmt lediglich den Ladevorgang. Letzendlich verschwendet man zum Zeitpunkt an dem die Seite aufgerufen wird nur das limitierte Kontigent an HTTP Requests. Wie zuvor erwähnt führt der Browser die Skripte erst aus wenn der Rest der Seite beim Klienten vorliegt. Frei nach dem Prinzip "erst die Arbeit - dann das Vergnügen".

Um dieses Verhalten zu umseren Vorteil zu nutzen erstellen wir im folgendem ein Skript welches zuständig für das Laden weiterer Skripte ist. Das ganze wird erledigt mit einem Loop, einem Array und document.write(). Der Sinn ist es, dass man im Endeffekt nur noch ein kleines Script hat welches erst dann alle Bibliotheken runterlädt, wenn der Klient Javascript aktiviert hat (entlastung) UND wenn der Browser überhaupt in der Lage ist diese auszuführen. Zwei Fliegen mit einer Klappe :)

Und so sieht das ganze dann aus:

Erstellt eine Funktion welche mit document.write die Script-tags einfügt.

Wenn eure Seite geladen wird lädt der Browser erstmal das ganze HTML samt Bilder und DANACH führ er erst die 'loadScripts' Funktion aus, welche die eigentlichen Skripte runterlädt.

Vorteile:

• Man kann fast zu 100% sicher sein das der DOM komplett verfügbar ist. Für eventuell geplante Manipulation etc..
• Die Seite wird schneller geladen, weil man den Browser nicht mit noch nutzlosen Scriptdownloads beschäftigt
• Javascripte werden nur geladen wenn der Benutzer auch Javascript aktiviert hat. (Spart Traffic und Nerven)

Nachteile:

• Mir sind keine bekannt. window.onload geht meines Wissens nach in allen Browsern.

Überlegungung vor der Implementierung:

• Warum man das nicht schon immer so gemacht hat ;)

Die etwas andere Richtung

Zuvor haben wir ja das verzögter Ausführen für nützlich befunden. Es mag jedoch Fälle geben in dem das nicht erwünscht ist. Allerdings muss ich gleich dabei sagen das meine Erfahrungen mit dieser Methode positiv sowie negativ waren. Es kommt eben auf das Anwendungsgebiet an. Dean Edwards hat sich ein wenig mit dem "onload"-Problem auseinandergesetzt und einen Weg gefunden wie er das Ausfühen von Javascript NACH dem laden des DOM und VOR dem laden enthaltener Bilder möglich ist.

Gerade auf Seiten mit grossen Bildern kann es hier zu argen Problemen kommen, da der Benutzer wichtige Funktionen oder Navigationselemente erst verwenden wenn der Ladevorgang abgeschlossen ist. Das kann unbeachtet ein Besucher-Killer sein.

Testet es einfach mal selbst mit dem Code von seinem Blog. Falls ihr Prototype einsetzt, kann ich die FastInit Klasse empfehlen. Sie ermöglicht auch mehrere Funktionen die vor dem Laden der Bilder gebraucht werden aneinander zu ketten.

Vorteile:

• Man kommt schneller an den DOM.
• Man kann Berechnungen auf dem Client erledigen die er später braucht, aber ohne die Bilder noch nicht einsetzen kann.

Nachteile:

• Internet Explorer nur via externer Datei, Safari und Opara nur über Umwege (Q)

Überlegungung vor der Implementierung:

• Was wird als erstes gebraucht (dhtml menüs, etc.)?
• Welche Browser haben die Besucher (zielgruppe)
• Kommt mein Skript damit klar so schnell zu sein?