Hallo zusammen, in Google Analytics bekomme ich immer wieder Ladezeiten zu verschiedenen Artikeln angezeigt die weit über 10 Sek. liegen. In der Error.log oder Access.log steht aber leider nichts auffälliges drin… Z.B. handelt es sich um diese URL http://www.notenshop-plus.de/piano-gefa … en/id_5553 Die Ladezeit liegt bei 45,63 Sek.! In einigen Fällen konnte ich in der Access.log sehen, dass aus Österreich von einem Smartphone zugegriffen wurde. Meine Vermutung ist daher, dass man in den Bergen einen schlechten Empfang hat… Kann das aber einem die Statistik versauen? Und ist die Ladezeit in Google Anayltics überhaupt wichtig? Oder kann man das vernachlässigen? Es ist nur so, dass solche Werte mich schon nachdenklich machen.
Hat jemand eine Erkläung dafür? Im nächsten Schritt werden wir Pagespeed aktivieren. Das wird einen enormen Gewinn bringen. Aber vorher hätte ich gerne noch gewusst, was es mit den Ladezeiten auf sich hat. Das sieht doch nach einem oder mehreren Fehlern aus… Grüße Mathias
[quote=„mbdus“]"(…) Die Ladezeit liegt bei 45,63 Sek. (…) In einigen Fällen konnte ich in der Access.log sehen, dass aus Österreich von einem Smartphone zugegriffen wurde. Meine Vermutung ist daher, dass man in den Bergen einen schlechten Empfang hat. (…) Hat jemand eine Erkläung dafür? (…)"[/quote] Hallo Mathias, am Empfang muß es nicht liegen. Analysiere die Website mal bei Google mit PageSpeed Insights. Wie Google diese Seite „above the fold“ sieht (wenn man die Seite über Smartphone oder Desktop-Computer aufruft) und welche Inhalte die Geschwindigkeit beeinträchtigen, dass erklärt diese schnelle Analyse. Und Vorschläge zur Verbesserung der Seite werden auch gleich gemacht: - Mobil-Analyse - Desktop-Analyse Deine PageSpeed-Bewertung erreicht bei dieser Seite leider nur 34 bzw. 42 von 100 Punkten. 
Da ist noch Luft nach oben. Mehr Infos zu PageSpeed Insights auch hier. Gruss Jochen
Die 1% der Österreicher die in den Bergen lebt, haben wahrscheinlich nicht mal ein Handy 
Danke für Eure Antworten! Pagespeed werden wir auf jeden Fall als Servermodul aktivieren. Im Moment haben wir es aber absichtlich deaktiviert, um Fehler besser finden zu können. Und diese 45,63 Sek. sehen nach einem wirklich krassen Fehler aus…
Hallo, heute habe ich mal einen Google PageSpeed Insights Test gemacht und war ziemlich erschrocken über das Ergebnis :shock: Die Werte möchte ich hier gar nicht kommentieren, was aber übel auffällt ist, dass der javascript/css Test nicht wirklich gut ist. Hier wird moniert (im übrigen auch bei yslow), dass: “JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten “above the fold” (ohne Scrollen sichtbar) beseitigen Ihre Seite enthält 6 blockierende Skript-Ressourcen und 8 blockierende CSS-Ressourcen. Dies verursacht eine Verzögerung beim Rendern Ihrer Seite. Keine der Seiteninhalte “above the fold” (ohne Scrollen sichtbar) konnten ohne Wartezeiten für das Laden der folgenden Ressourcen gerendert werden. Versuchen Sie, blockierende Ressourcen zu verschieben oder asynchron zu laden, oder laden Sie kritische Bereiche dieser Ressourcen direkt inline im HTML.” Von den 6 javascripts sind 3 Standard von Shopware, von den css sogar 6. Da ist doch sicher auch noch Luft nach oben seitens Shopware drin, abgesehen davon, dass man da selbst noch was in Richtung Komprierung machen kann. Gruß
1 „Gefällt mir“
An Shopware liegt das above the fold nicht, dass ist eben Sache der Template Programmierung. Wenn man bspw. 10 verschiedene und eigenständige JS Files + 10 eigenständige CSS Dateien hat, darf man sich nicht wundern Aber allzuviel nimmt es auch nicht weg, aktuell lädt die Seite bei mir recht flott, da gibt es eigentlich nichts zu meckern
1 „Gefällt mir“
Danke für die Antworten! Serverseitig ist das Modul Pagespeed im Einsatz. Das bindet CSS- und Javascriptdateien zusammen. Eine weitere Bündelung ist nicht möglich… Aber asynchrones Laden der Dateien hört sich gut an. Danke!
above the fold heisst eigentlich nichts anderes, als das du die nötigen CSS Anweisungen direkt im header lädst. Aber nur die CSS Anweisungen, welche dafür zuständig siehst, was du als erstes auf der Seite siehst. Bspw. sieht man generell den Footer nicht, dieser wird also auch erst garnicht direkt im head eingebunden. Smashingmagazine ist ein ganz gutes Beispiel, die haben es hinbekommen ganze 100 Punkte rauszuholen http://www.smashingmagazine.com/
2 „Gefällt mir“
Danke für die Erklärung. Im Moment ist das Hauptproblem die schwankende Ladezeit im Google Webmaster Tool durch den Google Bot. An einem Tag ist die Ladezeit gut und am nächsten Tag schlecht. Das könnte man hoffentlich mit asynchronem Laden der Javasriptdateien verbessern. CSS-Dateien dürften dabei nicht so ins Gewicht fallen. Above the fold ist natürlich auch wichtig für den Shopbesucher. Das sollte aber nichts mit dem Google Bot Problem zu tun haben. Nochmals Danke für den Tipp!
[quote=“mbdus”]Danke für die Erklärung. Im Moment ist das Hauptproblem die schwankende Ladezeit im Google Webmaster Tool durch den Google Bot. An einem Tag ist die Ladezeit gut und am nächsten Tag schlecht.[/quote] Das liegt an deinem Server. Die GWT zeigen TTFB an. Das ist nur das erste Byte der ersten Datei in dem network-Panel der Developer Tools und reflektiert die Zeit, die Shopware für die Berechnung benötigt. Die Javascript-Dateien haben damit nichts zu tun. Wahrscheinlich liegen bei den kurzen Ladezeiten die Dateine im http-Cache von Shopware und bei den längeren nicht. Die anderen “Cache-Systeme” von Shopware oder php haben auch noch Auswirkungen.
1 „Gefällt mir“
Ja, aber auch wenn ein Artikel nicht im Cache liegt, dürfte die Ladezeit nicht so hoch sein. Das werde ich aber mal beobachten. Das würde aber auch bedeuten, dass man den Cache im Backend nicht löschen darf. Oder wenn man etwas verändert hat (z.B. einen neuen Artikel eingestellt), dieser sofort in den Cache müsste.
[quote=“mbdus”]Ja, aber auch wenn ein Artikel nicht im Cache liegt, dürfte die Ladezeit nicht so hoch sein.[/quote] Diese ultra-lange Ladezeit konnte ich von Anfang an nicht nachvollziehen bei dir. Wenn man ein langsames Hostingpaket hat, kann das aber schon in Richtung der 5-6 Sekunden gehen und mit http-Cache bei 350ms landen. In den Developertools sind häufig die Statistik-Module für eine Weiterzählen der Ladezeit verantwortlich, obwohl die Seite an sich bereits geladen ist. Dito für asynchron geladene Plugins. [quote=“mbdus”]Das würde aber auch bedeuten, dass man den Cache im Backend nicht löschen darf. Oder wenn man etwas verändert hat (z.B. einen neuen Artikel eingestellt), dieser sofort in den Cache müsste.[/quote] [quote=“mbdus”]Das ist so auch so, wenn man die höchste Performance erreichen möchte. Das ist schließlich das Grundprinzip eines Caching-Servers. Wenn man dem Cache sagt, die Lebenszeit der Dateien ist abgelaufen, müssen die neu berechnet werden. Allerdings pendelt sich das eigentlich in den GWT aus. Die bilden ja immer einen Durschnittswert. Abgesehen davon, muss man aufpassen, dass das GooglePagespeed-Modul nicht alle Lizenzkommentare aus den JS- und CSS-Dateien löscht!
[quote=„hth“]Wahrscheinlich liegen bei den kurzen Ladezeiten die Dateine im http-Cache von Shopware und bei den längeren nicht. Die anderen „Cache-Systeme“ von Shopware oder php haben auch noch Auswirkungen.[/quote] Sorry, dazu habe ich nochmal eine Frage. Was ist wenn ich einen neuen Artikel anlege, einen Artikel ändere oder sonstige Änderungen am Shop mache? Wie gehe ich da am sinnvollsten vor? Da muss man doch den Cache löschen? Zu den Webmaster Tools: Wie bekomme ich einen linearen Graphen ohne Schwankungen bei den Ladezeiten hin? Eine neue Seite kommt dazu. Diese liegt noch nicht im Cache. Das wäre doch dann ein Problem… Dazu fällt mir nur ein, dass ich einen eigenen Crawler laufen lassen müsste, der meinen Shop im Cache hält… Das asynchrone Laden der Javascript-Dateien funktioniert leider nicht, da diese für den Aufbau der Seite benötigt werden…