Automatisierung von Client-seitigen Web-Performance-Optimierungen

Automatisierung von Client-seitigen Web-
Performance-Optimierungen

Vorlesung: System Engineering und Management,
Prof. Walter Kriha

Student: Jakob Schröter
http://www.jakob-schroeter.de/

Juni 2011

Computer Science and Media
Hochschule der Medien Stuttgart

Dieses Paper soll einen Überblick über mögliche Automatisierungen von Client-seitigen
Performance Optimierungen von Webseiten geben. Dabei werden kommerzielle als auch freie
Lösungen betrachtet und einen Ausblick in die Zukunft der Performance-Optimierungen
gegeben.

System Engineering und Management Automatisierung von Client-seitigen Performance-Optimierungen

Inhaltsverzeichnis

1 Die Bedeutung der Website-Performance ............................................................................... 3
1.1 Automatische Performance-Optimierungen ...................................................................5
2 Optimierung im Deployment-Prozess .................................................................................... 6
2.1 Build-Tools ....................................................................................................................... 6
2.2 Framework-spezifische Build-Tools .................................................................................7
3 „On-the-fly“-Optimierung ....................................................................................................... 8
3.1 mod_deflate ...................................................................................................................... 8
3.2 mod_concat ...................................................................................................................... 8
3.3 Google mod_pagespeed ................................................................................................... 9
3.4 WEBO Site SpeedUp ....................................................................................................... 10
3.5 Strangeloop Site Optimizer ............................................................................................. 11
3.6 Blaze.io ............................................................................................................................. 12
4 Zukunft: Google SPDY als HTTP-Erweiterung ...................................................................... 14
5 Zusammenfassung .................................................................................................................. 15
Literatur .......................................................................................................................................... 16

Jakob Schröter | Hochschule der Medien Stuttgart 2


1 Die Bedeutung der Website-Performance
Zum Erfolg eines Webprojekts tragen neben der Qualität des Angebots auch maßgeblich die
User Experience und damit die Performance der Webseite bei.

Mehrere große Anbieter haben in Studien festgestellt, dass sich die Geschwindigkeit der
Webseite direkt auf die Webseiten-Zugriffe und den Umsatz auswirken. Zudem kann durch
Performance-Optimierungen oft auch Hardware eingespart werden.

Die folgende Tabelle zeigt einige Ergebnisse:

Amazon +100 ms 1% weniger Verkäufe
Yahoo +400 ms 5-9% weniger Zugriffe
Google +500 ms 20% weniger Zugriffe
Bing +2000 ms 4,3% weniger Umsatz/Nutzer (Schurman &
Brutlag, 2009)
Shopzilla -5000 ms 25 % mehr Zugriffe
7-12% mehr Umsatz
50% weniger Hardware (Souders, O'Reilly
Radar: Velocity and the Bottom Line, 2009)
Mozilla -2200 ms 15,4% mehr Downloads (Cutler, 2010)

Es wird deutlich, dass selbst kleine Unterschiede in der Ladezeit drastische Auswirkungen auf
das Geschäft haben können. (Website Optimization, LLC, 2008) Seit April 2010 lässt Google
sogar die Ladezeit einer Webseite mit in die Bewertung des Rankings einer Seite einfließen
(Singhal & Cutts, 2010).

Mit der Bewegung vom rein statischen Thin-Client zum immer komplexeren Rich-Client
verschiebt sich die Wartezeit von der Server- auf die Client-seite. Entwickler von Yahoo
stellten fest, dass 80-90% der Wartezeit auf dem Client stattfindet (Theurer, 2006) (Souders,
High performance web sites: essential knowledge for frontend engineers, 2007, S. 5).

Server Client

Wasserfall-Diagramm von web.de, generiert mit webpagetest.org



Am Beispiel des Wasserfall-Diagramms wird deutlich, dass das Laden und Verarbeiten der
Webseiten-Ressourcen wie Grafiken, JavaScript- und CSS-Dateien wesentlich länger dauert als
die reine Generierung der HTML-Seite auf dem Server.

Demnach muss die Performance nicht nur im Backend sondern auch im Frontend optimiert
werden. Auf der Client-Seite besteht ein sehr hohes Optimierungspotential. Für die Nutzer des
Webprojekts zählt dabei vor allem die gefühlte Ladezeit bis die Webseite aufgebaut und für
den Nutzer nutzbar ist. Die tatsächliche und die wahrgenommene Ladezeit können unter
anderem durch verschiedene Client-seitige Optimierungen verbessert werden (Schröter, 2011).

Zu den typischen Optimierungstechniken zählen unter anderem:

 Reduzierung der Datenmenge von Text-basierten Dateien (HTML, XML, JavaScript,
JSON, CSS, …)
o Inline-JavaScript und -Styles in externe Dateien auslagern
o Mehrfach-Einbindungen von Scripts vermeiden
o entfernen von unnötigen Kommentaren, Zeilenumbrüchen, …
o JavaScript-Minification
o GZIP-Kompression
 Reduzierung der Datenmenge von Grafiken
o Optimales Kompressionsformat wählen (JPG, PNG, GIF, WebP)
o Optimale Auflösung
o Entfernen unnötiger Meta-Daten
 Reduzierung der HTTP-Requests
o Zusammenfassung von JavaScript- und CSS-Dateien
o Zusammenfassen von Grafiken in eine Datei (CSS-Sprites)
 Richtige Konfiguration der HTTP-Header zur Optimierung des Browser-Caches
o Expires-Header
o ETag-Header
 Verteilen der Ressourcen in ein Content Delivery Network
o Optimierte Webserver für statische Dateien
o Für jeden Nutzer optimale Netzwerk-Anbindung
 Optimieren des Rendering-Prozesses (Progressive Rendering)
o Optimale Ladereihenfolge (CSS-Dateien zuerst, JavaScript zuletzt)
o Pre-/Post-Loading von Komponenten
o Early Flushing
o Anzahl der DOM-Element reduzieren
 Anwenden von Best Practices
o JavaScript optimieren
o CSS optimieren (CSS-Selektoren, …)



1.1 Automatische Performance-Optimierungen
Nun stellt sich die Frage, ob und wie diese Optimierungen automatisiert werden können.
Beispielsweise wäre es möglich den Optimierungsprozess in den Build/Deployment-Prozess zu
integrieren. So würden die Optimierungen automatisch vor der Auslieferung bzw. Live-
Installation des Projektes durchgeführt werden. Dadurch kann viel Zeit gespart und garantiert
werden, dass immer die Optimierungen vorgenommen werden. Ebenso müssen die einzelnen
Entwickler des Projekts keine besondere Rücksicht auf die Optimierungen nehmen. Dies
resultiert wiederum in einer geringeren Fehlerrate durch die vorgenommenen Optimierungen.

In den letzten Jahren wurden zudem einige Unternehmen gegründet, welche sich auf die
Automatisierung von Web-Performance-Optimierung spezialisiert haben. Alternativ zur
eigenen Integration in den Build/Deployment-Prozess versprechen die Produkte
vollautomatische Optimierungen ohne jegliche Änderungen an der eigenen Webanwendung.
Häufig funktioniert das Prinzip wie ein Proxy-Server. Die eigenen Domains werden per DNS-
Änderung an die Server des Anbieters umgeleitet. Dort wird die eigene Webseite abgerufen,
optimiert und anschließend an den Besucher ausgeliefert. Die Auslieferung findet hierbei
meist über ein CDN statt. So kann der eigene Betrieb eines global verteilten CDNs gespart
werden.

Im folgenden Kapitel werden die verschiedenen Varianten der automatischen Performance-
Optimierung näher betrachtet.



2 Optimierung im Build/Deployment-Prozess
Der Build/Deployment-Prozess großer Projekte bietet sich an um dort automatisierte
Performance-Optimierungen zu integrieren. Folgende der in Kapitel 1 genannten
Optimierungen können problemlos automatisiert werden:

 Reduzierung der Datenmenge von Text-basierten Dateien (HTML, XML, JavaScript,
JSON, CSS, …)
o entfernen von unnötigen Kommentaren, Zeilenumbrüchen, …
o JavaScript-Minification
 Reduzierung der Datenmenge von Grafiken
o Entfernen unnötiger Meta-Daten
 Reduzierung der HTTP-Requests
o Zusammenfassung von JavaScript- und CSS-Dateien
 Verteilen der Ressourcen in ein Content Delivery Network
o Optimierte Webserver für statische Dateien

In diesem Kapitel sollen frei verfügbare Lösungen, d.h. vorwiegend Open Source Lösungen
betrachtet werden.

2.1 Build-Tools
Das Zusammenfassen und komprimieren von JavaScript- und CSS-Dateien kann beispielsweise
mit Tools wie YUICompressor1 oder UglifyJS2 vorgenommen werde. Wichtig ist hierbei, einen
möglichst gut wartbaren Prozess zu entwickeln. Während der Entwicklung sollen diese
Dateien möglichst modular (das heißt in getrennten Dateien) und dokumentiert (das heißt
mit Kommentaren) verwendet werden. Gut lesbarer Code ist auch wichtig um JavaScript-Code
im Browser zu debuggen. Um Fehler zu vermeiden ist es wichtig, die Reihenfolge der
Einbindung der Dateien beizubehalten.

Wenn die Anwendung eine index-Seite beinhaltet, welche bereits alle JavaScript- und CSS-
Dateien beinhaltet könnte ein Script geschrieben werden, welches den HTML-Code nach
<script> und <link>-Tags durchsucht und diese Dateien zusammenfasst und darauf ein
Minify-Tool anwendet. Anschließend erstellt das Script eine angepasste Version der index-
Seite welche nur einen einzelnen Aufruf auf die zusammengefasste CSS- und JavaScript-Datei
beinhaltet.

Während es schwierig ist, die optimale Wahl der Grafikformate und Auflösungen zu
automatisieren lässt sich relativ einfach die Entfernung der Meta-Daten automatisch erledigen.
So können alle im Projekt verwendeten Grafiken automatisch durch Tools wie pngcrush3,
jpegtran4 oder auch dem API von smushit.com optimiert werden5.

1
http://developer.yahoo.com/yui/compressor/
2
https://github.com/mishoo/UglifyJS
3
http://pmt.sourceforge.net/pngcrush/
4
http://jpegclub.org/



Auch lässt sich die Verwendung von CSS-Sprites teilweise automatisieren. Das Tool
SmartSprites 6 benötigt beispielsweise lediglich ein paar Meta-Informationen in den CSS-
Dateien und erzeugt anschließend die CSS-Sprite-Dateien sowie die richtigen CSS-
Definitionen automatisch.

2.2 Framework-spezifische Build-Tools
Viele JavaScript-Frameworks und –Tools stellen bereits eigene Build-Tools zur Verfügung.
Diese verwenden beispielsweise Tools wie den YUICompressor um JavaScript- und CSS-
Dateien zusammenzufassen.

Bei der Verwendung von externen Frameworks und Tools sollte immer zunächst geprüft
werden, ob diese bereits eigene, für das Framework/Tool optimierte Build-Tools mitbringen.
So bietet beispielsweise Sencha mit dem Sencha SDK7 bzw. JSBuilder8 eine gute Lösung um
einen an die eigenen Bedürfnisse angepassten Build des Sencha ExtJS-Frameworks zu
erzeugen. Dabei werden unter Anderem die für das eigene Projekt benötigten JavaScript- und
CSS-Dateien automatisch zusammengefasst und komprimiert.

5
beispielsweise http://mathew-davies.co.uk/2010/01/01/smushit-php-class.html
6
http://csssprites.org/
7
http://www.sencha.com/products/extjs/download/
8
http://www.sencha.com/products/jsbuilder



3 „On-the-fly“-Optimierung
Bei der „On-the-fly“-Optimierung werden die Optimierungen während des Zugriffs
durchgeführt und ggf. für die nächsten Zugriffe im Cache gespeichert. Bei Projekten mit sehr
hohen Zugriffszahlen muss die durch die „Live-Optimierung“ zusätzliche Belastung der Server
berücksichtigt werden. Jedoch sind oft keine oder nur geringe Anpassungen an der eigenen
Anwendung nötig.

3.1 mod_deflate
Das weit verbreitete Apache-Modul mod_deflate 9 kann dazu verwendet werden, alle
textbasierten Dateien wie HTML, CSS, JavaScript, XML und JSON automatisch mit dem
Deflate-Algorithmus 10 zu komprimieren. Alle aktuellen Browser unterstützten diese
Kompressionstechnik. An der eigenen Anwendung müssen hierfür keine Anpassungen
vorgenommen werden und die zusätzliche Server-Belastung ist gering. Das Modul sollte daher
bei jedem Webprojekt aktiviert werden, das Optimierungspotential ist enorm. Für andere
Webserver sind vergleichbare Module verfügbar.

Zu beachten ist allerdings, dass die aktuellen Browser die Kompression nur für den
Transferweg vom Server zum Browser, nicht aber für den Weg vom Browser zum Server
unterstützen. So können Daten, die per GET/POST-Request vom Browser an den Server
gesendet werden nicht komprimiert werden, obwohl der Apache-Webserver die Unterstützung
dafür bereitstellt11.

3.2 mod_concat
Das Apache-Modul mod_concat12 erlaubt es, mehrere JavaScript- oder CSS-Dateien innerhalb
eines Requests dynamisch serverseitig zusammenzuführen und als eine einzelne Datei
auszuliefern.

Statt folgendem Aufruf:

<script src="js/base.js"></script>
<script src="js/uploader.js"></script>

Könnte der Aufruf wie folgt aussehen:

<script src="??js/base.js,js/uploader.js"></script>

Intern werden die zusammengeführten Dateien gecached, sodass sie nicht bei jedem Request
neu erzeugt werden.

9
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
10
Der Deflate-Algorithmus findet unter anderem auch im ZIP-Dateiformat Verwendung.
11
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#input
12
http://code.google.com/p/modconcat/



Ähnlich wie mod_concat funktioniert das PHP-basierte Tool combine13. Allerdings basiert es
rein auf PHP und optional mod_rewrite und kann dadurch auch verwendet werden, wenn kein
Zugriff auf die volle Apache-Konfiguration besteht (z.B. bei einfachen Webhosting-Paketen).

3.3 Google mod_pagespeed
Google bietet mit der Page Speed 14 Familie mehrere Produkte an, mit deren Hilfe die
Performance von Webseiten gemessen und analysiert werden kann. Dazu zählt beispielsweise
das gleichnamige Page Speed Plugin für die Firefox-Erweiterung Firebug. Dieses analysiert eine
Webseite auf Basis verschiedener Best Practice Performance-Regeln und bietet Vorschläge, wie
die Performance der Webseite optimiert werden kann.

Im November 2010 veröffentliche Google das Apache-Modul mod_pagespeed15. Das Modul soll
Webseiten vollautomatisch auf bestmögliche Performance optimieren. An den eigenen
Webanwendungen müssten dazu keinerlei Änderungen vorgenommen werden. 16 Hierbei
kommen vorwiegend Optimierungen zum Einsatz, welche die Lade-, Anzeige- und
Ausführungszeit im Browser beeinflussen, das heißt Client-seitige Optimierungen. Dafür
kommen verschiedene Filter zum Einsatz welche die Ausführung von JavaScript, HTML und
den CSS-Stylesheets optimieren.

Folgende Filter können bei mod_pagespeed aktiviert werden:

 Optimize Caching
o Extend Cache
o Outline CSS
o Outline JavaScript
 Minimize Round Trip Times
o Combine CSS
o Inline CSS
o Inline JavaScript
o Configuration file directive to shard domains
 Minimize Request Overhead
o Configuration file directive to map domains
 Minimize Payload Size
o Collapse Whitespace
o Combine Heads
o Elide Attributes
o Minify JavaScript
o Optimize Images
o Remove Comments
o Remove Quotes
o Rewrite CSS

13
http://rakaz.nl/code/combine
14
http://code.google.com/intl/de-DE/speed/page-speed/docs/overview.html
15
vgl. (Google Inc., 2010)
16
siehe (Google Inc.)



o Trim URLs
 Optimize Browser Rendering
o Move CSS to Head
o Optimize Images

Bei Webservern, die bislang in der Standardkonfiguration betrieben werden, kann durch
mod_pagespeed die Performance deutlich gesteigert werden. Der größte Performancegewinn
stammt dabei jedoch durch die Umkonfiguration des Apache-Servers. So aktiviert
mod_pagespeed unter Anderem das Apache-Modul mod_deflate. Das heißt das Page Speed-
Modul selbst ist mehr oder weniger überflüssig wenn die richtige Konfiguration direkt im
Webserver vorgenommen wird und die Grundregeln der Performance-Optimierungen bei der
Erstellung der Webseite bereits berücksichtigt wurden.

Dennoch ist die Idee hinter mod_pagespeed gut, vor allem wird damit in Bezug auf Web-
Performance-Optimierungen eher unerfahrenen Webentwicklern und Server-Administratoren
geholfen die Performance zu verbessern.

3.4 WEBO Site SpeedUp
Mit dem Tool WEBO Site SpeedUp17 kann die Performance von PHP-basierten Projekten
automatisch verbessert werden. Das Tool wird lokal auf dem eigenen Webserver installiert und
klinkt sich in die eigene Anwendung ein. Neben PHP und ein paar PHP-Modulen werden
keine besonderen Anforderungen an den Webserver gestellt. WEBO Site SpeedUp stellt eine
Weboberfläche zur komfortablen Konfiguration bereit. Für viele verbreitete PHP-
Anwendungen wie Drupal, WordPress oder Magento sind speziell angepasste Versionen
verfügbar. Die Konfiguration ist sehr einfach, im Try&Error-Verfahren können verschiedene
Optimierungsmöglichkeiten aktiviert, getestet und die Performance verglichen werden.

Abbildung 1: Quelle: WEBO Site SpeedUp

17
http://www.webogroup.com/home/site-speedup/



Das Tool analysiert die von der eigenen Anwendung erzeugte HTML-Ausgabe und kann
folgende Optimierungen durchführen:

 CSS/JavaScript zusammenfassen
 GZIP-Kompression für HTML/CSS/JS/ICO Dateien auch wenn der Webserver kein
mod_deflate bereit stellt
 Dynamisches Nachladen von JavaScript
 CSS/JavaScript/HTML Minification (per JSMin, YUICompressor oder Packer)
 Vordefinierte optimale Einstellungen für die .htaccess-Datei für Apache Webserver
(mod_deflate + mod_filter für GZIP, mod_mime + mod_rewrite für statisches GZIP,
mod_expires oder mod_rewrite für Client-seitiges Caching, mod_headers)
 Optimiertes Client-seitiges Caching
 Server-seitiges Caching kann einzelne Teile oder die komplette Webseite
zwischenspeichern
 CSS Sprites (automatisches Zusammenfassen von CSS-Hintergrundgrafiken)
 Bildoptimierung per smushit.com
 CDN Unterstützung (statische Dateien können automatisch auf das CDN verteilt
werden)
 Inline-Grafiken (data:URI)

WEBO Site SpeedUp kann mit reduziertem Funktionsumfang kostenlos verwendet werden.

3.5 Strangeloop Site Optimizer
Die Firma Strangeloop Networks18 hat sich auf die Web Performance Optimierung spezialisiert
und bietet mit dem Site Optimizer eine kommerzielle Lösung an, welche die eigene Webseite
ohne jegliche Änderungen am Quellcode „on-thy-fly“ optimiert. Der Site Optimizer wird
zwischen die eigenen Server und die Browser-Client geschaltet. Dieser optimiert
vollautomatisch jeden Seitenzugriff auf Basis der Best Practices von Yahoo19 und Google20 und
eigenen Regeln der Firma Strangeloop. Der HTML-Code und alle Ressourcen werden nun
spezifisch für den Ziel-Browser und das -Endgerät optimiert.

18
http://www.strangeloopnetworks.com/
19
http://developer.yahoo.com/performance/rules.html
20
http://code.google.com/intl/de-DE/speed/page-speed/docs/rules_intro.html



Abbildung 2: Quelle: Strangeloop

Besonderer Fokus liegt zudem auf der Optimierung der vom Nutzer wahrgenommenen
Ladezeit. Dafür analysiert der Site Optimizer das Nutzerverhalten und berechnet, welche
Seiten der eigenen Webpräsenz der Nutzer vermutlich als nächstes aufrufen wird. Während
der Nutzer noch mit dem Lesen der aktuellen Seite beschäftigt ist wird der Browser bereits
angewiesen die Ressourcen (JavaScript, CSS, Grafiken, …) der vermutlich nächsten Seite
herunter zu laden. Dadurch kann der nächste Seitenaufruf (wenn der Nutzer wirklich die
vermutete Seite aufruft) deutlich beschleunigt werden. Ebenso wird analysiert, welche
Ressourcen typischerweise für eine bestimmte Seite benötigt werden. Während der eigene
Anwendungs-Server noch mit der Generierung des HTML-Codes beschäftigt ist sendet der
Strangeloop Site Optimizer die vermuteten Ressourcen bereits an den Client. Sobald der Server
dann die Seite fertig generiert und den HTML-Code an den Client ausgeliefert hat kann die
Seite sehr schnell darstellt werden, da viele benötigte Ressourcen schon verfügbar sind.

Die Software von Strangeloop wird zum einen als Hardware-Lösung für die Installation im
Rechenzentrum, als auch als Cloud-basierte Lösung angeboten. Diese kann per DNS-
Umleitung vor die eigenen Server geschaltet werden.

Über eine Weboberfläche kann die Lösung konfiguriert und der Optimierungs-Status
kontrolliert werden. Ebenso können statistische Daten über die Optimierungen in bereits
bestehende Tracking-Systeme wie Google Analytics, Omniture oder Web Trends eingespielt
werden.

3.6 Blaze.io
Das im Jahr 2010 gegründete Unternehmen Blaze Software Inc.21 hat sich ebenfalls auf die
Optimierung von Website-Performance spezialisiert. Die Lösung funktioniert wie folgt: Auf
dem eigenen Webserver wird der so genannte Blaze Agent installiert. Die leichtgewichtige
Anwendung prüft bei jedem Request, ob bereits eine optimierte Version der angeforderten
Seite vorliegt. Wenn nicht, wird die Webseite regulär an den Besucher ausgeliefert und
anschließend Informationen zum Request sowie eine Kopie der angeforderten Seite an die
Blaze-Cloud gesendet. Diese analysiert die Webseite und optimiert sie anhand verschiedener

21
http://www.blaze.io/



Regeln. Dabei kommen die Standard-Best Practices wie zusammenfassen, minimieren und
komprimieren von Ressourcen zum Einsatz. Ebenso werden alle statischen Ressourcen, d.h.
Grafiken, CSS- und JS-Dateien im CDN abgelegt. Wird die Seite nun erneut von einem
Besucher angefordert, liefert der Blaze Agent die optimierte Seite aus. Ebenso werden statische
Ressourcen nun aus dem Blaze- oder einem beliebigen CDN an den Besucher geliefert.

Abbildung 3: Quelle: blaze.io

Ähnlich wie bei Strangeloop werden dem Browser bereits die vermutlich für den nächsten
Request nötigen Ressourcen zugespielt.

Große Vorteile der Cloud-basierten Lösung sind, dass an der eigenen Anwendung und auf den
eigenen Servern kaum Änderungen vorgenommen werden müssen. Ebenso benötigt der Blaze
Agent keine häufigen Update- und Wartungsarbeiten, da die eigentliche Analyse und
Optimierung der Webseiten extern in der Blaze-Cloud stattfindet. Daher werden die eigenen
Server auch kaum zusätzlich belastet.



4 Zukunft: Google SPDY als HTTP-Erweiterung
Das von Google entwickelte Projekt SPDY kann zwar im Vergleich zu den in den vorherigen
Kapiteln genannten Lösungen nicht direkt für eigene Projekte verwendet werden, dennoch ist
das Projekt für die Zukunft der Web Performance Optimierungen sehr spannend: das bislang
experimentelle Protokoll könnte viele der heutigen Performance-Optimierungen überflüssig
machen.

Es ist bekannt, dass das HTTP-Protokoll für die mittlerweile sehr komplexen Webprojekte
einen relativ großen Overhead mitbringt. Für jede notwendige Datei muss eine eigene
Verbindung initialisiert werden, bei jedem Request werden einige (unkomprimierte) HTTP-
Header übertragen, …

Das SPDY-Application-Layer-Protokoll stellt eine interessante Verbesserung dar. Durch die
Reduzierung 22 und Komprimierung von HTTP-Headern, dem Senden und Verarbeiten
multipler Streams und einer konsequenten Abfrage-Priorisierung sollen im Test 25 der
beliebtesten Webseiten um 55 Prozent schneller geladen werden als bisher23 – inklusive SSL-
Verbindung, welche die Grundlage der Kommunikation darstellt um eine funktionierende
Übertragung durch bestehende Proxy-Server hindurch zu ermöglichen. SPDY basiert auf TCP
und benötigt daher keine Änderungen an der bestehenden Netzwerkinfrastruktur.

Um das Protokoll zu nutzen muss der Server als auch der Browser eine SPDY-Unterstützung
mitbringen. Anpassungen an den Webanwendungen selbst sind nicht notwendig. Viele der
heutigen Optimierungen wie etwa CSS-Sprites werden durch SPDY überflüssig. Durch CSS-
Sprites lässt sich die Anzahl der HTTP-Requests oft deutlich reduzieren – jedoch
verschlechtert sich dadurch die Wartbarkeit der Anwendung. Auf mobilen Geräten können
CSS-Sprites sogar zu Performance-Einbußen führen, da bei jeder Verwendung eines
Ausschnitts aus der Sprite-Grafik die komplette Grafik in den Speicher geladen und verarbeitet
werden muss. Da SPDY ohnehin alle Ressource-Dateien in einem gemeinsamen Daten-Stream
überträgt müssen die Dateien nicht mehr kombiniert werden. Dabei sieht SPDY auch eine
Push-Funktion vor, über die Server Daten an den Browser senden können, noch bevor dieser
die Ressource angefragt hat. So können beispielsweise schon Ressourcen gesendet werden, die
auf der folgenden Seite benötigt werden.

Wie man es von Google erwartet, ist Google wiedermal Vorreiter: Google Chrome seit Version
11 und alle Google-Dienste wie Google Mail unterstützen bereits SPDY24. Nun ist die Frage, ob
und wann andere Browser und Webdienste nachziehen werden.

Erste Implementierungen als Apache-Modul 25 , Python 26 , Java 27 , Ruby 28 oder für Node.js-
Server29 befinden sich momentan in der Entwicklung.

22
Der Header „User-Agent“ wird bei SPDY beispielsweise nur bei der ersten Verbindung mitgesendet, da
es sehr unwahrscheinlich ist, dass sich der User-Agent während einer laufenden Session ändert.
23
(Belshe & Peon, 2009)
24
(golem.de, 2011)
25
http://code.google.com/p/mod-spdy/
26
http://github.com/mnot/nbhttp/tree/spdy
27
http://svn.apache.org/repos/asf/tomcat/trunk/modules/tomcat-lite
28
https://github.com/igrigorik/spdy



5 Zusammenfassung
Die Optimierung der Performance einer Webseite ist eine komplexe und zeitaufwändig
Aufgabe. Umso verlockender ist daher ein möglichst weit automatisierter
Optimierungsprozess. Wie in den vorhergehenden Kapiteln gezeigt wurde existieren bereits
einige Lösungen mit denen viele der Optimierungen automatisch angewendet werden können.
Dennoch gibt es bisher keine perfekte „One-Click“-Lösung. Der Wirkungsgrad dieser
Lösungen variiert stark von Projekt zu Projekt. So reicht es beispielsweise bei einer
weitgehendsten statischen Webseite aus, die Bilder im Deploymentprozess zu optimieren,
während bei einer Magazin-Webseite die Bildoptimierung vor jedem Veröffentlichen eines
Artikels durchgeführt werden sollte. Ebenso wird bei manchen Anwendungen der HTML-Code
der Seite dynamisch per JavaScript erzeugt. Automatische Tools haben hierbei kaum eine
Möglichkeit Optimierungen am HTML-Code vorzunehmen. Manuelle Optimierungen bringen
immer bessere Ergebnisse, da sie gezielt auf die speziellen Anforderungen der eigenen
Anwendung angepasst werden können. Auch die meisten kommerziellen Lösungen beinhalten
manuelle projektspezifische Analysen der bestmöglichen Performanceoptimierungen welche
die Grundlage für die Konfiguration der automatischen Tools darstellen. Anschließend können
die konfigurierten Tools jedoch bei jedem Deployment des Projekts oder „on-the-fly“
automatisch ausgeführt werden, wodurch viel Aufwand eingespart werden kann.

Sehr spannend sind die Entwicklungen rund um Google SPDY. Sollten die anderen
Browserhersteller neben Google nachziehen und eine SPDY-Unterstützung in ihre Browser
integrieren, so könnte SPDY der neue Standard für den Transfer von Webseiten werden. Dabei
würden einige der aktuell empfehlenswerten Optimierungen wie das Zusammenfassen von
JavaScript- und CSS-Dateien sowie CSS-Sprites überflüssig werden.

29
https://github.com/donnerjack13589/node-spdy



Literatur

Belshe, M., & Peon, R. (11. November 2009). A 2x Faster Web. Abgerufen am 21. März 2011 von
Chromium Blog: http://blog.chromium.org/2009/11/2x-faster-web.html

Cutler, B. (März 2010). Von Blog of Metrix: Firefox & Page Load Speed:
http://blog.mozilla.com/metrics/category/website-optimization/ abgerufen

golem.de. (08. April 2011). Chrome nutzt SPDY statt HTTP. Abgerufen am 08. April 2011 von
http://www.golem.de/1104/82657.html

Google Inc. (03. November 2010). Make your websites run faster, automatically -- try
mod_pagespeed for Apache. Abgerufen am 02. Februar 2011 von Official Google
Webmaster Blog: http://googlewebmastercentral.blogspot.com/2010/11/make-your-
websites-run-faster.html

Google Inc. (kein Datum). Page Speed Family. Abgerufen am 10. Februar 2011 von
http://code.google.com/intl/de-DE/speed/page-speed/docs/overview.html

Nielsen, J. (Juni 2010). Von Website Response Times: http://www.useit.com/alertbox/response-
times.html abgerufen

Schröter, J. (18. Januar 2011). Client-side Performance Optimizations. Von
http://slideshare.net/jakob.schroeter/Client-side-Performance-Optimizations
abgerufen

Schurman, E., & Brutlag, J. (Juni 2009). Von Performance Related Changes and their User
Impact: http://www.slideshare.net/dyninc/the-user-and-business-impact-of-server-
delays-additional-bytes-and-http-chunking-in-web-search-presentation abgerufen

Singhal, A., & Cutts, M. (April 2010). Von Official Google Webmaster Central Blog: Using site
speed in web search ranking:
http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-
ranking.html abgerufen

Souders, S. (2007). High performance web sites: essential knowledge for frontend engineers.
(O'Reilly, Hrsg.)

Souders, S. (Juli 2009). Von O'Reilly Radar: Velocity and the Bottom Line:
http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html abgerufen

Theurer, T. (November 2006). Von Yahoo! User Interface Blog: Performance Research, Part 1:
What the 80/20 Rule Tells Us about Reducing HTTP Requests:
http://www.yuiblog.com/blog/2006/11/28/performance-research-part-1/ abgerufen

Website Optimization, LLC. (30. Mai 2008). The Psychology of Web Performance. Abgerufen
am 10. September 2010 von
http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/



Yang, Z. (August 2009). Von Facebook: Every Millisecond Counts:
http://www.facebook.com/note.php?note_id=122869103919 abgerufen


Automatisierung von Client-seitigen Web-Performance-Optimierungen

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Automatisierung von Client-seitigen Web-Performance-Optimierungen

Semelhante a Automatisierung von Client-seitigen Web-Performance-Optimierungen (20)

Mais de Jakob

Mais de Jakob (8)

Automatisierung von Client-seitigen Web-Performance-Optimierungen