Neu Google PageSpeed Insight

[karabey]

Hey,

Hab heute bemerkt das Google Pagespeed Insight neue Werte über eine Webseite ausliefert.
Ich habe mehr Probleme derzeit mit JTL Shop 4 als mit den Pagespeed zuvor.

Könnte man gewissen Sachen nicht schon tief im System verankern damit es im Shop 5 nicht zu diesen Problemen führt?
Ich hänge die Screenshots vom Shop 4 für ein Übersicht was die Fehler so sind.

https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://electronics.semaf.at
[Bild entfernt]

 

[hula1499]

Mobile 17 ist natürlich echt grottig, da gibts nix zu beschönigen.

Hier kann aber JTL zb. bei den millionen Bildern (vorallem bei der Grösse, 268kb ist halt schon ein Hammer) halt auch nicht machen. Auch nicht, wenn du XX Plugins oder so verwendest (da gibts massenhaft css/js die halt von unterschiedlichen Plugins kommen.) Löblich, das die Bilder vom einem CDN/Subdomain ausgeliefert werden.
Das endloss-scrollen bzw. erst nachladen wenn es in den sichtbaren Bereich kommt, ist halt keine Funktion die Evo kann.

WebP wird nur einfach promoted von G - das hat 0 relevanz, derzeit.

ubm.css sagt mir nix, aber die lpa-login...kommt halt vom Ama Plugin.
Mich nervt das auch gewaltig, dass alle SP/Pluginersteller ihre eigene js/css direkt einbinden (könnte man ja auch über die bestehenden jtl shop js/css einbinden, minify etc).

DOM Knoten -> wertlose anzeige.
(Alles meine pers. Meinung!)

Mir gefällt die neue Berechnung, hatte auch letzte Woche getestet. Bei uns: 87/100

 

[MichaelH]

Ich bin mit meinen 67/100 erst erschrocken, aber als ich dann andere mir bekannte Shop4 testete und dort 29/100 und 19/100 rauskam, war ich wieder etwas beruhigt.
Super ist es aber hin wie her nicht.

 

[hula1499]

67/100 ist doch bitte eh auch super, wird ja auch viel nonsense bewertet.

 

[MichaelH]

Jein, so lange Google zusammenfasst als "langsam" ist das kein Lob und das mit Root-Server + SSD wo ich sagen kann: An der Hardware liegt es nicht.

 

[hula1499]

Wir haben auch einen dicken managed (der sich langweilt) und er meint, via mobile wäre es angeblich langsam...egal mit welchen smartphone und 3g/4g und leerem cache und firefox als browser am smartphone und tablet, da ist nix langsam, keine Ahnung was da sein Problem angeblich ist... 67 ist super, nicht verrückt machen (lassen)

 

[FMoche]

100 (auf dem Desktop) bzw. 9x (mobil) sind mit Shop5 offenbar möglich:
Startseite: https://developers.google.com/speed...l=de&url=https://shop5.moches.de/&tab=desktop
Artikel: https://developers.google.com/speed...//shop5.moches.de/Standardartikel&tab=desktop
Kategorie: https://developers.google.com/speed...rl=https://shop5.moches.de/Farben&tab=desktop

Hängt halt viel von Bildern und Plugins ab - aber der Shop selbst erlaub hohe Wertungen.

 

[css-umsetzung]

Interessant ist hier, die Seite Farben hat einen ttfb von 69ms, das jtl3.js hat einen ttfb von 266ms

 

[MichaelH]

Na dann freuen wir uns auf Shop5 und hoffen das Template muss nicht komplett neu gemacht werden.

 

[peterwill]

Hallo jetzt freitag 21.58 hat die Seite Farben hat einen ttfb von 161ms, das jtl3.js hat einen ttfb von 395ms
Bin mal gespannt was er für Werte hat mit plugins und vielen Kategorien / Bildern in vergleich zum Shop 4.
Schon jemand mal was getestet?

 

[Stephan K.]

100 (auf dem Desktop) bzw. 9x (mobil) sind mit Shop5 offenbar möglich:
Startseite: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/&tab=desktop
Artikel: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/Standardartikel&tab=desktop
Kategorie: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/Farben&tab=desktop

Hängt halt viel von Bildern und Plugins ab - aber der Shop selbst erlaub hohe Wertungen.

Uff, Moches.de ist aber ein ziemlicher "basic" Shop mit 12 kleinsten Bildchen und Null hübscher Optik. Also ziemlich "out of the box" ohne Inhalte. Das kann der Shop4 so auch.
Wenn ich von deiner Seite einen Artikel am Desktop aufrufe, dauert es drei Sekunden, bis alles fertig geladen ist. Also nicht wirklich berauschend. Und das bei "billigsten" Bildern. Also einem Bild, ein paar Widgets, etc.

Das Problem bei den JTL-Shops sind die alten JavaScript-Implementierungen, die nicht alles einmalig laden, sondern bei den zigfachen Nachladungen der vielen Skripte immer wieder alles neu berechnen. Das gibt der jtl3.js eine so lange Ladezeit. Hauptseite Laden, weiteren Inhalt laden (Banner), neue Gesamt-Dimensionen berechnen, weiteren Inhalt laden (Bestseller), neue Dimensionen berechnen, etc.
Das wird heute teilweise insgesamt anders (relativ und nicht absolut) gemacht.

Das zum einen und zum anderen müsste man eben eine Subdomain für Mobile-Pages mit kleineren Bildern haben. Hier geht es ja um die langen Ladezeiten, wenn man 12 Bilder mit 100 kb auf der Startseite hat. JavaScript spielt natürlich ebenso eine Rolle.
Man kann sehr vieles - wie Amazon - verspätet laden lassen, aber das ist auch nicht der Weisheit letzter Schluss.
Dynamisches Nachladen beim Scrolling ist auch ein Faktor.

Es gibt relativ viele Techniken, wie man den Shop beschleunigen kann (max, Abfragegröße für externe Plugins, Skripts, etc.), aber alles hat ein Limit, wenn man nicht sehr viel Geld in eine Neuentwicklung der JS-Basis investieren möchte. Die dann auch noch nach jedem Update...

Aber: Es gibt Entwicklungen, die in ein paar Jahren viele der Probleme beseitigen werden. Mobiles Internet wird schneller (überall?) und somit der mobile PageSpeed nicht mehr so relevant. Es gibt Webseiten-Code, der nichts mehr berechnen muss, sondern vorab alles in Maschinensprache ausliefert, etc. Auch mit PHP 7.4 wird sehr viel Code vorab berechnet und im Server Cache vorgehalten. Das beschleunigt kleinste Abfragen am allermeisten und startet nicht jedes Mal eine Code-Ausführung.

Aber ja. Es ist schon ein Kampf mit dem JTL-Shop.

 

[karabey]

100 (auf dem Desktop) bzw. 9x (mobil) sind mit Shop5 offenbar möglich:
Startseite: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/&tab=desktop
Artikel: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/Standardartikel&tab=desktop
Kategorie: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://shop5.moches.de/Farben&tab=desktop
Hängt halt viel von Bildern und Plugins ab - aber der Shop selbst erlaub hohe Wertungen.

@FMoche
Das ist eher ein unfairer Vergleich wie von Fahrzeug Herstelle Angaben "Nur 4 Liter Benzin im Stadt".
Mal ordentlich Daten auffüllen und bitte erst dann die Bewertungen anzeigen

Startseite: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://electronics.semaf.at
Kategorien: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://electronics.semaf.at/raspberry-pi-computers
Artikel: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://electronics.semaf.at/Adafruit-DC-Stepper-Motor-HAT-for-Raspberry-Pi-Mini-Kit

@Stephan K.
Wenn schon ein Subdomain für die mobile Seiten existieren soll, wieso nicht gleich Google AMP überlegen?
JTL sollte sich überlegen das alle Plugins ausnahmslos unter einer JS / CSS gesammelt wird. Damit keine doppelte IDs / Klassen existieren, könnte man für Entwickler vielleicht eine Testumgebung erstellen und ein Datenbank um es zu vermeiden.

Du hast Recht mit dem JTL Shop kampf. Wir überlegen ehrlich gesagt ein weiteres Shop zu öffnen aber nicht JTL Shop 4 aber kompatibel zur JTL Wawi.
Eventuell Shopify mit Connector, wenn der Connector mal funktioniert.

 

[FMoche]

Deswegen hatte ich das ja relativiert: "Hängt halt viel von Bildern und Plugins ab"-

 

[hula1499]

Wenn ihr endlich eure SP dazu erzieht, nicht alle ihr eigenes Süppchen zu kochen und eigenständig dauernd js/css haben/aufrufen zu wollen...

Aber ja, natürlich stimmt die Aussage, dass viel vom Template, Plugins und den Bildern abhängt und ihr da eigentlich wenig dafür könnt, wenn viele Seiten überladen sind oder mit >200 requests daherkommen

 

[FMoche]

Mehr als die Bestpractices in den Schulungen und unseren Beispielplugins zu vermitteln und in den zertifizierten Plugins zu zu fordern können wir auch nicht tun.
Zumal wir ja nun auch die wenigsten Plugins von SPs einsetzen. Das hängt somit dann leider am Kunden.

 

[css-umsetzung]

Wenn ihr endlich eure SP dazu erzieht, nicht alle ihr eigenes Süppchen zu kochen und eigenständig dauernd js/css haben/aufrufen zu wollen...

Wir sind alle gut erzogen
Es gibt eigentlich eine klare Vorgabe wie das css und js eingebunden werden soll, das machen auch fast alle gleich aber es geht eben nicht immer.

 

[martinwolf]

Mobile keine 9xer aber dafür ist es ein repräsentatives Beispiel eines produktiven Shops wie er in freier Wildbahn auch mal vorkommt. Und man muss nicht immer auf eine neue Shopversion warten

Startseite: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/&tab=mobile
Kategorie: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/Hula-Hoop_1&tab=mobile
Artikel: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/Hoopomania-Might-Hoop-Schaumstoff-Hula-Hoop-2kg&tab=mobile

 

[karabey]

Mobile keine 9xer aber dafür ist es ein repräsentatives Beispiel eines produktiven Shops wie er in freier Wildbahn auch mal vorkommt. Und man muss nicht immer auf eine neue Shopversion warten

Startseite: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/&tab=mobile
Kategorie: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/Hula-Hoop_1&tab=mobile
Artikel: https://developers.google.com/speed/pagespeed/insights/?url=https://www.hula-hoop-shop.eu/Hoopomania-Might-Hoop-Schaumstoff-Hula-Hoop-2kg&tab=mobile

1A! Wieviel Stunden stecken da drinnen damit das so optimal läuft?

 

[martinwolf]

1A! Wieviel Stunden stecken da drinnen damit das so optimal läuft?

Das kann dir hula1499 vermutlich eher beantworten. Die Maßnahmen die abweichend vom Standard vorgenommen wurden sind aber soweit ich das weiß:

- nachträgliche Kompression der bereits minified jtl3.js
- jquery und migrate in einer Datei zusammengefasst und nachträglich komprimiert
- Auslieferung der Bilder und Ressourcen (JS/CSS) über ein CDN

 

[hula1499]

Hm, so recht kann ich das auch nicht mehr 100% sagen:

.) alles was irgendwie geht (nervig ist die includes/libs/xajax_0.5_standard/xajax_js/xajax_core.js ) zusammenfassen in wenige Datein (ressources!) und direkt via CDN ausliefern (produkt-bilder, css, js, eigentlich auch alle andren bilder wie payment, versand etc). Ohne dem asset zeug arbeiten, datein direkt erstellen und speichern
.) alles nochmal komprimieren (auch die plugin css/js) da die alle nur auf Lesbarkeit aus sind (schwachsinn, die SP können ihre lesebare version am rechner haben, aber die ausgelieferten sollen komprimiert sein, zumind. die js, dort haben wir eigentlich eh nix zu suchen) -> vorbildlich wäre hier eine plugin.css (komprimiert) und eine plugin_original.css (kostet jeden SP 30 Sek. arbeit und erspart dem Internet / Kunden 20-50% an Dateigrösse und somit Ladezeit).
.) weniger ist mehr prinzip -> nicht viel schnick schnack auf der Seite (verzicht von Bannern, Slidern und so ein Zeug) - ich bekomm immer alle Zustände, wenn ich Shops sehe, die Sliderbanner mit 1MB oder so haben, pro Slide versteht sich
.) Bilder versucht in einer akzeptablen quali aber mit (meist) geringstmöglichen grösse
.) verzicht auf 5 millionen boxen wie: kauften auch, bestseller, könnte interessieren, hast du nicht gesehen, viell. interessant für dich... bla bla bla

Ich bin da sicher sehr eigen und kann einiges auch nicht so wirklich erklären. Die oberste und wichtigste Regel für mich ist: UX, speed und, oh welch wunder, Abschluss.
Ob mich das Komprimieren nervt (weils andre nicht von Haus aus schon machen!) ist nebensächlich. Auch bei jeder kleinen Änderung muss alles am CDN angepasst werden etc, ist so - der Kundenspeed ist wichtiger.

Probleme:
includes/libs/xajax_0.5_standard/xajax_js/xajax_core.js
dropper (der wird jedoch vermutlich eh abgelöst in Kürze)
lpa zeug

Hätte ich mehr Wissen (oder überhaupt Ahnung) von html/php wär doch noch einiges mehr möglich.

Jetzt krieg ich von einigen SP und Templateentwicklern gleich wieder eine am Deckel weil weil weil...hab breite Schultern, geht schon