Scripte komprimieren
Immer häufiger nutzen Websites die durch diverse Frameworks angebotenen Möglichkeiten zur Realisierung interaktiver Browseranwendungen. Mit steigenden Ansprüchen der Seitenbenutzer in Bezug auf die Usability einer Website erreicht auch der durch Scripte benötigte Speicherplatz immer größere Ausmaße – mit negativen Auswirkungen auf die Website-Performance.
Auch Client-seitige Scripte, wie beispielsweise JavaScript-Code, müssen vor deren Ausführung ersteinmal an den Browser des Seitenbesuchers geschickt werden. Mit der zunehmenden Komplexität von Web-Anwendungen – die seit Einführung der im heutigen Web 2.0 üblichen interaktiven Browseranwendungen immer häufiger zum Einsatz kommen – wächst zugleich auch der Umfang solcher Scripte. Die Folge ist, dass die benötigten Script-Dateien immer mehr Speicherplatz belegen und die an den Besucher zu übertragenden Datenvolumen ansteigen.
Da aber die allseits genutzten Frameworks zum Teil bereits die 100 Kilobyte-Grenze geknackt haben, wartet der Internetnutzer immer länger auf die vollständige Auslieferung des Codes. Erst wenn alle auf einer Internetseite verwendeten Scripte beim Browser angekommen sind, ist die Verwendung der interaktiven Fähigkeiten möglich. Mit Blick auf die Seitenusability wird es also immer wichtiger, dass die Übertragung von Scripten schnellstmöglich abgeschlossen ist. Wie bereits unter JavaScript einbetten beschrieben, sollte zur Gewährleistung einer effektiven Auslieferung darauf geachtet werden, dass die benötigten Scriptkomponenten zusammengefasst – und eventuell sogar in die Internetseite integriert – werden. Hierdurch lassen sich zeitaufwändige HTTP-Anfragen reduzieren, was zu einer geringeren Latenzzeit führt – die Webanwendung ist entsprechend schneller nutzbar.
Bevor der Code auf dem Produktivsystem landet, sollten alle in den Scripten enthaltenen Kommentare entfernt werden. So sinnvoll sie auch bei der Entwicklung von Webanwendungen sein mögen, so überflüssig sind sie auf einem öffentlich zugänglichen System. Schliesslich werden diese nicht zur Ausführung benötigt und vergrößern nur das zu versendende Datenvolumen. Der Aufwand einer Filterung von Kommentaren sollte in jedem Fall in Kauf genommen werden. Hingegen sollte von einer Filterung überflüssiger Leerzeichen aus dem Code abgesehen werden, da die Datei bei einer nachfolgenden Komprimierung kaum kleiner ausfällt.
Neben diesen grundlegenden Maßnahmen, sollte der Script-Code nach Möglichkeit in Form einer statischen Datei auf dem Produktivsystem landen. Dabei sollten eventuell auf einer Seite genutzte Cookies auf der zur Auslieferung statischer Inhalte genutzten (Sub-)Domain keine Gültigkeit besitzen, da diese die zu versendenden Header-Informationen unnötig vergrößern.
Sind keine dynamischen Komponenten in den Scripten enthalten, so sollten Script-Dateien in zwei unterschiedlichen Dateiversionen – die dennoch den selben Inhalt haben – auf dem Webserver landen. Da ist zum Einen eine unkomprimierte Datei und zum Anderen eine mittels GZIP vorkomprimierte Fassung. Auch wenn es hier zu einer doppelten Speicherung kommt: Aufgrund der Tatsache, dass nicht unbedingt jeder Client gepackte Dateien verarbeitet, ist eine unkomprimierte Dateifassung unumgänglich. Der Vorteil einer solchen Lösung ist der, dass der Webserver sich nicht bei jedem einzelnen Dateiabruf mit der Komprimierung des Scripts herumschlagen muss und sich mit seinen Resourcen statt dessen anderen Anfragen widmen kann.
Bleibt die Frage, wie der Webserver entscheidet, ob er nun die komprimierte oder die unkomprimierte Dateiversion an den Webbrowser des Besuchers ausliefern soll. Zur Beantwortung dieser Frage lohnt ein Blick auf den bei jeder HTTP-Anfrage vom Browser abgesetzten HTTP-Request-Header. Hier gibt die Browseranwendung dem Webserver zu verstehen, ob dieser GZIP-komprimierte Inhalte verarbeiten kann oder nicht. Auf Basis dieser Information entscheidet der Webserver, welche der beiden Dateivarianten an den Browser des Seitenbesuchers geschickt wird. Gesteuert werden kann das mittels der Webserverkonfiguration oder aber mit bestimmten Angaben in einer im Root-Verzeichnis des Webservers abgelegten .htaccess-Datei.