Wir hatten diesmal in einem Projekt die Idee, statische Inhalte nicht vom selben Server zu laden, wo auch PHP prozessiert wird. Daher wurde dann ein Cookie-freier, Caching-optimierter Server zur Auslieferung von Statischen Dateien konfiguriert.
Dabei hatten wir uns folgende Vorteile versprochen:
- Alte Browser können Daten schneller laden
- Etwas schnellere Auslieferung der statischen Dateien
- Bessere Leistungsergebnisse unter hoher Last
- Entlastung für den www-Server
- Schnellere Seitenauslieferung von HTML-Dateien
- Schnellere PHP-Prozessierung
Mit der Extension ja_replacer konnten wir die Anforderung in TYPO3 umsetzen:
- Alle Statischen Dateien sollen von static.domain.com ausgeliefert werden
- Sichere Verbindungen müssen berücksichtigt werden
- Statisches Caching muss weiterhin funktionieren
Die Stelle, wo Ja_replacer ansetzt, ist direkt am Output von TYPO3, also kurz bevor ausgeliefert, bzw. in den Cache geschrieben wird. An dieser Stelle können nochmals beliebige Strings gesucht und ersetzt werden. Das Setup wird per TYPOScript gemacht, wir ersetzen in unserem Fall alle Links zu den einschlägigen Verzeichnissen, in welchen sich statische Infos aufhalten:
#Welche Links sollen ersetzt werden? (jeweils mit und ohne Slash am Anfang) config.tx_ja_replacer.search { 10="/typo3temp/ 11="typo3temp/ 12="/fileadmin/ 13="fileadmin/ 14="/typo3conf/ 15="typo3conf/ } #Mit was soll ersetzt werden, wenn im unsicheren Bereich (http) tx_ja_replacer.unsecure = COA tx_ja_replacer.unsecure { 10="http://static.domain.com/typo3temp/ 11="http://static.domain.com/typo3temp/ 12="http://static.domain.com/fileadmin/ 13="http://static.domain.com/fileadmin/ 14="http://static.domain.com/typo3conf/ 15="http://static.domain.com/typo3conf/ } #Mit was soll ersetzt werden, wenn im sicheren Bereich (https) tx_ja_replacer.secure = COA tx_ja_replacer.secure { 10="https://static.domain.com/typo3temp/ 11="https://static.domain.com/typo3temp/ 12="https://static.domain.com/fileadmin/ 13="https://static.domain.com/fileadmin/ 14="https://static.domain.com/typo3conf/ 15="https://static.domain.com/typo3conf/ } #Domain Setup: [globalString = ENV:HTTP_HOST = www.domain.com] #normalfall, wird statisch gecached page.config.baseURL = http://www.domain.com/ config.tx_ja_replacer.replace < tx_ja_replacer.unsecure [global] [globalString = ENV:HTTP_HOST = www.domain.com] && [globalString = _SERVER|HTTPS=on] page.config.baseURL = https://www.domain.com/ config.tx_ja_replacer.replace < tx_ja_replacer.secure [global]
Wenn wir die Leistungsergebnisse gemessen haben, werde ich an dieser Stelle nochmal einen Bericht anfügen.
Cool. Wir haben das auch bei uns im Einsatz. Wir nutzen hierbei die Cloudfront von Amazon. Super wie man dass auch per CNAME auf eine Subdomain mappen kann.
Hi,
super Idee! Das muss ich glatt mal ausprobieren.
Was war der Grund für diese Designentscheidung? Wieviel Traffic ist auf dem Server?
Die Seite ist generell gut besucht, aber jeder Zentimeter Luft nach oben ist ein Schritt in die richtige Richtung.
Und Ihr wisst ja: http://t3n.de/news/seo-google-ranking-site-speed-260247/
Und wie sieht es aus, habt ihr Performancetests gemacht? Denn das „Suchen/ Ersetzen dauert natürlich auch.
Toll wäre es, wenn man in den Core etwas ähnliches wie config.absRefPrefix packen könnte, dass aber nur die entsprechenden Verzeichnisse umschreibt. Und nicht die Links.
Das Suchen/Ersetzen dauert kaum.. wird auch nur einmal vor dem Wegcachen gemacht.
Okay, dann werde ich es mal testen.
Ich setzte CDN auf einigen Seiten ein. Für WordPress gibt es einige PlugIns die es unterstützen, aber die Lösung für TYPO3 funktioniert auch prima.
Coral CDN stellt ein kostenloses CDN zur Verfügung, das brauchbar ist.
Weitere Infos unter:
http://www.webseiten.leicht.info/2010/05/cdn-content-distribution-network-einsetzen/
Scheinbar steht das Plugin ja_replacer im Repository nicht mehr zur Verfügung. Ist das ein Fehler oder gewollt? http://typo3.org/extensions/repository/view/ja_replacer/current/
Wieso, ich sehe es doch noch??
Gut wäre es vielleicht noch per .htaccess-Anweisung zumindest Seiten auf die jeweilig entsprechenden www-Pendants umzuleiten, sodass die Seiten nicht irgendwann zusätzlich über die CDN-Subdomain indiziert werden und damit duplicate content erzeugen.
Hast du dazu einen Vorschlag?
Hm, es handelt sich um statische Inhalte, Grafiken, höchstens PDFs – also Daten, die keine Suchmaschinenbrauchbaren Meta-Daten enthalten.
Der Zugriff über die originäre Domain kann natürlich per htaccess eingeschränkt werden, aber dann kann sein, dass das Backend nicht mehr richtig funktioniert.
Daher wird eine duplicate content Regelung nur mit robots.txt umsetzbar sein. Also für deine Originäre Domain eine robots.txt, wo alle static-files disallowed werden.
Hm, die Umleitung ist vielleicht doch eine gute Idee. Hab aber keinen Code parat
Hallo,
Sehe ich das richtig, dass die gesamte Konfiguration dann auf CloudFront gespiegelt wird /typo3conf/localconf.php und jeder frei zugänglich diesen Ordner aufrufen kann und die Parameter zur Datenbank auslesen kann, wenn er den CRN Link kennt?
Ich probiere gerade aktuell eine Typo3 4.5.25 mit CloudFront im Origin Verfahren einzurichten. Ich habe nur nicht ganz verstanden, diese ja_replacer muss gemacht werden, damit die statischen Inhalte eine neue URL bekommen bei der Auslieferung?
Wie verhält sich der Cache wenn im Typo3 eine Seite verändert wird, eine Grafik ausgetauscht wird, bekommt der Cache das sofort mit?
Vielen Dank für diesen Artikel. Nachdem ich die Extension nun Testweise in einem Projekt eingebunden habe, stellt sich mir aber noch die Frage, wie z.B. der typo3temp-Ordner (TYPO3 Server) mit dem typo3temp-Ordner des CDN synchronisiert wird.
Wenn der CDN auf dem selben Server liegt, geht das sicherlich mittels Symlinks, aber auf einem anderen Server?
Die Fallunterscheidung https/http könnte man doch weglassen, wenn man es so schreibt:
config.tx_ja_replacer.replace {
10=“//static.domain.com/typo3temp/
11=“//static.domain.com/typo3temp/
12=“//static.domain.com/fileadmin/
13=“//static.domain.com/fileadmin/
14=“//static.domain.com/typo3conf/
15=“//static.domain.com/typo3conf/
}
So wird immer das aktuelle Protokoll (http/https) benutzt.
Ich habe das Phänomen, dass die URLs nur ersetzt werden, wenn ich im TYPO3 angemeldet bin und die Webseite im gleichen Browser öffne. Öffne ich die Webseite in einem neuen Browser, so wird nicht ersetzt.
Hat jemand eine Idee?