Soderle, nun bin ich mit unserem Shop auch in der 3.5er Runde und ih muß sagen, ich bin von der Performance entsetzt (im Vergleich zu 3.0). In der Roadmap wir großspurig von Verbesserungen in der Codebasis und Faktor 1.5 bis 3x so schnell gesprochen. Alosi ich muß offen und ehrlich sagen, bei uns sind es 200% und zwar 200% Ladezeit im vergleich zu vorher. War Shopware 3.5 vor der .4 am Ende wirklich so bescheiden? Wie komme ich auf die doppelt so lange Ladezeit? Naja, Onkel Google gibt mir 2,4 Sekunde im Vergleich zu 1,2 Sekunden vorher und auch Seite wie webpagetest.org bescheinigen mir das mein Shop erheblich langsamer geworden ist (neben dem subjektiven Gefühl ;)). Abgesehen davon ist der load unseres Servers erheblich angestiegen, von grob 0.2 auf 0.8 … Und das Update war ein sauberes, es wurden nur die Shop-Dateien ausgetauscht, die präsentierten Informationen sind gleich geblieben. Liebe Shopware’s, bitte veröffentlich doch mal ein „best practices“ zur Optimierung der Webumgebung und Caching der Software. Wenn hier im Forum schon gemutmaßt wird ob man Caching bei einer kleine Artikelanzahl lieber deaktivieren soll, dann ist das kein gutes Zeichen für eine ordentliche Dokumentation. Geht es anderen hier auch so das ihr Shop mit 3.5.4 unsäglich langsamer geworden ist? Order bin ich jetzt „nur“ in der 3.5er Welt angekommen?
Hi, Auf die Schnelle habe ich eine erste Vermutung, denn das ist absolut kein Standard-Verhalten. Hast Du zufällig viele und / oder eigene Plugins aktiv, die zudem immer bei jedem Seitenaufruf geladen werden? Falls ja, bitte mal temporaer deaktivieren und erneut die Perfromance checken. Theoretisch kann es auch sogar nur an einem Plugin liegen, ich kenne nur Deine Umgebung jetzt nicht genau. Bei den Plugins würde ich aber zuerst suchen. In 2. Instanz würde mal prüfen, ob evtl. auch eine Schnittstelle hier (wawi) die Ursache sein kann. In 3. Instanz dann mal an Shopeinstellungen (z.b. Cache) schrauben. Generell wäre aber auc mal interessant, was für ein Serverpaket im Einsatz ist?
Achso… Debug Plugins sind nicht auch zufällig an im Livebetrieb?
[quote=“ronecker”]Soderle, nun bin ich mit unserem Shop auch in der 3.5er Runde und ih muß sagen, ich bin von der Performance entsetzt (im Vergleich zu 3.0). In der Roadmap wir großspurig von Verbesserungen in der Codebasis und Faktor 1.5 bis 3x so schnell gesprochen. Alosi ich muß offen und ehrlich sagen, bei uns sind es 200% und zwar 200% Ladezeit im vergleich zu vorher. War Shopware 3.5 vor der .4 am Ende wirklich so bescheiden? Wie komme ich auf die doppelt so lange Ladezeit? Naja, Onkel Google gibt mir 2,4 Sekunde im Vergleich zu 1,2 Sekunden vorher und auch Seite wie webpagetest.org bescheinigen mir das mein Shop erheblich langsamer geworden ist (neben dem subjektiven Gefühl ;)). Abgesehen davon ist der load unseres Servers erheblich angestiegen, von grob 0.2 auf 0.8 … Und das Update war ein sauberes, es wurden nur die Shop-Dateien ausgetauscht, die präsentierten Informationen sind gleich geblieben. Liebe Shopware’s, bitte veröffentlich doch mal ein “best practices” zur Optimierung der Webumgebung und Caching der Software. Wenn hier im Forum schon gemutmaßt wird ob man Caching bei einer kleine Artikelanzahl lieber deaktivieren soll, dann ist das kein gutes Zeichen für eine ordentliche Dokumentation. Geht es anderen hier auch so das ihr Shop mit 3.5.4 unsäglich langsamer geworden ist? Order bin ich jetzt “nur” in der 3.5er Welt angekommen?[/quote] Hallo, 3.5.1 bis 3.5.4 ist der Shop nicht langsamer geworden bei uns, im Vergleich zu der alten 3.05 schon um einiges, auch traten hier einige Probleme auf, ob es nun an den neuen Plugins usw liegt kann ich als “Nichtprogrammier” nicht sagen. gruss und schönes We Volli
Hallo, Auch wir können diese Verlangsamung bestätigen, ein Seitenaufruf dauert im gegensatz zur 3.5.3 nun knapp 4 Sekunden mehr… Und am Server kanns definitiv nicht liegen (4 CPU Kerne, 8 GB Arbeitsspeicher)… Es sind keine Debug Plugins oder ähnliches aktiv. Woher kommt dieses Verhalten?
In 3,5,4 ist der db query Cache per Default deaktiviert, den könnt ihr in den Performance Einstellungen aber einfach wieder aktivieren. Ansonsten haben wir die Performance mit jmeter lasttests permanent zwischen den releases verglichen, da muss ein anderes Problem vorliegen. Ihr könnt zum Beispiel testweise die benchmark, debug u log Plugins aktivieren, dort gibt es nun einen SQL Monitor der die db Performance überwacht. @Holger du hast ja im zuge des Updates auch einiges am Server selbst verändert oder? Kann da der Hund begraben sein, die Overall Performance ist ungefähr gleich zur 305, das initiale kompilieren der templates dauert langer. Dieses webtool misst ja nicht die reine php Performance, sondern die Zeit, die zum ausliefern aller Ressourcen benötigt wird, oder? Da bitte mal schauen ob Output compression aktiv ist , Phpseitig konntest du noch apc installieren als opcode Cache. Ansonsten über die profiling tools von shopware die Stelle suchen, die viel Zeit benötigt. Was hast du für eine Server hardware und welche aktiven Plugins?
[quote=“Stefan Hamann”]In 3,5,4 ist der db query Cache per Default deaktiviert, den könnt ihr in den Performance Einstellungen aber einfach wieder aktivieren. Ansonsten haben wir die Performance mit jmeter lasttests permanent zwischen den releases verglichen, da muss ein anderes Problem vorliegen. Ihr könnt zum Beispiel testweise die benchmark, debug u log Plugins aktivieren, dort gibt es nun einen SQL Monitor der die db Performance überwacht. @Holger du hast ja im zuge des Updates auch einiges am Server selbst verändert oder? Kann da der Hund begraben sein, die Overall Performance ist ungefähr gleich zur 305, das initiale kompilieren der templates dauert langer. Dieses webtool misst ja nicht die reine php Performance, sondern die Zeit, die zum ausliefern aller Ressourcen benötigt wird, oder? Da bitte mal schauen ob Output compression aktiv ist , Phpseitig konntest du noch apc installieren als opcode Cache. Ansonsten über die profiling tools von shopware die Stelle suchen, die viel Zeit benötigt. Was hast du für eine Server hardware und welche aktiven Plugins?[/quote] holger?^^ Serverhardware Intel® Core™ i7-920 Quad-Core inkl. Hyper-Threading-Technologie Arbeitsspeicher 24 GB DDR3 RAM Festplatten 2 x 1500 GB SATA-II HDD (Software-RAID 1) bei Der 3.05 hatten wir ca 100T Artikel online und das ohne Probleme. Bei der 3.5 ca 60T,Seitenafbau,Löschen von Artikel usw geht da halt etwas langsamer. Generell nicht langsam aber halt langsamer im Vergleich zu der 3.05. Geändert wurde halt nur die php Version 5,26 auf 5,35. Dies ist aber kein Problem wo ich nun Hilfe benötige,wollts halt nur mal erwähnen im Vergleich zu der 3.05. Gruss Volker
@Stefan Wir haben das gleiche Problem mir der Performanz, ich dachte das es mit dem Update auf die Version 3.5.4 behoben wäre, nur leider ist das nicht der Fall. Ich glaube aber nicht das es an der Version 3.5.4 liegt sondern ehr an der 3.5.3, hier mal ein Beispiel! Wir haben seit ca. 6 Monaten eine Shop mit der Version 3.5.3, dieser Shop wurde auch mit dieser Version zum ersten mal installiert, da gab es schon mal Probleme mit der Indizies einer Tabelle (zum Beitrag). Das laden der Startseite dauert zwischen 4 bis 8 Sekunden, seltsam ist das wenn man eine Kategorie aufruft, diese wesentlich schneller aufgebaut wird als die Startseite, auch nach dem Update auf die Version 3.5.4 gibt es keine Verbesserung! Jetzt hatten wir nach dem Erscheinen der 3.5.4 einen neuen Shop mit der Version 3.5.4 erstellt. Beide Shops laufen auf demselben Server, und beide Webacounts haben die gleiche Einstellung und Performance Zuweisung, auch sind beide Shops ähnlich aufgebaut mit der Anzahl an Artikeln ca. 21000 und die Artikel haben jeweils 3 bis 5 Filterfunktionen. Nur ist der neue Shop wesentlich schneller, der benötigt nur ca. 1 Sekunde für die Startseite oder Kategorien. Also denke ich mal das es beim Anlegen einer oder mehrere Indizies in der SQL-DB ein Problem gegeben hat, und diese nicht korrekt angelegt wurden, und dieser Fehler ist auch nach dem Update auf 3.5.4 nicht behoben. Wir wären ja bereit die DB für den Shop neu aufzubauen wenn man die wichtigsten Inhalte separat sichern könnte, und nach dem neuen aufsetzen der neuen DB wieder einspielen könnte, hierbei geht es mir hauptsächlich um den ganzen Content, wie Mailvorlagen, Texte usw., aber ich weis nicht welche Tabellen ich dafür manuell sichern muss, um diese dann später wieder einfach per Insert über PHP MySQL wieder einzuspielen, da diese Einstellungen doch sehr Zeitaufwendig sind! Vielleicht hat ja jemand noch eine andere Idee? Vielleicht ist das auch eine Idee für ein Plugin das nur die Daten sichert die man im Shop manuell eingeben (Konfigurieren) muss um diese dann wieder einzuspielen zu können! Marco
@Revo: Das kann nicht sein! Da muss definitiv was an den Installationen anders sein, aber nicht die DB. Leg mal die Cache Verzeichnisse alle neu an, aber Vergleiche vorher alle Cache / Grundeinstellungen und alle aktiven Plugins! Dann sollte es keinen Performance Unterschied geben, es sei denn, die 3.5.3er Version war vorher nicht korrekt installiert!
[quote=“harald”]@Revo: Das kann nicht sein! Da muss definitiv was an den Installationen anders sein, aber nicht die DB. Leg mal die Cache Verzeichnisse alle neu an, aber Vergleiche vorher alle Cache / Grundeinstellungen und alle aktiven Plugins! Dann sollte es keinen Performance Unterschied geben, es sei denn, die 3.5.3er Version war vorher nicht korrekt installiert![/quote] @harald, dass das keiner Logik entspricht ist mir schon klar, aber leider ist es so. Das mit dem Cache haben wir alles schon ausprobiert! Egal ob wir Cache aktive haben oder nicht, die Geschwindigkeit ist gleiche, auch nicht notwendige Plug-Ins hatten wir schon mal deaktiviert, nur brachte das auch nichts! Ich sagte ja das es dieses Problem schon in der 3.5.3 gab, und sich mit dem Upgrade auf 3.5.4 nichts gehändert hat, daher gehe auch ich davon aus das es in der 3.5.3 schon ein Problem gab! Marco
die Aktivierung des Log Plugins endet mit ner netten Fehlermeldung. Strict Standards: Declaration of Enlight_Template_TemplateManager::__call() should be compatible with that of Smarty::__call() in /www/htdocs/w00ddcc2/engine/Enlight/Enlight/Template/TemplateManager.php on line 3 Fatal error: Uncaught exception ‚Zend_Controller_Response_Exception‘ with message ‚Cannot send headers; headers already sent in /www/htdocs/w00ddcc2/engine/Enlight/Enlight/Template/TemplateManager.php, line 3‘ in /www/htdocs/w00ddcc2/engine/Enlight/Vendor/Zend/library/Zend/Controller/Response/Abstract.php:321 Stack trace: #0 /www/htdocs/w00ddcc2/engine/Enlight/Vendor/Zend/library/Zend/Controller/Response/Abstract.php(115): Zend_Controller_Response_Abstract->canSendHeaders(true) #1 /www/htdocs/w00ddcc2/engine/Shopware/Controllers/Frontend/Error.php(26): Zend_Controller_Response_Abstract->setHeader(‚Content-Type‘, ‚text/html; char…‘) #2 /www/htdocs/w00ddcc2/engine/Enlight/Enlight/Controller/Action.php(70): Shopware_Controllers_Frontend_Error->errorAction() #3 /www/htdocs/w00ddcc2/engine/Enlight/Enlight/Controller/Dispatcher/DispatcherDefault.php(329): Enlight_Controller_Action->dispatch(‚errorAction‘) #4 /www/htdocs/w00ddcc2/engine/Enlight/Enlight/Controller/Front.php(99): Enlight_Controller_Dispatcher_DispatcherDefault-> in /www/htdocs/w00ddcc2/engine/Enlight/Vendor/Zend/library/Zend/Controller/Response/Abstract.php on line 321 wird dieses plugin benötigt um im sql monitor was anzuzeigen, denn der ist bei mir leider leer.
Mal so um die ganze Geschichte noch in den Raum zu werfen, Ladezeit eines 3.5.4 Shops eines unserer Kunden: http://www.webpagetest.org/result/11061 … 1/details/ 17,281 Sek… Ideen? Da die langen Ladezeiten, die Kunden frustieren, zur Zeit erhält unser Kunde zu dem noch Emails das die Kunden ständig Ihre Cookies löschen müssen, da sie sich nicht mehr ins Kundenkonto einloggen können. (Es erscheint keine Fehlermeldung!)
Habe das Ergebnis jetzt nicht im Detail gesehen, aber due Zeit ist nicht normal. Da muss was bim Uodate schief gegangen sein. Kopiere das Updatepaket einmal neu drüber. Aber nur die Dateien und dann mal den Cache/Database Order neu anlegen. Danach waren bei mir alle Pribleme weg. Auch das Session Problem. Sollte der Shop auch dann nicht schnell sein, musst du mal mit den Cachingzekten arbeiten. Hilft auch das nicht, so bleibt nur due Server Hardware! Ggf. schon älter/langsam… PS: konnte allerdings gar nicht feststellen, dass das System langsam ist
Hallo 
Ich denke im Thema Server Konfiguration, hab ich schon größere Server in der Administration, die täglich mehr als 10 Mio. Hits Verzeichnen. Die Hardware ist vollständig neu und auch überhaupt nicht unter dimensioniert. Die aufgezeichneten Server Statistiken zeigen das der Server bei mehr als 20.000 Zugriffen am Tag fast im „Leerlauf“ läuft. Ebenfalls auch die Statistiken vom Arbeitsspeicher, was aber sehr auffällig ist, sind die Lowqueries an die MySQL Datenbank seitens von Shopware. Ich bin gerne bereit, die Grafischen Aufzeichnungen des Servers zu veröffentlichen, wenn es der Fehlersuche dient. Die Caching Funktionen sind alle Komplett an, ebenfalls werden alle Caches einmal pro Nacht mittels einem Cronjob selbstständig gelöscht. Ich werde erstmal ein paar Server Tests fahren, unter anderem mit einer völlig anderen Konfiguration, da wir normaler weiße kein Apache einsetzten, sondern den High Performance Webserver NGIX. Morgen im laufe des Tages werde ich mal einen Probelauf auf einem 16 GB Arbeitsspeichersystem veröffentlichen… Aber das Login Backendproblem sollte aber nicht den Kundenlogin betreffen?!
Moin, wegen der Login-Probleme am besten wirklich einmal die Update-Dateien 3.5.4 nochmal drüber bügeln, dann sollte sich das erledigt haben. Was die Performance betrifft. Die 17 Sekunden beziehen sich auf die Gesamtladezeit aller Ressourcen - der PHP-Prozess läuft ca. 4 Sekunden, der Rest geht bei der AUslieferung statischer Ressourcen drauf. Das sollte der Webserver deutlich schneller können, es sei denn auf dem Server ist die “Hölle” los, was sich aber aus deinen Zahlen nicht ableiten lässt. Wie viele Artikel habt ihr im Sortiment? Ansonsten bitte einmal Benchmark, BenchmarkEvens, Log und Debug Plugin aktivieren und dann mit Firebug & FirePHP das Stack-Protokoll einsehen, da kannst du genau sehen, wo die Zeit beim PHP-Prozess bleibt. Zusätzlich könntest du das APC-Modul für PHP installieren - das bringt je nach Konfiguration zwischen 30 und 60 % mehr Performance. (Auf PHP bezogen). Hast du PHP per Fast-CGI eingebunden?
Servus miteinander, so, ich habe in den Eingeweiden unseres Servers ein wenig gewühlt und siehe da, es gibt einen Bug im eAccelerator in Kombination mit der open_basedir restriction von php5.3. Wer hätte es gedacht. Naja, ich habe eben eine gefixed Version bei uns eingespielt und ich werde sie noch ein wenige testen. Insgesamt kann ich jetzt schon sagen, ich spüre direkt das die Geschwindigkeit besser geworden ist. Mal schauen was Onkel Google, unsere Logs und die anderen Testseiten so berichten. Ich melde mich auf alle Fälle nochmal wenn ich weiß wie die Tests bei uns verlaufen sind.
@Volker naja, ich fühle mich von “Holger” angesprochen. Stephan hatte mich gemeint, da Shopware auch das Update bei uns durchgeführt hat. Nachdem ich das Wochenende am feilen und optimieren an unserem lieben kleinen Server war kann ich allgemein schon mal Entwarnung geben, der Shop liegt nun wieder in erwarteten Bereichen. Ich gehe mal der Reihe nach die Tipps und Anregungen durch. [quote=“Stefan Heyne”]Hi, Auf die Schnelle habe ich eine erste Vermutung, denn das ist absolut kein Standard-Verhalten. Hast Du zufällig viele und / oder eigene Plugins aktiv, die zudem immer bei jedem Seitenaufruf geladen werden? Falls ja, bitte mal temporaer deaktivieren und erneut die Perfromance checken. Theoretisch kann es auch sogar nur an einem Plugin liegen, ich kenne nur Deine Umgebung jetzt nicht genau. Bei den Plugins würde ich aber zuerst suchen. In 2. Instanz würde mal prüfen, ob evtl. auch eine Schnittstelle hier (wawi) die Ursache sein kann. In 3. Instanz dann mal an Shopeinstellungen (z.b. Cache) schrauben. Generell wäre aber auc mal interessant, was für ein Serverpaket im Einsatz ist?[/quote] 1) Naja, alles was es gibt will ich auch haben, daher ist das Meiste aktiviert. Aus dem Store haben wir keine zusätzlichen Plugins laufen, dafür ein paar eigene. Ein deaktivieren hat aber keinen Unterschied gebracht. 2) Ja, wir haben eine Wawi angebunden, zu dem Zeitpunkt der Probleme war die Schnittstelle aber deaktiviert, daher kann sie nicht der Grund für die Probleme gewesen sein. Im übrigen läuft sie nun ohne Probleme zu machen. 3) Mich hatte überrascht das der Cache bei jedem Update Schritt immer wieder deaktiviert wurde, inzwischen ist er wieder an, wobei ich das später noch mal in Ruhe testen muß, denn vom Eindruck her macht es keinen Unterschied ob der Cache an oder aus ist (außer das ich ihn nicht leeren kann wenn er an ist, vermutlich zu viele Dateien im Dateisystem) [quote=“Stefan Heyne”]Achso… Debug Plugins sind nicht auch zufällig an im Livebetrieb?[/quote] Die sind natürlich in der produktiv Umgebung deaktiviert. Ich würde sie gerne deinstallieren, aber da meckert der Plugin Manager rum. Ich glaube ihm gefällt neuerdings nicht wenn Plugins keine uninstall Funktion mitbringen, dann gibt es nur nichtssagende Fehlermeldungen. [quote=“Stefan Hamann”] @Holger du hast ja im zuge des Updates auch einiges am Server selbst verändert oder? Kann da der Hund begraben sein, die Overall Performance ist ungefähr gleich zur 305, das initiale kompilieren der templates dauert langer. Dieses webtool misst ja nicht die reine php Performance, sondern die Zeit, die zum ausliefern aller Ressourcen benötigt wird, oder? Da bitte mal schauen ob Output compression aktiv ist , Phpseitig konntest du noch apc installieren als opcode Cache. Ansonsten über die profiling tools von shopware die Stelle suchen, die viel Zeit benötigt. Was hast du für eine Server hardware und welche aktiven Plugins?[/quote] Naja, außer die PHP Version von 5.2 auf 5.3 bringen habe ich eigentlich nichts verändert am Server, der Rest war in den 3.0.5er Einstellungen. OK, ZendOptimizer ist noch raus geflogen, der IonCube Loader ist dafür rein gekommen und eAccelerator wollte für die neue php Version kompiliert werden. Das war’s aber, mehr wurde wirklich nicht verändert. zlib.output_compression ist deaktiviert, dafür läuft im Apachen mod_deflate, sprich alles was geht wird als gzip ausgeliefert. Als opcode Cache kommt wie gesagt eAccelerator zum Einsatz bei uns. Mir geht es weniger um den Hauch den er noch schneller als apc ist, eAccelerator kommt bei uns seit vielen Jahren zum Einsatz und hat uns bisher immer gute Dienste geleistet. Daher brauche ich im Moment keinen neuen. Als Server sind wir im Moment in einer virtuellen Umgebung (ja, buh, ich weiß) nur mir stehen 4 GB Ram + Reserve und 2 Kerne zur Verfügung. Und bisher gab es keine Veranlassung was zu verändert, denn der load auf dem Server lag vor dem Update im Durchschnitt bei 0.25 Bezüglich webpagetest.org, die schlüsseln schön auf was wann geladen wurde, von daher kann ich schon sehen wann die Seite ausgeliefert wurde und wann der restliche Zeremons wie css, js und die lieben Bilderchen geladen wurden. Aber kommen wir zum Ergebnis, das was ich denke das bei mir geholfen hat. Zum einen ganz klar der von mir angesprochene Bug im eAccelerator war wirklich für einen Teil der Probleme verantwortlich. Nachdem er wieder ordentlich Dateien includen darf meckert er auch nicht mehr herum. Bezüglich dem Shop Cache, er ist wieder aktiviert. Hier vertraue ich auch die Aussage von Shopware das er nützt, Ihr kennt Euch einfach besser in Eurem Quellcode aus als ich. Und dann natürlich ein fleißiges optimieren am Content selber. Wir hatten ebenfalls einen Wechsel der Template von 3.0.5 auf eine neue 3.5er durchgeführt. Und da wollen die ganzen Bilder besser komprimieren werden, js & css minimieren und zusammenfassen und den ganzen anderen Kram den sonst noch so macht. Mir macht trotzdem Sorge das 3.5 gegenüber 3.0.5 deutlich Ressourcen hungriger geworden ist. Wenn ich in unsere Auswertungen schauen dann hatten wir vorher einen load von 0.25 im Durchschnitt, jetzt sind es 0.45 im Durchschnitt. Die cpu time ist logischerweise auch schlagartig hoch gegangen. Und vor allem wird der SQL Server deutlich mehr gequält. Ja lacht nur, wir sind von 8 queries/sekunde unter 3.0.5 auf 135 queries/sekunde unter 3.5 gesprungen. Ok, davon werden 123 queries/sekunde als Cache Hits abgefangen, nur holla, das ist locker mal der Faktor 17 was mehr an Anfragen abgesetzt wird. Und dann sind die Apache Prozesse noch um den Faktor 1,5 angestiegen, das scheint aber (zum Teil) mit dem Recommendation Modul zusammen zu hängen, das läd ja immer neue Seiten um den Slider Effekt zu erzielen. Ich werde das ganze auch noch mal genauer beobachten, ich kann denn Mitarbeitern von Shopware auch gerne Zugang zu unseren Auswertungen geben. Soweit das aktuelle Feedback von unserer Seite aus.
[quote=“Sany-Media”]Mal so um die ganze Geschichte noch in den Raum zu werfen, Ladezeit eines 3.5.4 Shops eines unserer Kunden: http://www.webpagetest.org/result/11061 … 1/details/ 17,281 Sek… Ideen? Da die langen Ladezeiten, die Kunden frustieren, zur Zeit erhält unser Kunde zu dem noch Emails das die Kunden ständig Ihre Cookies löschen müssen, da sie sich nicht mehr ins Kundenkonto einloggen können. (Es erscheint keine Fehlermeldung!)[/quote] Hi Sany-Media, das sieht ja wirklich übel aus. Sie zu das Du das Keep-Alive im Webserver aktivierst, das sollte schon mal ein bisschen helfen, denn dar “Connection View” Eures Kunden sieht übel aus. Da wird wirklich eines nach dem anderen geladen. Punkt zwei, sieh zu das der Content mit einer Cache Zeit ausgeliefert wird. Das macht die Seite zwar per see nicht schneller, aber wenn man drauf rum surft dann hilft es doch schon wenn der Kunde nicht immer alles neu Laden muß. Das kann man am “Repeat View” sehen, der braucht fast so lange wie der Erste. Schritt drei, Nahkampf um die gut 4 Sekunden “Time to First Byte” der Webseite runter zu bekommen. Hier ein Vergleich für Dich wie es bei uns im Moment aussieht und wir laden mehr als doppelt so viele Objekte wie Euer Kunde. http://www.webpagetest.org/result/110620_RR_W945/ OK, ich habe gerade die Seite noch mal getestet, Punkt 1 scheinst Du ja schon gefunden zu haben und Punkt 3 ist ja auch schon besser geworden. Ich gebe Dir noch einen Tipp, ich habe gesehen Du arbeitest mit einem anderen Hostnamen für statischen Content, das ist grundsätzlich gut, nur paß höllisch auf wenn Du noch ein SSL Zertifikat für den Shop einbaust. Das meckert dann nämlich rum wenn auf einmal unverschlüsselter Content vom anderen Hostnamen geladen wird. Man kann es hier im Shopwareforum wunderbar testen wenn man auf “Mein Account” klickt. Bei mir springen dann alle Sicherheitsmechanismen im Browser an, weil dieses hübsche Twitter Ding rechts unten nicht verschlüsselt ist. Hier ist es naja, in einem Onlineshop ist es ein sehr schlechtes Zeichen wenn die Adresszeile auf einmal rot wird und vor nicht sicherem Inhalten gewarnt wird. Soweit meine Gedanken.