Im Typo3-Backend ab Version 4.3 sind viele alte und neue Funktionen in "erweitertem" Javascript realisiert. Damit werden höhere Anforderungen an die verwendeten Gerätschaften und Softwarekomponeneten gestellt, heißt es von den Core-Entwicklern.

Wie weit das notwendig oder sinnvoll ist, ist hier nicht Teil der Betrachtung. Das Backend geht mit der bislang benutzen Konfiguration definitv langsamer. Das fällt den Kunden negativ auf, die ihre Webs und Seiten selbst pflegen wollen und können müssen.

Leider haben in den letzten Diskussionen in der Typo3 Liste einige Teilnehmer nicht realisiert, daß die Kunden sich so gut wie gar nicht auf Diskussionen einlassen und einfach den Anbieter oder das Produkt wechseln. Das Hauptargument ist, es hatte ja bislang super funktioniert. Das Vernebeln dieser Kundensicht ist gefährlich.

Wenn überhaupt, können wir auf unseren Servern eingreifen !!! Die Frage ist : wie ?

Grundsätzlich sollte man den Empfehlungen der Macher (Entwickler) erst mal Glauben schenken. Dazu gehört, daß das Typo3 interne Chaching benutzt wird. Es gibt im Installtool ein Feld zum generellen (unabänderbaren) Einschalten des MYSQL Chachings ohne Ausnahme. Wenn das aus irgendeinem Grund mal irgendwo abgeschaltet wurde, nudelt sich der Server tot. (Also im Install-Tool [FE][disableNoCacheParameter] = 1 setzen, dann ist Ruhe).

Das hat aber den großen Nachteil, daß die TYPO3 Standard Suche nicht mehr geht. Und diese Suche ist essentiell für seriöses Vergleichen von Suchergebnissen mit anderen SuchAlgorythmen.

Ich habe also in der  /typo3conf/"localconf.php" die Variable wieder auf 0 gesetzt. [FE][disableNoCacheParameter] = 0

Bei uns gibt es zwei Tools, die bei der Diagnose sehr hilfreich sind. Im SSH putty Fenster läuft das Linux-Programm "htop" und zeigt mir die Speicher- und CPU- Auslastung an (sehr ähnlich dem Taskmanager unter Windows). Auf einer anderen Station bewachen wir mit dem STG den aktuellen Traffic eines jeden Servers. Beides zusammen zeigt recht genau, ob die Menge der Requests oder eine interne Funktion die CPUs nur beschäftigt oder sogar auslastet.

Die Programme werden offensichtlich immer größer, die Menge des geschriebenen HTML- und Javascript-Codes wird größer. Von Vorteil ist natürlich, daß in diesem modularen CM-System viele Teile öfter verwendet werden. Man könnte sie also lokal vorhalten - sprich cachen. Darum hier eine Betrachtung, welche Cache-Möglichkeiten verfügbar sind und wo die Vor- und Nachteile liegen. (mal ein Blick hierauf werfen - kaioa.com/node/74 - ist aber aus 2008)

Sowohl Linux als auch Windows Server cachen abgerufene ausgehende Dateien und damit auch Webseiten (samt zugehöriger css und JS Dateien), solange genügend RAM übrig bzw. verfügbar ist. Das ist nicht immer glücklich, weil Änderungen insbesondere in einer Datenbank erst erkannt werden, wenn die neue HTML-Ausgangs-Datei anders ist als die gecachte. Das Cachen vom Betriebssystem ist also für flexible Inhalte unbrauchbar.

Auch der Apache kann grundsätzlich zum Cachen benutzt werden. Hier ist fast das gleiche Problem wie bei dem OS-Caching, er sieht in seinem Cache nur die Datei und deren Verfallsdatum. Den veränderten Inhalt sieht der Apache nur, wenn er die Datei bereits erneut geladen hat. Das sollte ja vermieden werden. Dennoch wird immer wieder Traffic vom Server verursacht. Es gibt da aber ein paar andere Möglichkeiten, mit Apache Funktionen das Browser-Caching zu beeinflussen.

TYPO3 cached einmal abgerufene dynamische (Front-End-) HTML- "Inhalte" (und auch nur diese !!) in seinen MYSQL cache_xxxxx Tabellen und hält dort die fertige HTML-Seite (also ohne die Bilder) solange vorrätig, wie der Admin die Verfallszeit eingestellt hat. Hat der Admin/Redakteur eine Änderung in der Datenbank bereits vor diesem Ablauftermin vorgenommen, muß er explizit von Hand den Cache mindestens dieser einen Seite löschen. Sonst liefert TYPO3 weiterhin die alte Seite bis zum Ablaufdatum aus.

Kontakariert wird dieses Caching-System der optimalen Aktualität, wenn der Browser diese Seite (z.B. über ein mehrtägiges Ablaufdatum oder seinen Default) bereits vorher gecached hat und damit immer noch seine lokale Variante anzeigt.

Laut der Empfehlungen der RCFs werden seit etwa 1992 im Cache-Control Header einer HTML Seite die "max-age directive" für HTTP/1.1) abgefragt und gespeichert. So gut wie alle Browser ab 2001 (sogar der IE6 !!) halten sich an diese Regelung, sagt die Wikipedia. Um den Webtraffic bei wiederholten Aufrufen der gleichen Seite jetzt zu optimieren, kann man dieses Caching einschalten (bzw. nicht abschalten).

Da aber in den Jahren seit 2000 immer mehr Websites "on Click" dynamisch neu aufgebaut werden, kommt es bei ein- und demselben Benutzer kaum noch vor, daß er eine Seite mit gleichem Inhalt nochmal aufruft, es sei denn irrtümlich. Blogs und Newsletter von Onlinezeitungen sind typische Beispiele - gleicher Link = gleicher Dateiname und im Minutentakt kommen neue Inhalte. Wird diese Seite also gecached, bekommt der Benutzer die alten Inhalte (von der lokalen Platte).

Bei Typo3 Sites, bei denen sich solche Informationen in sehr kurzen Inkrementen ändern, wird also der Admin/Redakteur diese Verfallszeit, die für den Browser gedacht ist, für eine oder für alle Seiten per "Expires Header" auf wenige Minuten setzen oder gar auf 0 stellen.

Ein Weg für unser Problem wäre, das Caching für FE und BE Seiten unterschiedlich zu handhaben, also die html "expiration time" gezielt festzulegen. Zumindest für meine Websites bekommt der Besucher immer die aktuelle Seite aus dem Typo3 Cache, dessen jeweilige Aktualität ich selbst per "Seitencache löschen" bestimme. Die Typo3 interne Cache Einstellung bei den Seiteneigenschaften verbleibt auf default/standard.

Im Backend wäre das anders. Dort sollte die "expiration time" auf mehrere Tage gesetzt werden können. Für weitgehend unveränderliche rte-, css- oder js- Module wäre das beschleunigend.

Schalten wir also unser Caching wieder ein, so ist der Cache (pro einzelnem Browser) nach 1 Stunde googeln randvoll mit Müll ohne Ende. Das Aufteilen in mehrere Fenster bringt gar nichts und 2 verschiedene Firefoxe sind sehr sehr mühsam zu installieren. Also müssen alle verfügbaren Browser-Hersteller herhalten, NS, FF, IE, OP. Den "Lock und Köder-) Browser von Google lassen wir bewußt erst mal aussen vor.

Problem:  Nicht jeder Browser ist noch Typo3 4.4.6 Backend geeignet.

• 1.) Der alte Nescape 9 hat Probleme mit dem neuen "extended"- Javascript - geht aber bis 4.2.17 super.
• 2.) Der Opera 11 hat mit allen Typo3 Versionen Probleme mit skalierbaren Fenstern und der TAB-Taste in Editoren.
• 3.) Den Firefox 3.6 brauchen wir zum Kontrollieren der gefüllten Seiten, denn der ist draußen bei den Besuchern neben dem IE6 !!! und em IE7 der 2. Welt-Standard.
• 4.) Bleibt zum Entwickeln noch der überall verteufelte IE8, den man doch möglichst nicht benutzen soll.
• 5.) Dem Chrome traue ich nicht über den Weg, Google hat Ziele.

Und damit kollidieren die Inkompatibilitäten der verfügbaren Browser.

Mit etwas mehr Aufwand kann man in der localconf.php und in der .htaccess zum Ersten die Kompression der css und js Dateien einschalten bzw. erhöhen.

$TYPO3_CONF_VARS['BE']['compressionLevel'] = '9';

Dazu kann man den expired header modifizieren:

<FilesMatch "\.(js|css)(\.gzip)?$">
        <IfModule mod_expires.c>
                ExpiresActive on
                ExpiresDefault "access plus 1 month"
        </IfModule>

        # ETag
        FileETag MTime Size
        <IfModule mod_headers.c>
                FileETag none
                Header unset Last-Modified
        </IfModule>
</FilesMatch>

Ich werde das mal in der 4.4.6 ausprobieren. Bislang hatte ich noch nicht herausgefunden, welcher Browser auf die mit einem Verfalls-Zeitstempel im Dateinamen ergänzten (Nicht-HTML-) Files wirklich reagiert.
-

Die von einigen besonders "schlauen" Leuten empfohlene prinzipelle Aktivierung von 50MB Cache im Browser scheint mir das Problem weder hinreichend noch sinnvoll zu lösen, eher im Gegenteil.

Ich habe PCs bereinigt, bei denen im Cacheverzeichnis über 40.000 Dateien drinnen waren, die der Browser bei jedem Klick über mehrere Sekunden durchgesucht hatte. Abgesehen davon, daß das etwa 400 MB waren, bekamen die Nutzer immer irgendwelchen alten Schmodder vorgesetzt.


Das kann in den Zeiten von bezahlbarem DSL 6.000 / 16.000 nicht mehr die Lösung sein. Da müssen bessere Konzepte her. Aus meiner Sicht sind und waren alle Browser Caches nur Workarounds für langsamen Datenzugriff über Modems.

-