Bitte um Rat bzgl. sehr schlechter Ladezeit

[SloMo]

Ich wollte lediglich wissen, ob es auch an der Server-Hardware liegen könnte und ob man durch Maßnahmen, z.B. mehr RAM oder was immer ihr mir auf diese Frage vorgeschlagen hättet, die Geschwindigkeit des Servers noch steigern könnte.
Entschuldigt diese naive Vorstellung.
Noch eine Frage zum Joomla! internen Cache. Dieser ist derzeit nicht aktiviert. Soll ich den auch aktivieren? Wenn ja, auf welche Zeit könnte man den für diese Seite einstellen?

Über das Joomla-Caching solltest Du Dich lieber in einer Joomla-Community und der Joomla-Doku informieren. Wie lange Du cacht, hängt maßgeblich davon ab, in welcher Frequenz neuer Content kommt und welche Cache-Ebenen es gibt.

Die Hardware würde ich zuletzt anpacken. Ob es Speicher- oder Performance-Engpässe gibt, kann Dein Server-Admin feststellen. Gerade bei Performance-Engpässen hilft auch gezieltes Caching, z.B. Opcode-Caches. Nachdem das Problem mit den großen Grafiken abgestellt ist, könntest Du Dir https://en.wikipedia.org/wiki/List_of_PHP_accelerators ansehen.

[Synonym]

Also am Server würde ich erst mal gar nichts machen. Wenn, dann nach den anderen Dingen. Wichtig sind erst einmal die Bilder, die den ganzen Traffic verursachen. Dann kann man sich die JS und CSS auch ansehen, ob das denn so viele sein müssen oder ob da nicht ein paar überflüssig sind. Erst wenn das alles gemacht ist, dann würde ich den Server angehen.

Alles andere wäre wie bei einem Auto den Motor zu tunen, aber keinen Luft im Reifen zu haben.

[Mr. T]

Die Hardware würde ich zuletzt anpacken. [...] Wichtig sind erst einmal die Bilder, die den ganzen Traffic verursachen.

Ok, dann geb ich das so weiter und schaue mal, was man bzgl. der Bilder machen kann. Entweder wird es das empfohlene Plugin oder ich muss selber mal sehen.

Dann kann man sich die JS und CSS auch ansehen, ob das denn so viele sein müssen oder ob da nicht ein paar überflüssig sind.

Wie gesagt, ein Teil davon wird von Modulen, Plugins und Komponenten verwendet, die nicht von mir sind. Bei denen habe ich nur die Scripte mit YUI eingestampft, sofern das nötig war. Bei den eigenen Stylesheets und JS habe ich sowohl eingestampft als auch die Taktik verfolgt, nur die vom View benötigten Scripte und Stylesheets zu laden. Mir ist nämlich auch nicht klar, ob es der Performance zuträglicher ist, alles in einem RIESEN Stylesheet bzw. RIESEN JS abzulegen, dass nur einmal übertragen wird. Das wäre zumindest für den Programmierer extrem besch....., da mehrere Tausend Zeilen Code zu verwalten wären. Ich hatte schon die Vorstellung, per Plugin alles CSS und JS zur Renderzeit zumergen, ehe sie ausgeliefert werden, diesen Gedanken aber schnell wieder verworfen, da die Aufrufe der einzelnen Dateien ja über die versch. Erweiterungen verteilt sind. Den Stress muss ich mir nicht geben.

Das Design wurde outgesourced, oder?

Ja, das Design ist von der Agentur, die die Programmierung an mich übertragen hat. Daher kann ich von deren Seite keine programmiertechnische Unterstützung erwarten. Auch mit Joomla! haben sie keinerlei Erfahrung. Zwar haben die den Server angemietet, doch jede Frage bezüglich Joomla! und programmiertechnischer Art wird an mich durchgereicht. Ich kenne mich mit dem Thema Caching wirklich noch nicht aus und bin dankbar für jede Hilfe von erfahreneren Programmierern und Administratoren.

[Pompom]

- Caching ist super
- gzip ist auch super
Aber:
Du musst einfach deinen Content kleiner machen, d.h. die Bilder usw. verkleinern, da führt kein Weg vorbei.

Denn auch mit Caching dauert bei 28 MByte das erste Laden der Seite mit DSL 2.000 ca. 3 Minuten, mit ISDN 90 Minuten.

Dein Server ist in der Lage, Daten schnell zu handeln und auszuliefern - der Engpass ist einfach die enge Leitung zum User, da kannst du den Server aufrüsten wie du möchtest - ändert am Problem nichts.

[Medium]

und dich mal für ein framework entscheiden du bindest jquery und mootools ein daher kommen auch die ganzen JS Fehler - so kannst du deine JS Dateien auch nicht zusammenfassen und komprimieren

[SloMo]

Denn auch mit Caching dauert bei 28 MByte das erste Laden der Seite mit DSL 2.000 ca. 3 Minuten, mit ISDN 90 Minuten.

Du meinst die Cache-Optionen vom HTTP. Damit er die Bilder nicht jedes Mal schrumpfen muss, müssen die kleinen Bilder trotzdem gecacht werden. Darum ging es ja oben. Grundsätzlich ist es immer besser, die hochauflösende Version der Grafik vorzuhalten. Dann brauchen sich auch die Autoren nicht um technische Details wie Grafikformate und -größen zu kümmern.

[e-fee]

Vernünftige Systeme (wie das bereits von Alex genannte Imagecache in Drupal) verlangen dem User da auch nix weiter ab. Er lädt das Bild in Originalgröße (ok, eine Größenbeschränkung kann trotzdem sinnvoll sein, schließlich kann man 15 Megapixel ja eh schlecht auf einem Monitor darstellen) hoch und den Rest macht das System anhand der frei definierten Vorgaben durch den Admin automatisch.

[SloMo]

Drupal... meine Hassliebe. Sag mal bescheid, wenn es ein endgültiges Drupal gibt. Solange die mit jeder Hauptversion alles mögliche ändern, habe ich da keine Lust mehr drauf. Habe mir mal ein paar Drupal 6 Seiten ans Bein gebunden (eine Installation, mehrere Sites) und nachdem schon mal ein Modul inkompatibel wurde und ich deshalb die Templates debuggen musste, habe ich Schiss vor jedem Modul- und Core-Update.

Imagecache ist aber schon watt ordentliches.

[Cujo]

Ich habe vor einiger Zeit eine 5-teilige Serie zum Thema "Webseiten beschleunigen" geschrieben:

Webseiten beschleunigen

Da findest du sicher viele Tipps, die dir weiterhelfen

[Alex L.]

Ich zähle die Drupal Sites unter meinem Gürtel schon nicht mehr und dass zwischen Major Releases nicht jeder erdenkliche Ballast mitgeschleppt wird wie zu guten alten Intel-/DOS-/Windows-Zeiten werte ich klar als Vorteil

Und was seinen Schiss vor Updates angeht:
Meine Schwägerin hat Schiss Auto zu fahren wenn Schnee liegt. Darum kann sie es auch nicht

[nerd]

Du lädst da gut 5,5 MB auf der Index. Etwas üppig:

https://tools.pingdom.com/fpt/?url=www. ... &save=true

vorsicht! pingdom zaehlt alle elemente die es in eingebundenen css dateien findet, auch wenn diese auf der eigentlichen seite nicht verwendet oder geladen werden.

[o2]

Noch ein Punkt zur Größe der Bilder: die Browser erledigen das Herunterrechnen der großen Bildern auf die im HTML-Quellcode angegebene Größe nicht immer in der besten Qualität, sprich neben der verbesserten Ladezeit würde sich auch das Erscheinungsbild der Thumbnails durch die Größenanpassung am Server verbessern!

[seonewbie]

Ohne jetzt gleich allen zu widersprechen.
Erst einmal Apache und MySql optimieren.
Dann 1GB Anbindung direkt an den switch vom Rechenzentrum
denn es lohnt sich kaum an den Bildern zu Doktorn es
sei denn Dir wird der Traffic zu teuer ... Am besten
Server mit echter Traffic Flat ohne runter Schaltung am 100MBit
(kein 1&1, Stato e.t.c.) das kostet ca 300€ im Monat
aber Du hast dann 1GB 24h und extrem gute performance.

Buch mal den Hushi für ein paar Stunden:
https://www.huschi.net

Oder hier zum selber schrauben:

https://www.huschi.net/10_299_de.html?highlight=tuning
https://www.huschi.net/12_302_de.html

Server Support Forum Apache MySql:
https://serversupportforum.de/forum/sql ... cript.html

Für dein CMS sollte es ein Plugin/Contrib geben die deine
Bilder On the Fly verkleinern. Du brauchst nur das Plugin
den rest mach imagemagic auf deinem Server.

Ich denke die Links geben Dir einen Einstieg.Wenn Dir das zu viel
Arbeit oder zu komplziert ist ist buch den Hushi oder einen adäquat
kompetenten Linux admin.

Gruß

Micha

[nerd]

Erst einmal Apache und MySql optimieren.
Dann 1GB Anbindung direkt an den switch vom Rechenzentrum
denn es lohnt sich kaum an den Bildern zu Doktorn es
sei denn Dir wird der Traffic zu teuer ...

das nuetzt den usern die sich die seite ueber eine langsame verbindung oder von weit weg ansehen aber wenig
es ist deutlich sinnvoller die anzahl der verbindungen die benoetigt werden um die webseite darzustellen zu begrenzen (siehe css sprites). die antwortzeiten von db ->webserver sind selbst bei komplizierten anfragen in groesseren datenbanken auf meinem netbook im einstelligen millisekundenbereich.