Smartoptimizer generiert 500er Fehler für robots.txt und sitemap.xml

Hallo Muhi,

Die robots.txt ist keine Datei die Permanent übertragen wird oder werden soll. Diese Datei wird nur von den Sumas abgerufen.

robots.txt durch den SO zu drehen macht keinen Sinn.

Gleiches gilt für die xml. Ich sah dass du Joomla verwendest.
Die xml Dateien in Joomla sind für die Konfiguration des Systems an sich zuständig. Die Xml\'s werden nicht an den Clientrechner übertragen.

XML muss nicht durch den SO.

Man kann sich auch den Aufwand mit dem Smartoptimizer sparen und führt einfach die css/js Dateien zusammen. Erstellt Sprites und schon ist Joomla 3 Nummern flotter...

Hallo Romacron

Danke für deine Erklärung.

robots.txt und sitemap.xml ist statisch und sollte nur gelegentlich abgerufen werden.

Smartoptimizer ist in sekundenschnelle eingerichtet und funktionsbereit. Erst im nachhinein hab ich bemerkt, dass die robots.txt nicht ausgelesen wird von den Suchmaschinen.

Das Verhältniss zu Aufwand und Ertrag rechtfertigt den Einsatz von Smartoptimizer. Bei der seite deluxe-it.ch war eine besserung von Faktor 7 messbar.

Gruss
Muhi

Der Smartoptimizer greift auf mod_php zu, was der Hostingprovider nicht unterstützt, was er auch in ferner Zukunft nicht unterstützen wird. Interssant wird es wenn es viele Template für Joomla gibt die darauf zugreifen. Joomlaart hat solche Templates und andere ziehen mit.

*Der Smartoptimizer greift auf mod_php zu, was der Hostingprovider nicht unterstützt*

Dein Hoster macht es richtig. Im laufenden Betrieb mit vielen verschiedenen Webseiten ist cgi/fcgi pflicht. Es macht sich ganz gut, wenn Rechte gekapselt und abgeschirmt sind.

Bei mod_php gibt es nur eine php.ini im /etc/apache... Das ist für viele Nutzer die Ihr Php konfigurieren wollen nicht tragbar.

*Interssant wird es wenn es viele Template für Joomla gibt die darauf zugreifen.*
Wie meinst du das?

Der Ansatz, dass der SO wichtig oder gar pflicht ist teile ich nicht. Ordentlich programmieren oder aufsetzen ist schon die halbe Miete.

Ich benutze nun JCH Optimize. Bei meinem Hostingprovider kann man sich php.ini\'s in Verschiedenen Versionen anlegen.

Yootheme, JoomlaArt und weitere namhafte Template Hersteller nutzen/bieten diese Möglichkeiten in ihren Templates bereits an. Ich meine nicht, dass es Pflicht ist.

Gruss

ich meine, dass hier grundlegend was schief läuft!

1. Joomla ist ohne diverse Memory- und Cache-Hilfen ohne mit der Wimper zu zucken fix ohne Ende.
Es sei denn man...
Man misshandelt sein Joomla mit 50 Plugins und 20 Modulen die permanent im Einsatz sind.

Hast du schon einmal den Profiler drübergescheucht.
vielleicht hast du auch hier eine url parat, es würde mich brennend interessieren warum man da mit der Brechstange ran muss.

Hallo romacron

Wenn ich Joomla 1.6 mit JA Purity II installiere habe ich, wenn ich mich nicht täusche eine Lade grösse von ca. 500KB und um die 50 HTTP Request. Ca.30 Request gehen dabei auf Bilder und die restlichen auf CSS und JS. Ich habe noch keine Module aktiviert und auch keine PlugIns.

Ganz schlimm sind die Templates von einem hersteller der hat in der Grundkonfiguration über 100+ http Requests. Wieso brechstange? Ich denke nicht, dass es falsch ist, die Werte runterzubrechen.

Gruss
M

muhi schrieb:
Wenn ich Joomla 1.6 mit JA Purity II installiere habe ich, wenn ich mich nicht täusche eine Lade grösse von ca. 500KB und um die 50 HTTP Request. Ca.30 Request gehen dabei auf Bilder und die restlichen auf CSS und JS.

Hi muhi,

500kb sind jetzt nicht so viel und die ganzen Grafiken, CSS und JS Daten lassen sich wunderbar Cachen. Auch der Joonla interne Cache ist ziemlich flott. Von Daher machst du irgendetwas falsch.

Gib uns doch mal einen Link zu der Seite?

Schöne Grüße
Thomas

Der Link steht im ersten Beitrag von mir (www.deluxe-it.ch). Hier werden 127KB geladen und es sind 33 Requests nötig um die Seite zu laden.

Jungs es geht mir nicht nur um eine Seite, es geht mir um allgemein darum HTTP Requests und Traffic zu minimieren. Da ist die Ausgangslage nun mal bei jedem Template und bei jedem Hostingprovider anders.

Requests minimieren.

1. Webseite erstellen.
2. Testen
3. Sprites aus den wiederkehrenden grafiken erstellen
4. Relaunch der Css damit das Sprite greift.
5. Sauber programmierte Komponent haben im /views/tmpl/default.php in der Regel eine Componenten css oder Javascript eingebaut.
5.1. Template-Override erstellen, besagte Komponenten CSS und Js entfernen
6. Zusammenführen der css und js Dateien.

7. 33% - 50% Requests gespart.

Nun kann es sicher nachvollziehbarer sein, warum dein bestreben nicht das erfüllen wird, was es eigentlich sollte.

Requestst da minimieren wo sie auftreten!!