Artikel vom 11. Januar 2010

Website-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.

Social Werkzeuge

17 Kommentare zum Artikel

201 Tage zuvor | #1 Ben

Danke für diesen guten und sehr informartiven Artikel.

Ben
201 Tage zuvor | #2 Andreas

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

Andreas
200 Tage zuvor | #3 pehbehbeh

Sehr informativer Artikel.

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

pehbehbeh
195 Tage zuvor | #4 Sergej Müller

@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
193 Tage zuvor | #5 Veit Krahl

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

Veit Krahl
191 Tage zuvor | #6 Marco Spescha

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

Marco Spescha
189 Tage zuvor | #7 Dieter

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).

Dieter
174 Tage zuvor | #8 Xantiva

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.

Xantiva
174 Tage zuvor | #9 Sergej Müller

@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
174 Tage zuvor | #10 Chris

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

Chris
170 Tage zuvor | #11 Max

Sehr interessant, kann mich Chris nur anschließen!

Max
118 Tage zuvor | #12 Paul

Ich bin gerade dabei meine private Internetpräsenz zu optimieren und beschäftige mich genau mit solchen Dingen.

Grandioser Artikel! Vielen Dank für die Mühe.

Paul
94 Tage zuvor | #13 JUICEDaniel

Frage: Lohnt sich denn der Einsatz des Plugins “Use Google Libraries”?

Liebe Grüße Daniel

JUICEDaniel
93 Tage zuvor | #14 Sergej Müller

Du gehst doch nicht wirklich davon aus, dass ich jedes WordPress-Plugin kenne und dieses eventuell empfehle?

Sergej Müller
93 Tage zuvor | #15 JUICEDaniel

Nöö, nicht jedes. Aber Use Google Libraries. Eins reicht mir schon ;) (Ich hatte mal einen großen englischsprachigen Artikel darüber gelesen, war schon einige Monate her… hatte mich letztens daran erinnert – und mal ehrlich: Wer ist naheliegender zu fragen als dich?)

JUICEDaniel
93 Tage zuvor | #16 Sergej Müller

Nee, gründlich kenne ich kaum ein fremdes Plugins. Leider fällt auch von dir genanntes in diese Kategorie. Ich bin ja sowieso der Meinung, weitgehend auf Plugins zu verzichten und Dinge händisch implementieren – soweit es natürlich geht und im Rahmen der Vernunft bleibt.

Kurzum: Kenn’ ich nicht ;)

Sergej Müller
93 Tage zuvor | #17 JUICEDaniel

Alles klar, ein Versuch war’s wert ;) Trotzdem danke für die Info!

JUICEDaniel

4 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 [...]

Kommentar verfassen