- Tipp 1: UTF-8 nutzen
- Tipp 2: Komprimierung einschalten
- Tipp 3: Permanente Datenbankverbindung
- Tipp 4: Seitenstatistik entfernen
- Tipp 5: Unbenutzte Extensions entfernen
- Tipp 6: Auf Volltextsuche verzichten
- Tipp 7: Extensions deaktivieren
- Tipp 8: Extension „t3p_scalable“ verwenden
- Tipp 9: Reverse-Proxy nutzen
- Tipp 10: Alle HTML-Kommentare entfernen
- Tipp 11: PHP-Beschleuniger verwenden
- Tipp 12: TYPO3-Logging abschalten
- Tipp 13: MySQL tunen
- Tipp 14: Auf _INT-Objekte verzichten
- Tipp 15: User intelligent verwalten
- Tipp 16: Conditions gezielt verwenden
- Tipp 17: Cache-Header erzeugen
- Tipp 18: Statischen File-Cache verwenden
- Tipp 19: Expires-Header nutzen
- Tipp 20: Caching-Framework benutzen
- Tipp 21: Scriptmerger verwenden
- Tipp 22: Inline-Styles und JavaScript auslagern
- Tipp 23: CSS-Sprites verwenden
TYPO3 „Turbo Edition“: 23 Tipps und Tricks für ein schnelleres TYPO3
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 >
Listing 1
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
Listing 2
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>
Listing 3
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', ) ) );
Listing 4
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
Listing 5
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; }
Listing 6
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
Eine sehr gut geschriebene Zusammenfassung. Um sich dieses Material selbst zu suchen, hätte es Stunden gebraucht!
Eine Frage: wenn mir YSlow überall, ausser bei CDN, grüne Häkchen anzeigt,
habe ich dann kein Verbesserungspotential mehr? ;-)
Und was ist von Safaris „Web Inspector“ zu halten?
Hi Lutz,
Danke :-) Schätze da geht echt nicht mehr viel bei Dir *gg* – Web Inspector benutze ich sehr gerne, da es sehr viel übersichtlicher ist – leistungsfähiger ist aber YSlow. Sehr interessant zu diesem Thema ist vielleicht auch noch das Buch „Even faster websites“ aus dem O’Reilly Verlag (hier ein Auszug: http://oreilly.com/server-administration/excerpts/9780596522315/performance-tools.html)
Patrick
Hier eine vollständige Liste wegen den überflüssigen Kommentaren: http://nic3.de/-/typo3-kommentare-entfernen
Wie immer ein Fachman am Werk nur .htaccess scheint in diesem Zusammenhang nicht zu funktionieren. Führt bei mir (Mittwald) zu einem Fehler 500 interneal server error
zu obigem:
es muss heißen locationMatch bei .htaccess
Ist Tipp 15 noch aktuell?
Ich habe diesen Hinweis schön häufiger gesehen, konnte ihn aber praktisch nicht nachvollziehen. Ich habe eine Seite angelegt mit ca. 100 Nutzergruppen, jedoch kein (deutliches) Performanceproblem. In der cf_cache_pages Tabelle gibt es pro Seitenaufruf (nach Cache leeren) einen neuen Eintrag.