Nachdem Google nun offiziell bestätigt hat, dass auch die Performance einer Website als Ranking-Faktor für den Such-Index dient, geht vielerorten das Optimieren der Webpräsenz los. Aber nicht nur für Google ist die Ladegeschwindigkeit wichtig. Vor allem auch für den Besucher der Seite. Denn dieser landet bei extensiven Ladezeiten schnell bei der Konkurrenz.

Die folgende Liste bietet einen Überblick über die 23 wirkungsvollsten Optimierungsmöglichkeiten und kann als Performance-Checkliste verstanden werden, die man Punkt für Punkt abarbeiten kann, um so sein System zu beschleunigen.

Um aber überhaupt eine Steigerung der Performance feststellen zu können, ist es unabdingbar, diese auch zu messen. Es gibt für diesen Zweck zahlreiche Tools, von denen sich aber eines besonders eignet: „ApacheBench“ ist kostenfrei, ausreichend funktionell und vor allem für alle Betriebssysteme erhältlich [1]. Nach der Installation (wenn Apache als Webserver verwendet wird, liegt das Tool bereits vor) wird ApacheBench mittels „ab“ (oder unter Windows „ab.exe“) aufgerufen: „ab -n 100 -c 10 http://www.IhreDomain.de/“. Dies simuliert 100 Zugriffe (davon 10 parallele) auf den Webauftritt und gibt das Ergebnis übersichtlich in einer Tabelle aus. Besonders den Wert „Time taken for test“ sollte man sich gut merken und vergleichen, nachdem der Test nach jeder Optimierungsmaßnahme wiederholt wurde.

Ein weiteres sehr aussagekräftiges Tool ist „YSlow“, das die Performance direkt beim Client misst. „YSlow“ wird als Firefox-Extension [2] angeboten und benötigt „Firebug“ für den Betrieb.

Da UTF-8 mittlerweile zum Standard gehört, ist es wichtig, sein System komplett auf diesen einzurichten.

Dabei kann man aber einige Fehler machen. Als erstes sollte dafür gesorgt werden, dass die für TYPO3 benötigte Datenbank auch wirklich in UTF-8 angelegt wird – das ist nicht unbedingt der Fall, da TYPO3 hier hardkodiert ein „CREATE DATABASE xxx“ verwendet und nicht, wie es besser wäre, ein „CREATE DATABASE DEFAULT CHARACTER SET uft8“, das man am besten manuell ausführt. Weiterhin sollte im Install-Tool die Eigenschaft „[BE][forceCharset] = ‚utf-8’“ gesetzt werden. Nun muss noch dafür gesorgt werden, dass PHP UTF-8-kodierte Strings intern nicht immer in ISO-8859-1 umwandelt. Dies erreicht man mit der Install-Tool-Einstellung „[SYS][setDBinit] =’SET NAMES utf8\nSET SESSION character_set_server=utf8’“.

Die Ausgabe von TYPO3 erfolgt per default immer unkomprimiert. Es ist aber auch möglich, diese vor dem Ausliefern zu komprimieren und so zu übertragen. Dadurch erhöht sich zwar leicht der Aufwand bei der Seitengenerierung, im Gegenzug beschleunigt sich die Übertragung allerdings beträchtlich. Allerdings benötigt PHP dazu die Bibliothek „zlib“, die aber zum Standard zählen sollte. Durch das Setzen der Option „[BE][compressionLevel] = 5 und [FE][compressionLevel] = 5“ im Install-Tool kann man nun die Komprimierung einstellen.

Von Haus aus ist TYPO3 so eingestellt, dass alle Datenbankverbindungen permanent gehalten werden. Dies kostet nicht nur unnötig Ressourcen, sondern in Folge dessen auch Rechenzeit. Daher sollte im Install-Tool dafür gesorgt werden, dass die Einstellung „[SYS][no_pconnect] =1“ gesetzt ist.

Gerade etwas ältere Installationen sind oft noch mit der Extension „sys_stat“ (oder einer ähnlichen) zur Aufzeichnung von Seitenzugriffen ausgestattet. Allerdings bremsen diese Extensions die Performance von TYPO3 erheblich aus. Insofern sollte man entweder auf Google Analytics oder Webalizer ausweichen.

Am Anfang wird der Webauftritt mit allerlei nützlichen und vor allem benötigten Extensions ausgestattet. Aber mit der Zeit ändern sich die Bedürfnisse und so kommt es sehr häufig vor, dass Extensions auf dem System installiert sind, die nicht mehr benötigt werden. Allerdings verbraucht jede Extension – auch wenn sie nicht verwendet wird – wertvolle Rechenzeit. Es müssen Klassen geladen und initialisiert oder statische Templates geladen werden, die man gar nicht benötigt. Daher sollten in regelmäßigen Abständen dringend alle nicht benötigten Extensions im Extension-Manager deinstalliert und – schon alleine aus Sicherheitsgründen – am besten komplett vom System gelöscht werden.

Extensions können im Extension-Manager im Bereich „Install Extensions“ gelöscht werden, indem man auf den Namen der Extension klickt, oben aus dem Pulldown-Menü den Eintrag „Backup/Delete“ wählt und anschießend auf den Link „DELETE EXTENSION FROM SERVER“ klickt.

Die – zugegebenermaßen sehr leistungsfähige und oft eingesetzte – Volltextsuche „indexed_search“ hat einen erheblichen Nachteil. Durch die Verwendung der Extensions sinkt die Performance bei steigenden Seitenzahlen nahezu exponentiell. Daher sollte man versuchen, auf diesen Performance-Killer zu verzichten und lieber auf modernere, schlankere Methoden setzen. Will man den selben (und sogar noch einen viel mächtigeren) Leistungsumfang verwenden, kommt man an „Apache Solr“ [3] nicht mehr vorbei. Wem ein geringerer Leistungsumfang reicht, kann „mnogosearch“ oder „joh_advbesearch“ verwenden.

Extensions, die den Cache permanent mittels der Anweisung „$GLOBALS[„TSFE“]->set_no_cache();“ abschalten, sollten unbedingt deinstalliert werden, da damit das Caching von TYPO3 unwirksam wird, was in einer schlechteren Performance resultiert. Daher müssen alle Extensions ermittelt werden, die diese Anweisung in sich tragen. Das erledigt man direkt auf der Shell-Ebene oder mit der Extension „mw_shell“. Dort kann dann in das Feld „Command“ der folgende Befehl eingegeben werden, der alle betroffenen Extensions ermittelt: „grep -r -n ’set_no_cache()‘ *“.

Die so gefundenen Extensions sollten anschließend deaktiviert oder besser deinstalliert werden.

Mit Hilfe dieser Extension kann sowohl eine MySQL-Replikation (in der schreibende und lesende Zugriffe auf die Datenbank getrennt und somit optimiert werden) aufgebaut als auch Memcached verwendet werden. Memcached ist ein unter der BSD-Lizenz veröffentlichter Cache-Server zum allgemeinen Hinterlegen und Abholen von Daten aus dem Arbeitsspeicher. Dieser ist erheblich schneller als ein Zugriff des Caches über die Datenbank oder das File-System.

Mit Hilfe eines Proxyservers kann die Performance einer Website erheblich verbessert werden. So ist es kein Wunder, dass High-Performance-Websites wie POS-Sites, Finanzscout-Gruppe oder FTI entsprechende Software im Einsatz haben – in diesem Fall den sehr leistungsfähigen Varnish Cache [4], der sich langsam als Standard durchsetzt. Ein weiterer häufig eingesetzter Cache ist Squid [5], der ebenfalls bei vielen zeitkritischen Websites eingesetzt wird.

Die TYPO3-System-Extension „css_styled_content“ stattet den Quellcode mit reichhaltigen HTML-Kommentaren aus, die in der Entwicklung der Website sehr praktisch sein können. Im Live-Betrieb stellen diese Kommentare aber zusätzlichen Quellcode da, der jedes Mal mit übertragen werden muss. Daher sollte man sich von diesem schleunigst trennen. Dies geht mit den folgenden zwei Zeilen im TypoScript-Setup ganz einfach:

config.disablePrefixComment = 1
lib.stdheader.5.prefixComment >
lib.stdheader.stdWrap.prefixComment >
tt_content.stdWrap.prefixComment >

Ein so genannter PHP-Accelerator ist eine Software, die als Beschleuniger, Optimierer und Cache für PHP-Seiten dient. Dabei wird das PHP in einem kompilierten und optimierten Zustand gespeichert und bei Bedarf ausgeliefert. So kommt es zu einer erheblichen Steigerung der Ausführgeschwindigkeit – gerade bei PHP-lastigen Websites, wie es bei TYPO3 der Fall ist. Als besonders geeignet hat sich der freie Beschleuniger eAccelerator [6] erwiesen, der sehr unkompliziert zu installieren und konfigurieren ist.

TYPO3 hat prinzipiell drei Logs, die allesamt im Install-Tool aktiviert werden können: das Systemlog (oder auch „syslog“ genannt), das dazu dient, systemrelevante Nachrichten aufzunehmen; das Developer-Log (oder auch „devlog“), das Entwickler-relevante Nachrichten aufnimmt sowie das Deprecation-Log, in dem Funktionsaufrufe mitgeschrieben werden, die als veraltet („deprecated“) gekennzeichnet werden. Während alle drei Logs auf Entwicklersystemen durchaus sinnvoll sind, sollte man diese in einem Live-System deaktivieren, indem man folgende Optionen im Install-Tool setzt:
„[SYS][systemLog] = , [SYS][enableDeprecationLog] = 0, [SYS][enable_DLOG] = 0.“

Da TYPO3 beim Seitenaufbau überwiegend mit der Datenbank kommuniziert und sich so alle benötigten Daten und Informationen daraus besorgt, sollte auch dieser Teil optimal konfiguriert werden. Hierbei muss man Zugriff auf die MySQL-Konfiguration haben, die sich zumeist in der Datei „my.cnf“ befindet. Dort fügt man entweder die folgenden Optionen ein (wenn diese noch nicht existieren), ändert die Werte entsprechend oder kommentiert die Zeile aus:

max_connections = 400
#log-bin=mysql-bin
query_cache_limit = 2M
query_cache_size  = 64M
query_cache_type  = 1
table_cache       = 256
key_buffer_size   = 64M

Wann immer es geht, sollte man auf den Einsatz von „TypoScript _INT“-Objekten (also „USER_INT“ und „COA_INT“) verzichten, da diese die Performance erheblich verringern. Oftmals kann es bei der Erstellung eigener Extensions ressourcensparender sein, den Cache der ganzen Seite zu löschen, als ein „_INT-Objekt“ rendern zu lassen.

Wenn man lediglich die Uhrzeit oder das Datum ausgeben will, ist es ohnehin sehr viel performanter, dies mit JavaScript zu realisieren. Und auch bei anderen Daten, wie etwa dem Namen des aktuell eingeloggten Users, kann es oftmals sehr viel schneller sein, diese per AJAX (über den eID-Mechanismus [7] ) nachzuladen.

Gerade bei Inhouse-Schulungen lässt sich oft ein Wildwuchs im Bereich der Benutzerrechte beobachten. So werden bei zehn möglichen Usern auch parallel zehn Usergruppen angelegt, obwohl diese nahezu identisch konfiguriert sind. Hier lohnt es sich, vor der Erstellung der Benutzerrechte erst einmal ein sinnvolles Konzept zu erarbeiten und zu versuchen, am Ende möglichst wenige – wirklich unterscheidbare – Benutzergruppen zu erhalten. Denn für jede Benutzergruppen-Kombination wird eine Kopie der Seite im Cache vorgehalten. Das sind bei fünf Benutzergruppen bereits 32 verschiedene Kombinationen (25) und damit eben 32 Einträge in der Cache-Tabelle.

Conditions können immer dann zu einem Performance-Problem werden, wenn diese nicht gezielt eingesetzt werden. Will ich beispielsweise eine bestimmte Seite abfragen (weil man dort zum Beispiel den Marker „###DATUM###“ mit dem aktuellen Datum füllen will), so muss man darauf achten, dass die Condition auch wirklich nur auf diese eine Seite anschlägt und nicht etwa noch auf deren Unterseiten – selbst wenn dort der Marker nicht vorhanden sein sollte.

Nicht nur TYPO3 kann für das Caching zuständig sein, sondern auch der Browser. Weiß dieser etwa, dass sich die Seite überhaupt nicht verändert hat, muss er diese nicht extra anfordern und spart somit wertvolle Übertragungszeit. Dafür muss dem Browser aber erst mitgeteilt werden, wie lange die Seite im Cache vorgehalten werden soll. Dafür werden so genannte Cache-Header verwendet, die per HTTP-Header mit jedem Response übertragen werden. Diese schaltet man im TypoScript-Setup wie folgt ein: „config.sendCacheHeaders = 1“.

Hat die Website wenig bis gar keine dynamischen Anteile, kann man mit der Extension „nc_staticfilecache“ [8] (oder etwa „fl_staticfilecache“) statische HTML-Seiten erzeugen lassen.

Wenn eine statische Version existiert, wird diese anstelle eines TYPO3-Renderings ausgeliefert und kann so einen erheblichen Performance-Schub geben. Damit einhergehend muss man allerdings auf Conditions verzichten, da diese in statischen Seiten nicht ausgewertet werden können. Serverseitig muss „mod_rewrite“ und „mod_expires“ vorhanden sein.

Auf einigen Websites gibt es Elemente, die sich über mehrere Monate nicht oder sogar niemals ändern. Man denke dabei nur an Logos, Background-Bilder oder etwa das Favicon. Alle diese Dateien könnten bequem länger als die sie umgebende Website im Cache vorgehalten werden, sodass zumindest für wiederholende Besucher eine Performance-Verbesserung zu erwarten ist. Dafür benötigt der Webserver ein aktiviertes Modul „mod_expires“ und eine „.htaccess“-Datei, die zum Beispiel folgende Information enthält (in der Annahme, dass alle Dateien im Verzeichnis „fileadmin/website/pics/“ länger im Cache gehalten werden können):

<LocationMatch "/fileadmin/website/pics/">
	<IfModule mod_expires.c>
		ExpiresActive on
		ExpiresDefault "access plus 6 months"
		ExpiresByType image/gif "access plus 6 months"
		ExpiresByType image/png "access plus 6 months"
		ExpiresByType text/css "access plus 6 months"
		ExpiresByType application/x-javascript "access plus 6 months"
		ExpiresByType text/javascript "access plus 6 months"
		ExpiresByType image/jpeg "access plus 6 months"
	</IfModule>
</LocationMatch>

Gerade bei einem langsamen Datenbankserver oder bei extrem großen Cache-Tabellen (aufgrund von vielen Seiten und Parametern) kann es durchaus eine Beschleunigung darstellen, diesen Cache ins Filesystem oder gar in den Hauptspeicher zu verlagern.

TYPO3 hat in der Version 4.3 ein Caching-Framework spendiert bekommen, das allerdings zunächst im Install-Tool mit der Option „[SYS][useCachingFramework] = 1“ aktiviert werden muss. Zusätzlich wird in der Datei „typo3conf/localconf.php“ detailliert konfiguriert, wohin der jeweilige Cache geschrieben werden soll – hier als Beispiel alle drei möglichen Methoden:

$TYPO3_CONF_VARS['SYS']['caching']['cacheBackendAssignments'] = array(
	'cache_hash' => array(
		'backend' => 't3lib_cache_backend_File',
		'options' => array(
		)
	),
	'cache_pages' => array(
		'backend' => 't3lib_cache_backend_Memcached',
		'options' => array(
			'servers' => array('localhost:11211'),
		)
	),
	'cache_pagesection' => array(
		'backend' => 't3lib_cache_backend_Db',
		'options' => array(
			'cacheTable' => 'cache_pagesection',
		)
	)
);

Für die Verwendung von Memcached muss dessen Server natürlich zuerst installiert werden [9].

Eines der Hauptprobleme in Richtung Performance sind Assets, die nachgeladen werden müssen. Hat man davon einige auf der Website, muss jede einzelne vom Server angefordert, dort verarbeitet und zurückgeliefert werden. Hier wäre es gut, die Anzahl der Dateien, die vom Server angefordert werden, auf ein Minimum zu reduzieren. Die Extension „scriptmerger“ [10] macht dies in beeindruckender Weise.

Zunächst werden CSS- und JavaScript-Dateien verkleinert, indem Whitespaces entfernt und Variablennamen gekürzt werden. Dann werden alle auszuliefernden CSS- und JavaScript-Dateien jeweils zu einer einzigen Datei zusammengefasst und anschließend noch komprimiert.

Einige Extensions und auch TYPO3 legen bestimmte Daten wie Style-Anweisungen und JavaScript inline ab – also direkt in den ausgegebenen HTML-Code der Website. Damit wird ein effizientes Caching dieser Dateien verhindert, sodass man diese besser in externe Dateien auslagern sollte.

Dies kann man mit den folgenden beiden Anweisungen im TypoScript-Setup erledigen:

config.inlineStyle2TempFile = 1

Mit der „scriptmerger“-Extension ist es zwar schon möglich, mehrere CSS-Dateien zu einer einzigen zusammenzuführen, es bleiben aber die dort referenzierten Grafiken als eigene Assets, die jeweils separat vom Server angefordert werden müssen. Selbst dies kann erheblich reduziert werden, wenn man alle benötigten Grafiken mit einem Grafikprogramm zu einer einzigen zusammenführt – etwa in einem langen Streifen, bei dem sich untereinander jeweils die benötigten Grafiken befinden. Der Trick besteht nun darin, für jedes Element die passende Eigenschaft „background-position“ zu definieren. Damit wird das Sprite unter dem Element so positioniert, dass die gewünschte Teilgrafik sichtbar wird.

.checkbox {
	background: url(checkboxes.png) no-repeat 0 0;
	height: 25px;
	width: 25px;
}
.checkbox.checked {
	background-position: 0 -40px;
}
.checkbox:focus{
	background-position: 0 -80px;
}

Der Autor

Patrick Lobacher ist Inhaber und Geschäftsführer der Agentur „typofaktum unternehmenskommunikation“ (http://www.typofaktum.de), Autor, Trainer, Programmierer, unterstützendes Mitglied der TYPO3 Association und „Certified TYPO3 Integrator“ und nicht zuletzt ein Digital Native. Er berät seit 1996 Unternehmen beim Einsatz von Webtechnologien, insbesondere seit 2002 zunehmend im TYPO3-Umfeld.