Bitte um Rat bzgl. sehr schlechter Ladezeit

Mr. T · : 21.02.2011 : 4

Hallo Gemeinde,

ich bin auf der Suche nach einem Rat zur Optimierung der extrem schlechten Ladezeit einer auf Joomla! basierenden Seite. Sämtliche Scripten und Stylesheets, die von mir erstellt wurden und per Kommando geladen werden, wurden komprimiert. Doch es werden auch Scripten und Stylsheets von anderen Erweiterungen, die ich nicht programmiert habe, eingebunden.

Ich habe die Ladezeit der Seite mit dem Firefox Plugin YSlow sowie auf einer Mess-Seite bei 1und1 getestet und musste feststellen, dass schon auf der Startseite Inhalte geladen werden, die dort garnicht zu sehen sind. Alles in allem werden 28 MB Daten übertragen, ehe die Seite fertig geladen hat.

Ich wurde beauftragt, nach Optimierungsmöglichkeiten zu suchen, kenne mich damit bis auf das Einstampfen von Scripten und Stylesheets sowie Grafiken damit nicht aus. Da die Seite von einer studentischen Redaktion betreut wird, habe ich auch keinen Einfluss auf den redaktionell erzeugten Inhalt (Bilder).

Ist es möglich, mir mit klaren Handlungsempfehlungen weiterzuhelfen? Ich weiß nicht wirklich, wo sonst ich danach fragen könnte. Es gibt zwar für alles mögliche Foren, jedoch erschien mir dieses das am besten geeignete.

Alex L. · : 23.01.2011 : 208 : Iserlohn

Brrr.... Joomla! ....

Schau dir mal alleine die Playlist an. Da werden Bilder in der Größe 800x532 (vermutlich Originalgröße) geladen um als 110x70 angezeigt zu werden.

In Drupal ist das ein klassischer Fall für Imagecache. Aber sicher gibt es da auch in Joomla! eine Standard-Lösung.

Drupal & SEO

pimpi · : 13.12.2005 : 1493 : Norwegen

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

http://tools.pingdom.com/fpt/?url=www.berlinmusic.tv&treeview=0&column=objectID&order=1&type=0&save=true

!!! Das beste Partnerprogramm mit top Zahlungsmoral !!!

Suche für Ostsee Reise Seite: Links/Artikeltausch

Synonym · : 09.08.2008 : 3496 : Würzburg

was nicht verwunderlich ist, bei solchen Bildern:
http://www.berlinmusic.tv/media/bmtv/redaktion/bilder/11_01_18_roughroostars.png

Rizzo · : 31.08.2010 : 45

Ich kenn YSlow nicht, daher beziehe ich mich jetzt mal auf PageSpeed (unter Firefox).

Damit kannst du recht gut erkennen wo Ladenzeiten verschwendet werden... mit Beispielen wie diese behoben werden können.

Zum Thema:
Auch wenn du keinen Einfluss auf die Bilder an sich hast... so sag den Betreibern - dass HD Bilder (oder welche die es werden wollten) sich nicht sonderlich gut machen. Vorallem wenn diese ca. 80% kleiner (Dateigröße) fast genauso aussehen.

Zum Server (falls dieser unter der Linuxflagge läuft) schau mal ob 'mod_expires' installiert ist. Da kann man vieles Cachen lassen.
Das zum Beispiel in die htaccess schreiben und schauen ob es funktioniert

SloMo · : 04.01.2005 : 4027

Die Bilder sollten schon in der Originalauflösung hinterlegt werden. Während der Anzeige müssen sie auf ein Thumbnail herunterskaliert und gecacht werden.

Eine Extension, die sowas wohl recht gut macht: Image Resize ( http://extensions.joomla.org/extensions/photos-a-images/articles-images/5694 )

Ob sich das mit der Vorgehensweise der Studenten und mit den anderen Extensions verträgt, musst Du herausfinden.

Mr. T · : 21.02.2011 : 4

Danke für eure zahlreichen Beiträge!

Das Problem mit den Bildern ist, dass die Studis diese so "groß" speichern, weil sie sie sowohl in Artikel-Vorschaubildern, als auch in den Artikeln selbst (hier werden die großen in der Lightbox angezeigt) und stellenweise auch in der Playlist verwenden. Man müsste also hergehen und sie davon überzeugen, dass zusätzlich Thumbnails für die Vorschauen benötigt werden. Ich bin überzeugt davon, dass das auf Dauer nicht funktioniert, weil da einfach zu viele Köche im Brei rühren. Daher suche ich nach einem automatisierten Ansatz.

Die Bilder zur Renderzeit runterrechnen und im Temp-Folder speichern zu lassen, wird die Ladezeit sicher auch verschlechtern, oder?

Was mich bei beiden, YSlow und den 1und1 Webtools, gewundert hat, ist dass beim Laden der Startseite schon Bilder von den Genre-Unterseiten geladen werden, die erst mit einem Klick auf einen Top-Menülink geöffnet werden. Es wurden insgesamt erstmal 28 MB runtergeladen. Warum ist das so? Werden beim Laden der Startseite alles Links verfolgt und die Inhalte dabei schon gecacht? Kann man das unterbinden?

Lässt sich also mit Sicherheit der Flaschenhals auf die Bilder beschränken? Das ist, was ich sicher wissen müsste, um den um Hilfe bittenden Verantwortlichen eine entsprechende Erklärung präsentieren zu können und in der Folge den Hebel an der richtigen Stelle anzusetzen.

Lässt sich irgendwie messen, ob vielleicht auch der Server die Inhalte zu langsam ausliefert - sprich, ob man an der Serverperformanceschraube auch noch was tunen kann?

Alex L. · : 23.01.2011 : 208 : Iserlohn

Was willst du denn bei 5.5 oder 28 MB serverseiitg tunen!? Und willst du alle Besucher nötigen erstmal zum Server zu fahren und sich per GBit-Kabel dranzuhängen um eine akzeptable Geschwindigkeit zu erhalten?

Drupal & SEO

SloMo · : 04.01.2005 : 4027

Rizzo · : 31.08.2010 : 45

Nanu... auf einmal wird alles gecacht. War das vorher schon so?

Auch egal! Was zu deiner Cachelist noch hinzugefügt werden sollte sind vielleicht die CSS- und Javadateien.
Und da die bestimmt nicht so oft geändert werden, kannst hierbei die Cachezeit noch auf 1 Monat schrauben.

Zusätzlich kannst du den JS & CSS Code mit der Apache Mod 'gzip' etwas kleiner machen.

Soweit war das jetzt alles... ansonsten liegt das Hauptsächlich nur noch an den Bildern.

Theorie ist wenn jeder meint es besser zu wissen, Praxis ist wenn alles funktioniert und keiner weis warum.

Alex L. · : 23.01.2011 : 208 : Iserlohn

Rizzo · : 31.08.2010 : 45

Sry... für meine ungehobelte Abk., natürlich meine ich JAVAscript!!
Ich hab doch tatsächlich gedacht das man sich das herleiten könnte, vorallem da er keine [ACHTUNG] JAVA - Dateien auf dem Server zu laufen hat.

Theorie ist wenn jeder meint es besser zu wissen, Praxis ist wenn alles funktioniert und keiner weis warum.

Alex L. · : 23.01.2011 : 208 : Iserlohn

Mr. T · : 21.02.2011 : 4

SloMo · : 04.01.2005 : 4027