Optimierung von Ladezeiten (Basics)

[jan.theofel]

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:

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:

Details: Sparen Sie bis zu 4,86 KB, 1 Anfragen, 1 DNS-Lookups.

1. gzip-Komprimierung aktivieren
Die Komprimierung der folgenden Ressourcen mit gzip könnte ihre Übertragungsgröße um 4,86 KB reduzieren:

* http://www.tac-stuttgart.de/ (3,67 KB)
* http://www.tac-stuttgart.de/basic.css (862 Byte)
* http://www.tac-stuttgart.de/layout.css (361 Byte)

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.

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.

3. Externe CSS kombinieren
2 CSS-Dateien werden von www.tac-stuttgart.de bereitgestellt. Sie sollten in so wenig Dateien wie möglich zusammengefasst werden:

* http://www.tac-stuttgart.de/basic.css
* http://www.tac-stuttgart.de/layout.css

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.

Page Speed Score: 77/100
Moderate performance improvements are possible

Ah, so schlecht sind wir also gar nicht. Juhu. :-)

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:

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

Non-scoring information
The following resources are explicitly non-cacheable. Consider making them cacheable if possible:

* http://www.google-analytics.com/__ut....tac-stuttgart....
* http://www.tac-stuttgart.de/cron.php

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.

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.

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.

Defer loading of JavaScript
100% of the JavaScript loaded by this page had not been invoked by the time the onload handler completed.

http://www.tac-stuttgart.de/plugins/...ls/mootools.js 599 functions uncalled of 599 total functions.
...

Hier folgen Tonnenweise JS-Anweisungen, die ungenutzt sind. Auch hier gilt wieder: mootools udn slimbox abschalten, wenn diese nicht genutzt werden.

Minify CSS
Minifying the following CSS resources could reduce their size by 117B (2% reduction).

Minifying http://www.tac-stuttgart.de/system/typolight.css could save 64B (9% reduction). See optimized version or Save as.
Minifying http://www.tac-stuttgart.de/basic.css could save 25B (1% reduction). See optimized version or Save as.
Minifying http://www.tac-stuttgart.de/layout.css could save 25B (3% reduction). See optimized version or Save as.
Minifying http://www.tac-stuttgart.de/plugins/...ss/slimbox.css could save 3B (0% reduction). See optimized version or Save as.

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.

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.

Minify JavaScript
There is 119kB worth of JavaScript. Minifying could save 990 bytes (0.8% reduction).

Minifying http://www.tac-stuttgart.de/plugins/...ls/mootools.js using JSMin could save 808 bytes (0.9% reduction). See minified version.
Minifying http://www.tac-stuttgart.de/plugins/.../js/slimbox.js using JSMin could save 145 bytes (3.5% reduction). See minified version.
Minifying http://www.google-analytics.com/ga.js using JSMin could save 37 bytes (0.2% reduction). See minified version.

Die mitgelieferten JS sind schon ganz gut optimiert. Bei eigenem JS Code kann man da ggf. noch was rausholen.

Optimize images
Optimizing the following image resources could reduce their size by 7.6KiB (18% reduction).

Optimizing http://www.tac-stuttgart.de/tl_files...karte-hand.jpg could save 7.6KiB (18% reduction). See optimized version or Save as.

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.

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.

Remove unused CSS
15.5% of CSS (estimated 646 bytes of 4.1kB) is not used by the current page.

http://www.tac-stuttgart.de/system/typolight.css: 167 bytes of 669 bytes is not used by the current page.

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.

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.

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:

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

[xchs]

Da mir dieses Thema auch sehr am Herzen liegt und ich auch schon an anderer Stelle darauf hingewiesen hatte, hier einige Ergänzungen meinerseits:

Ich habe in meinem Firebug zusätzlich zum Add-on "Page Speed" auch noch das von Yahoo bereitgestellte "YSlow" installiert; es prüft - ähnlich wie "Page Speed" auch - diverse geschwindigkeitsrelevante "Performance Rules". Damit hat man dann einen direkten Vergleich, an welchen Schrauben man drehen kann/soll, um Ladezeiten bzw. Overall-Performance einer Webseite möglichst gut zu optimieren.

Wer sich etwas detaillierter in dieses Thema einlesen möchte, kann sich z.B. einige dieser Seiten ansehen:

Best Practices for Speeding Up Your Web Site
14 Rules for Faster-Loading Web Sites
Website Performance: What To Know and What You Can Do

Ergänzend noch zum Thema (Apache-) Caching:
Speed Up Sites with htaccess Caching

Um auch längere Cache-Zeiten möglich zu machen, wäre es aus meiner Sicht durchaus auch ganz hilfreich oder sinnvoll, wenn TYPOlight für diverse Ressourcen (JS, CSS, Bilder, usw.) auch ein geeignetes "Versioning" vorsehen würde. In diesem Zusammenhang auch der Hinweis auf diesen Feature Request.

Relevant ist aus meiner Sicht auch das Thema "HTTP Requests" bzw. "Combining von Ressourcen"; hier ein Thread, der sich bereits mit dieser Thematik beschäftigt.

Nachfolgend auch einige interessante Ansätze bzw. Vorschläge wie Browserhersteller zukünftig dieser Problematik begegnen könnten:

Making browsers faster: Resource Packages
Fewer requests through resource packages


@Jan: Deine oben zitierte "Private Seite" - Läuft die wirklich schon unter TL 2.8.2? Laut Quelltext/Template hätte ich jetzt eher auf eine etwas ältere Version getippt...

[FloB]

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.

Hier hatte ich die Idee "virtuelle" Stylesheets im Generator zu ermöglichen, oder die Möglichkeit zu geben andere Stylesheets in eines einzubinden (per CheckboxWizard, um die Reihenfolge ändern zu können). Optimalerweise sollten dabei noch gleiche Selektoren oder sogar verschiedene Elemente mit den gleichen Eigenschaften zusammengefasst werden.

Die virtuellen bzw. zusammengesetzten Stylesheets könnte man schnell umsetzen, ohne großartige Änderungen durchführen zu müssen – selbst beim Generator gilt es (für die Basisvariante) nur wenige Codezeilen hinzuzufügen. In den Seitenlayouts muss dafür gar nichts geändert werden.

Was haltet ihr davon?

[mdoll]

Hallo,

ich wollte zu diesem Thema mal auf folgenden Blogbeitrag bei Peter Kröner hinweisen:
http://www.peterkroener.de/der-css-j...eschleunigung/

Gruß
Mathias

[Sebastian]

HI

In den Einstellungen kann man übrigens auch die Gzip-Komprimierung für die gesendeten HTML-Inhalte aktivieren.

Sebastian