Artikel vom 11. Januar 2010

Webseiten-Performance: JavaScript-Dateien mit Google bündeln

Zip

Steigende Anzahl an Interaktionen innerhalb einer Webseite sorgt in der Regel für zusätzliche Stylesheets und JavaScript. Im unglücklichen Fall werden gar Frameworks aka “Schwergewichte” herangezogen. Dabei generiert extern ausgelagerter Code je nach Dateimenge weitere Server-Anfragen und verlangsamt den gesamten Ladevorgang. Google’s Werkzeuge reduzieren die Quantität auf ein Minimum – Resultat: Einziger Request bei beliebig vielen JS-Dateien.

JavaScript only
Dieser Artikel fokussiert sich ausschließlich auf die Performance-orientierte Einbindung der JavaScript-Komponenten. Eine gewinnbringende Integration von Stylesheets ins Projekt wird an dieser Stellen nicht behandelt.

Verlangsamte Ausführung durch JavaScript-Dateien
Je nach Komplexität und Funktionsvielfalt einer Website bindet der Entwickler Handvoll an externen JavaScript-Instanzen ins XHTML-Gerüst ein, um Funktionen zur Laufzeit verfügbar und ausführbar zu machen. Ein alltäglicher Prozess.

Zuviele Requests schaden dem Ladevorgang der Seite
So nicht: Zuviele Requests schaden dem Ladevorgang der Seite

Ein Szenario aus dem Alltag: Zwei JavaScript-Frameworks werden geladen, plus ein jQuery-Plugin für die Slideshow, SWFObject für die Flash-Einbindung, dazu kommt noch Google Analytics oder anderes Tracking-Tool auf JavaScript-Basis.

An sich nichts, was man nicht braucht. Wenn da nicht die schmerzende Tatsache wäre, dass jede dieser Module (Modul = Datei) den Browser dazu zwingt, sich mit dem Server zu verbinden, um Daten in Form von JavaScript-Zeilen zum Rechner des Nutzers zu transferieren. Das Gewicht der Files und die Anzahl der Bytes ist an dieser Stelle nicht wirklich kritisch (was sein muss, muss sein). Vielmehr ist die Menge der Anfragen als bedenklich zu betrachten, da Browser je nach Typ eingeschränkt parallele Requests bzw. Downloads ausführen können.

Einbettung einer Gesamtdatei mit JS-Code
Je mehr Dateien von der gleichen Domain in eine Seite eingebunden werden (unabhängig vom Typ), desto länger wird im Browser die Warteschlange zum Abarbeiten, um so langsamer ist die Ausgabe. Die Erkenntnis: Idealerweise steckt der komplette JS-Code in nur einer Datei, die einmalig im XHTML referenziert wird – der Browser stellt dafür nur die einzige Verbindung her und kann nebenbei andere Medien wie z.B. Bilder herunter laden. Bringt einen Performanceschub.

Viele der erfahrenen Entwickler praktizieren diese simple Technik: In der Entwicklungsumgebung aus Gründen der Übersichtlichkeit und der Bequemlichkeit an mehreren Dateien arbeiten. Live kommt lediglich die eine Datei zum Einsatz, die aus den separaten JS-Bibliotheken gewonnen und anschließend minimiert (z.B. mithilfe des JavaScript-Compressor) wurde.

Techniken für die Bündelung der JavaScript-Sourcen
Neben dem händischen Kopiervorgang der Zusammenführung von JS-Fragmenten existieren noch weitere Methoden für das Erzeugen einer zentralen JS-Datei. Eine der bewährten Möglichkeiten ist beispielsweise ein dynamisches Load-Script in PHP, welches Dateinamen als Parameter empfängt und entsprechende JS-Files in kombinierter Form an den Browser ausgibt.

Aber auch Google Labs stellt solch zweckmäßige, installationslose Online-Lösungen öffentlich zur Verfügung, welche weiter unten samt Vorteilen praxisbezogen vorgestellt werden.

1. Google Closure Compiler
Closure Compiler ist ein kostenloser Online-Service von Google mit alleiniger Aufgabe, JavaScript-Input komprimiert zu bündeln. Warum bündeln? Das Tool fasst nicht nur die händisch eingefügten JavaScript-Fragmente zusammen, auch gängige Frameworks (jQuery und Prototype zum Beispiel) und extern abgelegte Quellen lassen sich in der Anwendungsoberfläche auswählen bzw. abrufen und fließen so ins Endergebnis mit ein. Nach diesem Prinzip wären die notwendigen Frameworks und der eigene Code in nur einer Datei vereint.

Nach der erfolgreich abgeschlossenen Kompilierung der Rohdaten steht eine Zeichenwüste zum Kopieren und Download bereit.

Pro

Contra

Eigene JS-Inhalte und bekannte Libs mit Closure Compiler gruppieren
Eigene JS-Inhalte und bekannte Libs mit Closure Compiler gruppieren

2. AJAX API Loader
Seit neustem verfügt Google über einen neuartigen Dienst namens Autoloader, der mehrere APIs zusammenlegt und in komprimierter Datei zurückgibt. Der Autoloader unterstützt auch GET-Parameter und so werden die zum Laden notwendige Module als URL-Aufruf übergeben, Google fast den Code der APIs in einer Datei zusammen. Der praktische Wizard hilft bei der Bündelung der APIs und der Generierung der kryptischen Adresse.

Doch die Vielfalt der möglichen Module beschränkt sich nicht unbedingt auf Google APIs: Die oben bereits erwähnten Frameworks können auf die gleiche Weise via URL-Aufruf gruppiert geholt werden – als Ergänzung eine Übersicht der auf Google verfügbaren Frameworks: Google AJAX Libraries API. Dazu werden lediglich die Namen und Versionsnummer der gewünschten Module angepasst bzw. ergänzt und als Übergabeparameter definiert. Mehr ist an dieser Stelle nicht notwendig.

In folge dessen können schwergewichtige Bibliotheken (dabei bleibt die Anzahl der Files variabel) mit nur einem Request (welcher jedoch Gold wert ist) ins eigene Projekt inkludiert werden.

Pro

Contra

Google's Autoloader kann APIs, aber auch Frameworks verbinden
Google’s Autoloader kann APIs, aber auch Frameworks verbinden

Fazit
Aktuell berücksichtigt Google die Geschwindigkeit der Webseiten als einen nicht unerheblichen Ranking-Faktor, gibt den Entwicklern aber auch ausgereifte und kostenfreie Werkzeuge für diesen Zweck in die Hände. Die Zusammenführung der JavaScript-Dateien ist eine wichtige Schraube im mächtigen Motor der Performance-Optimierung und darf daher nicht “einrosten”.

Sergej Müller

[Der Autor] Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das weltberühmte und patentierte SEO-Plugin für WordPress-Blogs.

11 Kommentare zum Artikel

#1 Ben am 11. Januar 2010 um 09:48

Danke für diesen guten und sehr informartiven Artikel.

#2 Andreas am 11. Januar 2010 um 11:02

Vielen Dank für diesen hilfreichen Artikel. Ich kenn mich mit diesem Thema kaum aus und wusste bis Dato nicht, das sogar Google eine scheinbar passable Lösung anbietet. Definitiv ein Thema, womit ich mich intensiver auseinander setzen muss.

Gruß,
Andreas

#3 pehbehbeh am 12. Januar 2010 um 01:13

Sehr informativer Artikel.

Ich bin gespannt, in wie weit die Geschwindigkeit von Websites in Zukunft das Ranking beeinflussen wird.

#4 Sergej Müller am 17. Januar 2010 um 15:27

@all
Sehr gern. Macht mir wirklich Freude und Spaß Tutorials zu schreiben, die sonst nirgends zu lesen gibt. Keine Listen von Links zu fremden Beiträgen, sondern feine Eigenherstellung ;)

@pehbehbeh
Die Ausführungszeiten der Webseiten spielen in der nahen Zukunft eine zunehmende Rolle, da Suchmaschinen hochwertige Ergebnisse liefern wollen und der Speed ist einer der Kriterien solcher Seiten. Dabei geht Google doch ganz schlau vor und lässt nicht den eigenen Spider die Ladezeiten der Webseiten vermessen. Nein, vielmehr übernehmen Nutzer mit installierten Toolbars die Messung im Hintergrund. So kommt Google an die tatsächlichen Geschwindigkeit ran – in der Form und dem Umfang wie Nutzer die Seiten ebenfalls sehen würden: Mit all den JavaScript-Files, Stylesheets und hunderten an Grafikelementen.

Sergej Müller
#5 Veit Krahl am 19. Januar 2010 um 16:36

Ein Aspekt der modernen Webentwicklung der oft übersehen wird. Gutes Thema!

#6 Marco Spescha am 21. Januar 2010 um 00:50

Sehr interessant.
Ich persönlich setzte nicht gerne auf fremde Server, auch wenn es die von Google sind.
Da lad ich mir wie du es sehr gut geschrieben hast eine CFM-Applikation die mir das ganze zusammenstellt und anschliessend GZipped wieder bereitstellt.

Besonders Coldfusion hat da einen ziemliches Puff mit den eingebundenen JS-Files die automatisch hinzugefügt werden wenn ein Ajax-Dienst verwendet wird. Da können es schon bis zu 20 solch “falsch” eingebundene JS-Dateien sein. Leider lässt sich das auf dieser Ebene nicht umgehen.
Trotzdem danke für die wertvollen Informationen.
mfg

#7 Dieter am 23. Januar 2010 um 11:49

Hallo Sergej,

sehr interessanter Artikel. Danke!

Bisher kannte ich nur die Techniken händisch JavaScript-Dateien zu bündeln oder einen JavaScript-Compressor einzusetzen. Wieder etwas dazu gelernt.

Auch wenn die Google-Angebote interessant klingen, werde ich wohl bei meiner händischen Methode des Zusammenfassens und anschließendes Komprimieren mit gzip bleiben. Ungern möchte ich Code meiner Website von externen Servern geliefert bekommen. Dadurch, dass möglichst viel von meinem Webspace geladen wird, bin ich autarker und nicht so sehr auf die Funktionsfähigkeit externer Dienste angewiesen.

Komplexe externe Webdienste wie Google Maps, Gravatar und Akismet setze ich allerdings dann doch ein. Da überwiegen für mich die Vorteile (könnte ich nicht gleichwertig substituieren) gegenüber den Nachteilen (Abhängigkeit von der Funktionsfähigkeit des externen Dienstes).

#8 Xantiva am 7. Februar 2010 um 11:21

Danke für die Hinweise. Ich habe das Zusammenfassen auch schon mehrfach versucht, aber dann traten andere unerwünschte Nebeneffekte auf : Laut YSlow (Firebug) wurde die zusammengefasste .js Datei bei jedem Seitenaufruf neu geladen. Also nicht mehr von Browser gecacht. (Ich weiß noch nicht warum.)
Diesen Vorteil haben ja auch noch die von Google gehosten Frameworks: Je mehr Leute diese verwenden, desto höher ist die Warscheinlichkeit, dass der Besucher die Datei schon vom Besuch einer anderen Webseite im Browsercache hat und erst gar nicht mehr laden muss.

#9 Sergej Müller am 7. Februar 2010 um 12:56

@Xantiva
Wenn du Dateien mit dem Google Closure Compiler zusammenfügst, dann wird die Zieldateien auch auf deinem Space gehostet – dann muss du für die Cache-Header sorgen. Der AJAX API Loader übergibt bereits die korrekten Cache-Header.

Die von Google direkt bezogenen Frameworks haben mit Sicherheit den von dir beschriebenen Effekt und Vorteil, allerdings wenn diese Stand-Alone bezogen werden. Meistens hat man ja noch den eigenen JS-Code, den man dann in einer separaten Datei einbinden müsste. Ob man doch die Lib und den Eigencode in eine Datei zusammenfasst oder separat lädt (eine von Google und eine lokal) muss dann jeder für sich entscheiden. Ich würde bündeln, da man da nur einen Request hätte.

Sergej Müller
#10 Chris am 7. Februar 2010 um 21:10

Sehr interessante Geschichte, gerade die JS Dateien machen bei einer typische WP Installation ja oft den Hauptanteil an der Page Load aus. Ich hatte vor kurzem gerade die JS-Dateien mit dem Plugin W3 Total Cache gebündelt und nutze als CDN Cloudfront/S3 – der Closure Compile macht im Grunde das gleiche, nur dass man mehr Einfluss auf das JS-Endpaket hat, hört sich für mich nach einer guten Lösung an, die ich sicher mal ausprobieren werden

#11 Max am 11. Februar 2010 um 17:36

Sehr interessant, kann mich Chris nur anschließen!

5 Verlinkungen auf den Artikel

› JavaScript-Dateien mit Google bündeln - SEO.at

› Webseiten-Performance erhöhen – Braekling.de

› delicious Links: 12. January 2010

› JavaScript-Dateien mit Google bündeln | Webmaster, Security und [...]

› JavaScript-Dateien mit Google bündeln « Blogger City