Optimierung von Ladezeiten (Basics)
Hi,
basierend auf dem Suchmaschinenoptimierungsthread möchte ich daraus etwas sinnvolles ableiten und mal in einem Überblick erörtern, wie man Ladezeiten von TYPOlight-Webseiten optimieren kann.
Das hilft zum einen bei SEO (für alle die es nicht mitbekommen haben: Seitenladezeiten ist eines von vielen Rankingkriterien in Suchmaschinen) zum anderen kommt es faktisch den Besuchern eurer Webseite entgegen. Man schlägt also zwei Fliegen mit einer Klappen.
Freundlicherweise stellt uns Google zwei Hilfsmittel zur Verfügung: Die Google Webmaster Tools (nur für den Seitenbetreiber nutzbar) und das page speed Plugin für Firefox.
Als Beispieldomain nehme ich mal eine private Seite von mir. Die läuft mit TYPOlight 2.8.2, einigen Modulen und ist in keiner Weise besonders optimiert. (Wozu auch bei dem speziellen Thema?)
In den Google Webmaster Tools finden sich unter "Google Labs" und "Website Leistung" ein paar grundlegende Informationen:
Zitat:
Leistungsübersicht
Im Durchschnitt benötigen Seiten auf Ihrer Website 0,6 Sekunden zum Laden (aktualisiert am 14.04.2010). Dies ist schneller als 97 % der Websites.
Gefolgt von dem Hinweis, dass einige Sachen durch den Google Bot anderes gesehen werden können als sie in der Realität sind, werden mir folgende Vorschläge gemacht, die eigentlich für alle Seiten identisch sind. Sie lauten wie folgt:
Hier nimmt einem TYPOlight in der Standardinstallation schon Optimierung ab. Normalerweise wird in der .htaccess definiert, dass css und js Dateien vom Server komprimiert übertragen werden. Vorausgesetzt diese sind vorhanden und der Client weiß damit etwas anzufangen. Wenn man sich einen kleinen Hilfsjob einrichtet, der alle Dateien mit gzip komprimiert profitiert man davon. Problem: Den muss man manuell nach jeder CSS-/JS-Anpassung durchführen.
Optimierungsmöglichkeit: Der TYPOlight Core könnte die gz-Versionen der CSS-Dateien beim Erzeugen direkt mit schreiben. Bei JS wird es etwas schwiriger weil das der Core ja nicht erzeugt sondern von Modulen definiert wird.
Nur für die Seite selbst bestünde in einer normalen Installation noch zusätzliche Handlungsbedarf. Man könnte auch die noch komprimieren.
Zitat:
2. DNS-Lookups minimieren
Die Domains der folgenden URLs stellen nur jeweils eine Ressource bereit. Vermeiden Sie falls möglich zusätzliche DNS-Lookups durch die Bereitstellung dieser Ressourcen von bereits bestehenden Domains:
*
http://www.google-analytics.com/ga.js
Interessant, dass Google hier die eigenen Tools anmeckert. (Ja ich weiß um den Datenschutz und so weiter und so fort. Das brauchen wir hier nicht disskutieren.)
Mögliche Optimierung: Lokales Trackingtool nutzen. Nachteil: Zusätzliche Serverlast und meistens nicht so umfangreich wie Google Analytics.
Hier wäre wieder der TYPOlight Core gefragt. es ist hier hilfreich CSS zu trennen, damit die aus basic im Editor angezeigt werden, die anderen jedoch diesen nicht belasten. Ggf. könnten die Datein auf Serverseite gemerged und so gecacht werden und dann ausgeliefert. So viele CSS-Dateien und Kombinationen hat man in der Regel ja nicht.
So und jetzt wird es lang. Hier kommt die Ausgabe des Plugins mit Kommentaren. Ich versuche das soweit wie möglich zu kürzen ohne den Sinn zu entstellen und dabei darauf einzugehen, was man daraus in TYPOlight noch optimieren kann.
Zitat:
Page Speed Score: 77/100
Moderate performance improvements are possible
Ah, so schlecht sind wir also gar nicht. Juhu. :-)
Zitat:
Leverage browser caching
The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached:
http://www.tac-stuttgart.de/basic.css
...
The following cacheable resources have a short freshness lifetime. Specify an expiration at least one month in the future for the following resources:
*
http://www.google-analytics.com/ga.js
Das ist vor allem ein Thema für den Webserver. Für die Seiten selbst könnt ihr in der Seitenstruktur Caching ein-/ausschalten und eine Cache-Zeit festlegen. Für übliche Seiten könnt ihr da sicherlich eine Stunde oder mehr setzen - abhängig davon wie oft sich eure Seite ändert. Das greif aber nur für die HTML-Seite, nicht für Bilder, CSS und JS.
Im Apache könnt ihr das beispielsweise so konfigurieren:
Code:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 300 minutes"
ExpiresByType image/jpeg "access plus 300 minutes"
ExpiresByType image/png "access plus 300 minutes"
ExpiresByType text/css "access plus 30 minutes"
ExpiresByType text/javascript "access plus 30 minutes"
</IfModule>
Bei Bildern setzt ihr die Cache-Zeit so auf 5 Stunden (ändern sich doch eher selten), bei CSS und JS sind öfters Änderungen zu erwarten, also setzen wir nur eine halbe Stunde Cache-Zeit.
Wer das alles hat kann noch Feintuning betreiben und keine gleiche Inhalte unter verschiedenen URLs vorzuhalten. Das gilt vor allem für die Startseite, die meisten mit "http://www.doain.tld", "http://www.doain.tld/index.php" und "http://www.doain.tld/alias" abrufbar ist. Sorgt z.B. mit der googlesitemap-Erweiterung, dass alle Links immer auf die / Variante zeigen. Dann cacht der Broswer nicht mehrere Versionen des gleichen Inhalts.
Um den ersten Punkt kommen wir nicht drum rum. Aber die cron.php kann man sich schenken, wenn man den Cron als echten Cronjob laufen lässt und nicht über den Poor-Mans-Cron in der Seite integriert hat. Ein Hoster der echtes Cron für seine Kunden anbietet, ist hier klar von Vorteil.
Zitat:
Combine external CSS
...
Enable compression
...
Combine external JavaScript
...
Hatten wir schon in den Webmaster Tools. Außer, dass hier noch die system/typolight.css und plugins/slimbox/css/slimbox.css mit geladen werden.
Bei der Kompression tauchen hier dann auch mehr Dateien auf, vor allem die mootools.js und slimbox.js.
Regel: mootools und slimbox abschalten wenn diese nicht genutzt werden.
Zitat:
Leverage proxy caching
Due to a bug in some proxy caching servers, the following publicly cacheable, compressible resources should use "Cache-Control: private" or "Vary: Accept-Encoding":
http://www.tac-stuttgart.de/basic.css
...
Nochmal ein Cachingthema.
Hier folgen Tonnenweise JS-Anweisungen, die ungenutzt sind. Auch hier gilt wieder: mootools udn slimbox abschalten, wenn diese nicht genutzt werden.
Hier hängen die Auswertungen und Potentiale natürlich stark von eurem CSS-Code ab. Versucht den so optimal wie möglich zu gestalten. Die System CSS sind so ziemlich frei von unnötigen CSS-Anweisungen und meine auch.
Zitat:
Minify HTML
Minifying the following HTML resources could reduce their size by 913B (14% reduction).
* Minifying
http://www.tac-stuttgart.de/ could save 913B (14% reduction). See optimized version or Save as.
Ok, das Framework bringt es mit sich, dass wir unnötigen HTML-Ballast mit uns rumschleppen. Man könnte den einen oder anderen Optimierungspunkt im Core finden, aber die werden nicht viel ausmachen.
Wer auf High-End-Optimierung geht, kommt hier an eigenen Templates, die auf ein Minimum reduziert sind, wohl nicht vorbei.
Die mitgelieferten JS sind schon ganz gut optimiert. Bei eigenem JS Code kann man da ggf. noch was rausholen.
Auch hier hängt das Ergebnis stark von eurem Bildmaterial ab. Generell ist empfehlenswerte die Bilderzahl zu verringern und mehr Effekte mit CSS abzubilden. Das ist meistens kleiner und erzeugt keinen zusätzlichen Request beim Server.
Zitat:
Serve scaled images
The following images are resized in HTML or CSS. Serving scaled images could save 43B (100% reduction).
http://www.tac-stuttgart.de/cron.php is resized in HTML or CSS from 1x1 to 0x0. Serving a scaled image could save 43B (100% reduction).
Hier könnte man den Core so anpassen, dass er den cron.php tatsächlich an unbedeutender Stelle als 1x1 Pixel ausliefert. Das sollte in den meisten Layouts nicht stören.
Besser wäre es jedoch den "echten" Cron zu verwenden und den Aufruf ganz aus dem Template zu verbannen. Aber das hatten wir ja schon mal.
Es folgen überflüssiuge weil ungenutzte CSS-Anweisungen. Werden diese auf keiner Seite benötigt, kann man sie aus dem CSS entfernen. Dazu sind aber immer alle Seiten durchzutesten bzw, zu kennen.
Zitat:
Serve static content from a cookieless domain
Serve the following static resources from a domain that doesn't set cookies:
...
Cookies möglichst zu vermeiden ist einleuchtend. An einigen Stellen, wie etwa beim Mitgliederlogin kommt man aber nicht drum herum. Die Alternative sind Session-URLs in der URL, die sicher auch keiner haben will.
Zitat:
Use efficient CSS selectors
http://www.tac-stuttgart.de/plugins/...ss/slimbox.css has 0 very inefficient rules, 0 inefficient rules, and 2 potentially inefficient uses of :hover out of 13 total rules.
Rules that use the :hover pseudo-selector on non-anchor elements. This can cause performance problems in Internet Explorer versions 7 and 8 when a strict doctype is used.
* #lbPrevLink:hover
* #lbNextLink:hover
http://www.tac-stuttgart.de/layout.css has 0 very inefficient rules, 1 inefficient rules, and 0 potentially inefficient uses of :hover out of 11 total rules.
Inefficient rules (good to fix on interactive pages):
* #headline .headlink a Tag key with 2 descendant selectors
Das hängt wieder stark von eurem CSS-Code ab. Schaut, was das Plugin bei euch ausspuckt und optimiert das bei Bedarf.
Die restlichen Punkte haben im Beispiel keine weitere Optimierungsvorschläge und Erläuterungen. Der Vollständigkeit halber:
Zitat:
Avoid bad requests
Minimize DNS lookups
Minimize redirects
Minimize request size
Optimize the order of styles and scripts
Put CSS in the document head
Serve resources from a consistent URL
Specify a character set early
Specify image dimensions
Avoid CSS expressions
Parallelize downloads across hostnames
Ihr seht also, dass es ein mächtiges Tool ist, bei dem ihr einiges an Optimierungspotential herausfinden könnt, der individuell pro Seite ist.
Generell mitnehmen solltet ihr:
- Echten Cronjob statt cron.php verwenden.
- mootools und slimbox nur dann einbinden, wenn ihr sie braucht.
- Möglichst wenig CSS Code in möglichst wenigen CSS Dateien
- Möglichst kleine (Dateigröße!) Bilder verwenden
Im Core sehe ich vor allem Potential in Hinblick auf Kombination von mehreren CSS-Datei und JS-Dateien. Wie man das ideal umsetzt könnte man sich mal überlegen.
Weitere Hinweise sind gerne willkommen, so dass ich daraus mal ein Übersichtliches Tutorial zusammenstellen kann.
Jan
