Hallo, leider ist die Pagespeed meines Shops ziemlich schlecht. Ich bin bei Mittwald und habe nun auf deren Empfehlung auf einen Managed V Server L umgestellt, leider hat sich nichts kann. Kann das nur an dem fehlenden Gzip/deflate liegen? Wäre super, wenn ihr euch das mal anschauen könntet und mir Tipps geben würdet. Der Shop lautet. www. w ohlfuehl- schirme. de (absichtlich so geschrieben, bitte kopieren u Leerzeichen entfernen) Viele Grüße!
[quote=“fittken”]Hallo, leider ist die Pagespeed meines Shops ziemlich schlecht. Ich bin bei Mittwald und habe nun auf deren Empfehlung auf einen Managed V Server L umgestellt, leider hat sich nichts kann. Kann das nur an dem fehlenden Gzip/deflate liegen? [/quote] Hallo, zur Beurteilung der Ladegeschwindigkeit und der Serverleistung ist zuerst die erste Datei in den DeveloperTools (Network Panel) der Browser entscheidend. Da sich diese bei der Seite und wiederholtem Laden nicht verändert, dürfte der Shopware http-Cache nicht aktiviert sein. Den zuerst aktivieren, dann lädt die Seite eigentlich ganz ordentlich. Das PAket ist nur leider nicht so performant. Wenn der Shop ohne Cache schnell laufen soll, muss man zu einem anderen Paket greifen. Mit httpCache, sollten aber keine Probleme mehr auftreten. Dann sollte man bei Mittwald darauf achten, eine neue php-Version zu verwenden. Eventuell ist dort noch 5.3 vorinstalliert (aus einer älteren Shopware-Installation). Dann muss man aber von Hand oder durch deren Kundendienst ioncube umstellen lassen. Also nur während der Geschäftszeiten die Umstellung im Kundenmenü vornehmen. Generell ist es so, dass die “Komfort”-Features bei Mittwald hinsichtlich Sicherungen Geld kosten und man bei preislich vergleichbaren Paketen anderer Anbieter dort Abstriche machen muss. Dafür könnten die dann evtl. etwas schneller sein. Wer aber schon einmal ein Paket zurücksetzen musste, weil ein Plugin “Amok” lief, wird diese zu schätzen wissen. Viele Grüße HTH
1 „Gefällt mir“
Neben dem Hosting ist natürlich auch die Seiten Optimierung sehr wichtig. Was mir hier bspw. auch auffällt ist, dass alleine Facebook ( wie immer ) knapp eine eine Sekunde zum laden benötigt. Hinzu kommen dann natürlich noch einige Bilder, sodass hier knapp 2 MB geladen werden müssen, was schon recht viel ist.
1 „Gefällt mir“
@hth: Du schreibst, dass sich Ladegeschwindigkeit und Serverleistung der Seite bei wiederholtem Laden nicht verändert haben. Ich hab mir bei Google Developers mit PageSpeed Insights mal die Startseite, sowie einige Kategorie- und Produktseiten angesehen. Ergebnis für die Desktop-Analyse: Von 100 möglichen Pukten hat die Startseite im Schnitt 60, die Kategorieseiten 57 und die Produktseiten nur noch 55. Je tiefer es in den Shop ging, desto mehr verschlechter sich der Pagespeed. Außerdem hat der Server mal innerhalb von 1 Sekunde geantwortet, öfters über 2 oder auch mal eine Antwortzeit von 3,7 Sekunden gehabt. (Laut Google sollte die Server-Antwortzeit ja eigentlich unter 200 ms liegen.) @fittken: Auf den ersten Blick könnte man auf den Produktseiten die Bilder komprimieren … und so fast soviel KB einsparen, wie durch die Komprimierung mit gzip oder deflate. (siehe z.B: https://developers.google.com/speed/pag … ab=desktop ) Du solltest aber vorher in der Google Bildersuche das Bilder-Ranking überprüfen. Wenn Bilder ein gutes Ranking haben, dann verzichte lieber auf deren Komprimierung. Veränderungen an den Bilddateien mag Google halt nicht - und jagt dann deren Ranking erstmal in den Keller. Gruss Jochen Baumberge
1 „Gefällt mir“
Danke an alle, das hilft schon mal. Vorher hatte ich ein ganz normales Hosting-Paket für 10€ im Monat, jetzt stelle ich auf den Managed V Server für 30€ um und merke keine Verbesserung… [quote=“Jochen Baumberge”] Außerdem hat der Server mal innerhalb von 1 Sekunde geantwortet, öfters über 2 oder auch mal eine Antwortzeit von 3,7 Sekunden gehabt. (Laut Google sollte die Server-Antwortzeit ja eigentlich unter 200 ms li[/quote] Woran liegt das? An Mittwald?
[quote=“fittken”]Danke an alle, das hilft schon mal. Vorher hatte ich ein ganz normales Hosting-Paket für 10€ im Monat, jetzt stelle ich auf den Managed V Server für 30€ um und merke keine Verbesserung… [quote=“Jochen Baumberge”] Außerdem hat der Server mal innerhalb von 1 Sekunde geantwortet, öfters über 2 oder auch mal eine Antwortzeit von 3,7 Sekunden gehabt. (Laut Google sollte die Server-Antwortzeit ja eigentlich unter 200 ms li[/quote] Woran liegt das? An Mittwald?[/quote] Der Server antwortet bei jeder Shopseite mit konstanten Zeiten, wenn man den Reload-Button drückt. Natürlich mit einer gewissen Streuung (100-200ms), aber nicht mit den im Zitat behaupteten Streuungen. Natürlich ist die Antwortzeit bei Kategorien, Artikeldetailseiten, Startseite usw. immer unterschiedlich. Die Antwortzeit reflektiert den “Rechenaufwand” zur Erstellung der Seite. Dies kann man am schnellsten mit den Developer-Tools in den Browsern messen. Wenn der Shopware http-cache aktiviert ist, dann sollte diese Zeit beim Drücken auf den Reload-Button geringer werden. Tut sie aber nicht, daher meine Vermutung, der Shopware-Cache sei nicht aktiviert (im Backend aktivierbar). Der Wert sollte mit Cache so bei 350-400ms liegen. Diese initiale Antwortzeit ist abhängig von dem Hosting-Paket. Allerdings glaube ich nicht, dass die bei einem der preiswerten Shared-Hosting-Angeboten von Mittwald ohne Shopware-Cache durchschnittlich so schnell gewesen ist. Jetzt gibt es in den Developer-Tools noch eine “Gesamtladezeit”. Die gibt an, wie lange es dauert, bis alle Grafiken etc. geladen sind. Hier muss man allerdings aufpassen, da Statistik-Tools oder Social-Media-Buttons unter Umständen permanent Daten abrufen und den Wert erhöhen, obwohl die Seite eigentlich komplett geladen ist. Diese Statistik-Tools werden gerne als Begründung für langsames Laden genannt. Sie haben aber nichts mit der initialen Antwortzeit von oben zu tun.
1 „Gefällt mir“
Schau mal nach ob bei dir im Mittwald-Paket ein Byte-Code-Cache aktiv ist. Im Standard ist das dort nicht immer der Fall, siehe auch http://wiki.shopware.com/Performance-Ti … _1258.html Stichwort ZendOpcache + APCu Falls nicht aktiv, einfach beim Support anrufen die stellen das auch für dich um.
1 „Gefällt mir“
@hth: Du kennst dich bei Server-Fragen ohne Zweifel wesentlich besser aus und wahrscheinlich ist das von mir genutzte Google-Tool auch nichts für Profis. Ich hab die Startseite daher als Beispiel nochmal vom WebPagetest analysieren lassen (siehe: http://www.webpagetest.org/result/150204_WE_S7Y/ ). Wenn die “Repeat View” hierbei einem Reload beim Browser entspricht, dann liegen zwischen “First View” und “Repeat View” über 2 Sekunden. Oder verstehe ich diese Angaben jetzt falsch? @fittken: Schau Dir bitte bei dem WebPagetest mal die Details an. Ein 404-Fehler wird dort an einer Stelle angezeigt.
1 „Gefällt mir“
[quote=„Jochen Baumberge“]@hth: Du kennst dich bei Server-Fragen ohne Zweifel wesentlich besser aus und wahrscheinlich ist das von mir genutzte Google-Tool auch nichts für Profis. Ich hab die Startseite daher als Beispiel nochmal vom WebPagetest analysieren lassen (siehe: http://www.webpagetest.org/result/150204_WE_S7Y/ ). Wenn die „Repeat View“ hierbei einem Reload beim Browser entspricht, dann liegen zwischen „First View“ und „Repeat View“ über 2 Sekunden. Oder verstehe ich diese Angaben jetzt falsch? [/quote] Time to First Byte in der ersten Zeile im Waterfall-Diagramm oder „First Byte“ in der ersten Tabelle bei dem Link sind die Werte, die durch die Rechenleistung beeinflusst werden. Bei Google Pagespeed wird im Prinzip „Time to First Byte“ als Ladezeit gewertet. Liegt die bei 350-400ms ist Google Pagespeed eigentlich zufrieden. In dem Waterfall-Diagramm sieht man in der ersten Zeile an dem langen hellgrünen Balken, wie der vServer „rechnet“ und die Daten zusammenstellt. Der folgende kurze blaue Abschnitt ist die eigentliche Download-/Übertragungszeit. Die Datei in der ersten Zeile ist der „nackte“ HTML-Code der Startseite, Kategorie- oder Artikeldetailseite. Um diesen „Zusammenzustellen“ , muss Shopware alle Informationen zu Artikeln, Preisen oder Shopseiten aus der Datenbank abfragen und dazugehörige Berechnungen ausführen. Hier sieht man, wie leistungsfähig ein Webpaket ist und der Wert wird auch nicht durch die Größe der Artikelbilder oder sonstiger Dateien beeinflusst, die geladen werden müssen. Ist der httpCache von Shopware aktiviert, sinkt der Wert, weil viele Seiten bereits fertig zusammengebaut im Cachce-Speicher vorliegen. Dadurch werden die notwendigen Datenbankabfragen reduziert und die sind die Ressourcen verbrauchenden Teile von Shopware. Die „Load-Time“ berücksichtigt, dass beim Browser-Reload z. B. Artikelbilder oder CSS-Dateien lokal im Cache des Browsers vorliegen. Der Wert ist theoretisch die Zeit, bis das Layout im Browser fertig ist. Theoretisch, weil die Browser unterschiedliche Strategien für den Seitenaufbau verfolgen. Der Kunde sieht meist viel früher eine komplette Seite und im Hintergrund werden noch „Reste“ vom Browser geladen. Dieser Wert sollte für „Repeat View“ bei jedem Shop bei dem genannten Tool deutlich niedriger sein. Meist sind die Artikelbilder der wesentliche Bestandteil des gesamten Downloadvolumens und diese sowie CSS- und JS-Dateien werden lokal im Browsercache gespeichert, wenn dieser aktiv ist. Das ist er normalwerweise. Benutz man die DeveloperTools, sollte man ihn deaktivieren. Dann meckert Pagespeed bei schönen Artikelbildern eigentlich immer über deren Größe. Das kann man bei einem Onlineshop nur sehr schlecht beeinflussen und eine maximale Kompression bedeutet nicht unbedingt maximale Schönheit und Verkauf. Außerdem sind die Einsparpotenziale oft nahezu lächerlich, wenn man auf die absolute Dateigröße schaut. Prozentual hört sich dies immer toll an. Die Browser-Caching Zeiten sind bei Google Pagespeed ebenfalls oft ein Thema. Allerdings bemängelt das Tool oft auch den Google+ Button & Co. Das kann man nicht wirklich beeinflussen. [quote=„Jochen Baumberge“]@fittken: Schau Dir bitte bei dem WebPagetest mal die Details an. Ein 404-Fehler wird dort an einer Stelle angezeigt.[/quote] Das ist einer der „Schatten“, der im Standard-Template von Shopware als Background-Image verwendet wird. Im CSS müsste noch background-image: none an der entsprechenden stelle gesetzt werden. Das hat auf der anderen Seite keinen wirklichen Einfluss auf die Ladegeschwindigkeit
2 „Gefällt mir“
Vielen Dank für die Antworten, war schon einiges hilfreiches dabei! Der Http-Cache war nicht aktiv, den habe ich nun aktiviert. PHP war auch noch 5.3, habe jetzt auf die Version 5.6.5 GRC (Opcode & APCu) umgestellt. Ist das auch der ByteCache Code mit ZendOpcache + APCu? Oder ist da etwas anderes mit gemeint? Es wäre super, wenn ihr jetzt nochmal drüber schauen könntet.
Hallo ich habe auch gerade mal den Test mit webpagetest gemacht -> Your text to link here… Was mich an der ganzen Sache stutzig macht sind die unteren Einträge, die auch bei Chrome Entwicklertool zu sehen sind, aber im reinen Seiten-Quelltext gar nicht vorhanden sind. Wo kommt der “Müll” denn her? http://d.adroll.com/cm/g/in?google_ula= http://d.adroll.com/cm/f/out http://ads.yahoo.com/cms/v1?esig=1 http://x.bidswitch.net/ul_cb/sync?dsp_id http://cm.g.doubleclick.net http://www.googleadservices.com/pagead/conversion_async.js https://analytics.twitter.com/i/adsct?p_user_id= http://www.googletagmanager.com/gtm.js?id Oder sind das externe Zugriffe auf meine Seite und haben die Einfluss auf die Ladezeit?
[quote=„body62“]Was mich an der ganzen Sache stutzig macht sind die unteren Einträge, die auch bei Chrome Entwicklertool zu sehen sind, aber im reinen Seiten-Quelltext gar nicht vorhanden sind. Wo kommt der „Müll“ denn her? http://d.adroll.com/cm/g/in?google_ula= http://d.adroll.com/cm/f/out http://ads.yahoo.com/cms/v1?esig=1 http://x.bidswitch.net/ul_cb/sync?dsp_id http://cm.g.doubleclick.net http://www.googleadservices.com/pagead/conversion_async.js https://analytics.twitter.com/i/adsct?p_user_id= http://www.googletagmanager.com/gtm.js?id [/quote] Das sind höchstwahrscheinlich Ressourcen, die per JavaScript nachgeladen werden (d.h., die sind irgendwo in Deinem JavaScript versteckt, weshalb Du sie nicht im normalen HTML-Quelltext siehst).
1 „Gefällt mir“
[quote=“body62”]Hallo ich habe auch gerade mal den Test mit webpagetest gemacht -> Your text to link here… Was mich an der ganzen Sache stutzig macht sind die unteren Einträge, die auch bei Chrome Entwicklertool zu sehen sind, aber im reinen Seiten-Quelltext gar nicht vorhanden sind. Wo kommt der “Müll” denn her? http://d.adroll.com/cm/g/in?google_ula= http://d.adroll.com/cm/f/out http://ads.yahoo.com/cms/v1?esig=1 http://x.bidswitch.net/ul_cb/sync?dsp_id http://cm.g.doubleclick.net http://www.googleadservices.com/pagead/ … n_async.js https://analytics.twitter.com/i/adsct?p_user_id= http://www.googletagmanager.com/gtm.js?id Oder sind das externe Zugriffe auf meine Seite und haben die Einfluss auf die Ladezeit?[/quote] TimmeHosting hat mit dem Javascript Hinweis natürlich recht. Als kleine Zusatzinfo, um die Ursachen zu finden, wenn gewünscht: Adroll, doubleklick, yahoo sind die Retargeting/Werbeprogramme, die auf der Seite vom Shopbetreiber integriert wurden. Analytics.twitter ist wahrscheinlich selbsterklärend bei dem Namen, auch vom Shopbetreiber integriert worden. Das sind alles Programme, die meiner Ansicht nach in der Datenschutzerklärung auftauchen müssen. GoogleTagmanager ist für Structured Data bei RichSnippets und von Google. Wäre überflüssig, wenn man das Template “vernünftig” ergänzt oder sich mit den veralteten Standards von dem emotion-Templates begnügt. Grundsätzlich kann jedes der Skripte Einfluss auf die Geschwindigkeit des Seitenaufbaus haben. Als Beispiel mal die SocialMedia-Buttons (Like ect.): Das Skript wird zwar so geladen, dass es keinen Einfluss auf die Ladegeschwindigkeit der eigentlichen Shopseite hat, aber es kann ein “Redraw” eines Teils der fertig gerenderten Webseite notwendig sein. Das sieht man natürlich, gerade auf langsameren Tablets. Die Javascripte werden normalerweise so programmiert und integriert, dass Sie ansonsten den Seitenaufbau nicht beeinflussen. Den Time-To-First-Byte-Werte beeinflussen diese auf keinen Fall!
[quote=“fittken”]PHP war auch noch 5.3, habe jetzt auf die Version 5.6.5 GRC (Opcode & APCu) umgestellt. Ist das auch der ByteCache Code mit ZendOpcache + APCu? Oder ist da etwas anderes mit gemeint?[/quote] Das ist so in Ordnung, für mehr Speed, müsstest Du das Paket wechseln. Schau noch mal unter /etc/php/php.ini nach, ob das memory-Limit auf min. 128 MB steht. Das ist für die Seite so ausreichend. Oder schau in den System-Informationen im Shopware Backend, dort steht es auch und ist wahrscheinlich einfache zu finden.
[quote=“hth”] Adroll, doubleklick, yahoo sind die Retargeting/Werbeprogramme, die auf der Seite vom Shopbetreiber integriert wurden. Analytics.twitter ist wahrscheinlich selbsterklärend bei dem Namen, auch vom Shopbetreiber integriert worden. Das sind alles Programme, die meiner Ansicht nach in der Datenschutzerklärung auftauchen müssen. GoogleTagmanager ist für Structured Data bei RichSnippets und von Google. Wäre überflüssig, wenn man das Template “vernünftig” ergänzt oder sich mit den veralteten Standards von dem emotion-Templates begnügt. Grundsätzlich kann jedes der Skripte Einfluss auf die Geschwindigkeit des Seitenaufbaus haben. Als Beispiel mal die SocialMedia-Buttons (Like ect.): Das Skript wird zwar so geladen, dass es keinen Einfluss auf die Ladegeschwindigkeit der eigentlichen Shopseite hat, aber es kann ein “Redraw” eines Teils der fertig gerenderten Webseite notwendig sein. Das sieht man natürlich, gerade auf langsameren Tablets. Die Javascripte werden normalerweise so programmiert und integriert, dass Sie ansonsten den Seitenaufbau nicht beeinflussen. Den Time-To-First-Byte-Werte beeinflussen diese auf keinen Fall![/quote] Danke für eure Antworten. Ja genau das ist ja mein Problem, da ich der Shopbetreiber bin und ich den Shop selbst aufgesetzt habe und kein anderer am Code rankommt. z.B der GoogleTagmanager ? da hätte ich ja den Code ins Template (header.tpl) einbauen müssen, ist aber nicht passiert und auch nichts drin Die Richs RichSnippets sind fest ins mein Template von mir eingebaut, kein Plugin. Adroll, doubleklick, yahoo darüber zerbreche ich mir den meisten Kopf. Das einzige was ich an Sripte eingefügt habe ist eines von Bonusbox und Veinteractive Von Veinteractive ist der Script aber auf den produktiven Shop mit auskommentiert und dieser läuft nur im meinem Test-Shop. Mit diesem Script sollte sich ein PopUp-Fenster öffnen wenn ein Kunde was im im Warenkorb hat und das Fenster schließt, hat aber schon ausgelöst wenn der Versandkostenrecher im Warenkorb benutzt wurde. Ich werde mal im Testshop ein original Template nehmen und mal schauen ob die Plagegeister dann weg sind. Oder es ist eines von den Zahlungsplugins.
[quote=„body62“][quote=„hth“] Adroll, doubleklick, yahoo sind die Retargeting/Werbeprogramme, die auf der Seite vom Shopbetreiber integriert wurden. Analytics.twitter ist wahrscheinlich selbsterklärend bei dem Namen, auch vom Shopbetreiber integriert worden. Das sind alles Programme, die meiner Ansicht nach in der Datenschutzerklärung auftauchen müssen. GoogleTagmanager ist für Structured Data bei RichSnippets und von Google. Wäre überflüssig, wenn man das Template „vernünftig“ ergänzt oder sich mit den veralteten Standards von dem emotion-Templates begnügt. Grundsätzlich kann jedes der Skripte Einfluss auf die Geschwindigkeit des Seitenaufbaus haben. Als Beispiel mal die SocialMedia-Buttons (Like ect.): Das Skript wird zwar so geladen, dass es keinen Einfluss auf die Ladegeschwindigkeit der eigentlichen Shopseite hat, aber es kann ein „Redraw“ eines Teils der fertig gerenderten Webseite notwendig sein. Das sieht man natürlich, gerade auf langsameren Tablets. Die Javascripte werden normalerweise so programmiert und integriert, dass Sie ansonsten den Seitenaufbau nicht beeinflussen. Den Time-To-First-Byte-Werte beeinflussen diese auf keinen Fall![/quote] Danke für eure Antworten. Ja genau das ist ja mein Problem, da ich der Shopbetreiber bin und ich den Shop selbst aufgesetzt habe und kein anderer am Code rankommt. z.B der GoogleTagmanager ? da hätte ich ja den Code ins Template (header.tpl) einbauen müssen, ist aber nicht passiert und auch nichts drin Die Richs RichSnippets sind fest ins mein Template von mir eingebaut, kein Plugin. Adroll, doubleklick, yahoo darüber zerbreche ich mir den meisten Kopf. Das einzige was ich an Sripte eingefügt habe ist eines von Bonusbox und Veinteractive Von Veinteractive ist der Script aber auf den produktiven Shop mit auskommentiert und dieser läuft nur im meinem Test-Shop. Mit diesem Script sollte sich ein PopUp-Fenster öffnen wenn ein Kunde was im im Warenkorb hat und das Fenster schließt, hat aber schon ausgelöst wenn der Versandkostenrecher im Warenkorb benutzt wurde. Ich werde mal im Testshop ein original Template nehmen und mal schauen ob die Plagegeister dann weg sind. Oder es ist eines von den Zahlungsplugins.[/quote] Die Javascriptaufrufe sind wahrscheinlich durch ein Plugin eingefügt worden, wenn Du es nicht selber gemacht hast. Dann sind die natürlich auch im Emotion-Template vorhanden. Entfern halt mal die Bonusbox-Integration und schau, ob die weg sind. kann sein, dass die auf verschiedene Techniken für ihr System setzen.
1 „Gefällt mir“
So ich habe den Übeltäter gefunden. Es war tatsächlich Bonusbox, aber nicht er eigentliche Code, der sich ja nur auf der Seite befindet bei der der Kauf abgeschlossen ist, sondern das bonusbox-Buttons den ich in einer Footer-Box intigriert hatte. Den Code hatte ich von Bonusbox zur Verfügung gestellt bekommen und es ist eigentlich eine Frechheit von denen mir so ein Haufen Müll an den Hals zu hängen. Diesem Button ist ein Script und der Link zur Seite an gehangen, die ich jetzt löschen werde. Edit: Habe nun durch die Entfernung des Skripts die Requests von 72 auf 45 auf der Startseite reduzieren können. Danke für eure Hilfe, allein wäre ich da nicht drauf gekommen.
Hallo, Shopware hat mir zum Thema PHP folgendes geschrieben: ,Die PHP Version 5.6.5 ist im Moment noch nicht optimal für den Betrieb mit Shopware da es noch keinen APCu und Ioncube für die 5.6 Version gibt. Es sollte solange noch im PHP Versionzweig 5.5.x geblieben werden." Wie seht ihr das? Viele Grüße!
1 „Gefällt mir“
[quote=„hth“] Bleib auf 5.5 [/quote] Ok danke hth! Habe jetzt 5.5 inkl. GRC (Opcode & APCu) installiert, hoffe das passt? Oder ohne GRC (Opcode & APCu)? [quote=„hth“] Das ist so in Ordnung, für mehr Speed, müsstest Du das Paket wechseln. Schau noch mal unter /etc/php/php.ini nach, ob das memory-Limit auf min. 128 MB steht. Das ist für die Seite so ausreichend. Oder schau in den System-Informationen im Shopware Backend, dort steht es auch und ist wahrscheinlich einfache zu finden.[/quote] In der php-ini steht als Limit 256 MB. In der Shopware Systeminfo allerdings 2048MB. Was passt nun? Zumal das Paket bei Mittwald ja 4GB Arbeitsspeicher hat. Müsste ich das dann nicht hoschrauben? Viele Grüße!