Neu Plugin JTL Speed Optimizer verfügbar

[saw]

Ah, danke, hätte ich auch selbst testen können, mache ich in Zukunft

 

[gboehm]

dann stell sich aber doch die Frage nach der Sinnhaftigkeit dieser oder jener Messungen. Mit den Dev-Tools erhalte ich selbst one Optimizer einen Performance Score von 100. Mit Pagespeed waren es sonst so um 45
Oder gilt, wer viel misst misst Mist?

 

[eRock Marketing]

Nein,

aber die Audits sollten angepasst werden.
Grundlegend geht es ja häufig um die Mobile Optimierung - Desktops PCs haben meist eine schnelle Leitung und sind auch in der Power häufig ausreichend (wir reden ja von Webseiten und nicht Video-Rendering oder ähnliches).

Daher sollten die Audits (Pagespeed insights macht es ja auf 2 Lösungen) angepasst werden.
um die Pagespeed Insights Daten nachzuahmen geht es in etwa so:


Sprich: Auf Mobile stellen, Als Audit den Performance Audit wählen und auf 3G stellen (so bemisst Google nach eigenen Aussagen die mobile Geschwindigkeit), sowie Cache leeren aktivieren.

Ohne Optimizer kommt da bei Sannes Stickdesign derzeit raus:

 

[gboehm]

Ah, OK. hatte zwar auf "Mobile" aber "no throttling" stehen

 

[saw]

Was mir noch arg fehlt und die sind wohl nicht in der sitemap, sind Seiten die über Artikelmerkmale generiert werden. Davon haben wir eine ganz schöne Menge um praktische Filter anzubieten. Die Seiten werden auch viel abgerufen. Mal ein Beispiel:
https://www.softairwelt.de/Softair-AEG-Vollauto

Und was mir auch noch fehlt sind die "Besonderen Produkte" wie neu im Sortiment, Sonderpreise usw.. Die werden auch sehr viel geklickt.

Schubs

 

[eRock Marketing]

Wir sind hier an einer Lösung dran.

Als kleine Vorschau die Punkte für die aktuell geplante nächste Version (nicht bindend, aber sehr wahrscheinlich):

- JS nicht abrufbare Dateien automatisch ausschließen! (file_get_contents === false)
- Config Sitemap+URL Liste gleichzeitig
- Alternativ: Lösung via SEO URLs aus DB
- Einzelne URL Optimieren starten
=> checken ob der Optimizer den Aufruf kennt (ist es ein Admin?)
- Check Mod Pagespeed by Google! Info im Plugin ausgeben machbar?
- Elemente für kritisches CSS entfernen (z.B: Footer)

Sehr spartanische Ausführung, liegt an Copy+Paste aus der Liste hier

 

[saw]

Nochmal zur Sitemap und dem abarbeiten.
Ich stoße den Cron Morgens an und schaue welche Seiten er abarbeitet. Viele kann ich nicht erklären, heute waren es 160. Einige haben gestern neue "passende Artikel" bekommen, ein paar sind neu im Sortiment, einige haben Wareneingänge und die meisten anderen kann ich nicht erkennen warum.
Wie auch immer, manchmal merkt er neue Artikel nicht, so wie am 5.2.19, die hat er bis heute nicht bearbeitet.
Die Sitemap hat den Artikel, z.B:
<loc>https://www.softairwelt.de/G-G-ARP-556-ETU-S-AEG-schwarz</loc>
<image:image>
<image:loc>https://www.softairwelt.de/media/image/product/5505/lg/g-g-arp-556-etu-s-aeg-schwarz.jpg</image:loc>
</image:image>
<lastmod>2019-02-05T14:40:47+01:00</lastmod>
<changefreq>daily</changefreq>

oder den:
<loc>https://www.softairwelt.de/G-G-CM16-Combat-Machine-AEG-20-desert</loc>
<image:image>
<image:loc>https://www.softairwelt.de/media/image/product/5507/lg/g-g-cm16-combat-machine-aeg-20-desert.jpg</image:loc>
</image:image>
<lastmod>2019-02-05T13:20:13+01:00</lastmod>
<changefreq>daily</changefreq>
<priority>0.7</priority>
</url>

usw.. die sind alle nicht optimiert

Timestamp lastmod kommt hin.

 

[eRock Marketing]

Ich nehme mal eine Art Mini- Log mit auf, zumindest dass er sagt "Cronjob gestartet 07.02.2019 10:00 Uhr, letzter Start 06.02.2019 08:00 Uhr", dass man Anhaltspunkte hat, schaue es mir auch nochmal an und spiele es mal mit händischen Sitemaps nach. Kann mir das so nicht erklären woran das liegt dass er manche nicht macht, die aber in das Raster fallen.
Letztendliche Erklärung wäre "nur" dass hier an der Seite etwas hängt.
Aber auf "händisch" umstellen mit der URL-Liste speichert ja auch einen neuen Zeitstempel, daher ist das leider keine Lösung.
Mit der kommenden Version kann man aber einzelne URLs optimieren - das wäre dann auch mal ein Test wert, ob er bei den betroffenen URLs ggf. einfach auf einen ganz anderen Fehler kommt.

Danke.

 

[saw]

Wenn ich irgendwas testen soll/kann - Bescheid geben.

 

[eRock Marketing]

Will da ungern in den laufenden Prozess eingreifen um nicht noch mehr URLs zu verpassen - und bei den Datenmengen muss ja auch ein komplett neuer Crawl nicht zwingend sein.
Da ich die letzten Tage komplett zu war hängt es gerade etwas - bin in der "Aufholen"-Phase, wird aber bald kommen.
Dann mit der neuen Version gerne.

 

[saw]

Beim Swap von URL List und sitemap, und umgekehrt, hat das Plugin wohl noch Probleme es abzuspeichern.
Habe am Samstag eine größere URL Liste von Artikelattributen gemacht, auf URL umgestellt und gestartet. Alles gut.
Danach habe ich es wieder auf sitemap gestellt und gespeichert.
Sonntag Cron angestoßen und die URL Liste wurde wieder durch gearbeitet. Nanu.
Dann abarbeiten lassen, URL Liste gelehrt, gespeichert und wieder angestossen, Cron sagt "nichts zu tun"
Das habe ich nicht geglaubt, Cron gerade wieder angestoßen "Fehlermeldung" 3 (Das heisst wohl sowas wie Cron läuft noch.)
Cron abgebrochen, etwas gewartet und wieder angestoßen und plötzlich waren es etwas über 100 Shop-Seiten die durchliefen.
Irgendwie klemmt es da noch etwas.

 

[eRock Marketing]

Hallo und danke für das Feedback.

Folgendes "Problem".
Auch beim Modus "URL-Liste" speichert er das letzte "Startdatum" und beachtet das dabei im nächsten Lauf (für z.B: den Modus Sitemap.xml).
Das haben wir auf der ToDo und wird ebenfalls behoben (ist es wohl im aktuellen Stadium bereits, wenn ich den Kollegen richtig verstanden habe).

Der Status "3" hingegen besagt jedoch "Cronjob wurde beendet, für einen erneuten Durchlauf ist es noch zu früh" - Das ist die Zeit die in den Einstellungen eingestellt werden kann bis ein neuer Durchlauf erlaubt ist (Standard = 1 Stunde)

 

[peterwill]

Hallo wir sind begeistert !!!
Sicher wie saw schon schrieb gibt es noch hier und da was zu verbessern.
Aber endlich mal ein plugin was den schop nicht noch langsamer macht!!!!
Wie binde ich im Speed Plugin Livezilla oder piwik richtig ein?

 

[eRock Marketing]

Hallo,

vielen Dank für das tolle Feedback.
Bisher sind mir hier keine "Sonderkonfigurationen" bekannt zu den beiden Lösungen, sprich: Einfach so wie bisher auch.
Wenn das zu Probleme führt gerne melden, dann schaue ich es mir mal live an (einfach im Büro durchklingeln).

 

[swiss-sale.ch]

Hallo und guten Tag in die Runde

Wir sind begeistert vom Plugin und möchten dieses für unseren Outdoor Shop gerne einsetzen. Aktuell sind wir am testen, die Funktionalität und die Zugriffszeiten sehen vielversprechend aus.

Folgende Fragen zu den optimalen Einstellungen
- JTL Template: Soll die Komprimierung von JS und CSS deaktiviert werden?
- Dropper: Sollen Die CSS und JS Ressourcen eingebettet werden?
- Dropper: Sollen Javascripts verspätet geladen werden?
- Dropper (Flex Menu): Soll das Caching deaktiviert werden

Die Einstellungen vom Plugin haben wir auf Standard und derzeit läuft die Optimierung.

 

[eRock Marketing]

Hallo,

es freut uns natürlich, wenn wir auch euch mit dem Plugin ein Stück weiterhelfen können.

Direkt zu den Fragen:

JS/CSS Komprimierung
Die würde ich aktiv lassen, wenn es eine nicht optimierte Seite gibt, wird diese so wenigstens noch mit zusammengefassten JS/CSS Dateien ausgeliefert. Einer optimierten Seite ist das egal und es werden keine extra Ressourcen verbraucht, da die Lösung für komprimierte CSS/JS Dateien nur "gefordert" wird, wenn diese Dateien aufgerufen werden - das werden Sie bei den optimierten Seiten nicht mehr

Dropper
Einfach belassen wie es ist, der Optimierer schneidet es sich sowieso zusammen. Durch eine Priorität wird die Optimierung immer nach den Dropper Sachen ausgeführt, sodass diese mit optimiert werden.

 

[eRock Marketing]

Hallo,

sorry für die diesmal längere Wartezeit, das hat aber auch seinen Grund.
Ich bin derzeit mit den Kollegen dran alle möglichen Szenarien durchzuprobieren, weitere Ansätze zu testen usw (alle Mitarbeiter sind hier langsam schon genervt, aber es bringt uns stets weiter ).

Nebst weiteren Lösungen für die JavaScript Optimierungen, haben wir ein sehr wesentlichen Punkt:
Das Durcharbeiten der ganzen Seiten ist ein immenser Zeitaufwand für den Optimizer (für das kritische CSS).
Wir experementieren hier gerade mit dem Ansatz das nicht mehr auf jeder Seitenurl zu prüfen sondern auf dem Seitentyp (z.B: Startseite/Artikelseite/404/...) basierend.
Dabei geben wir die Möglichkeit eine URL für den Seitentyp zu definieren - damit z.B. man beim Typ Artikel auch einen nutzen kann, der mehrere Vorschaubilder hat, Variationen usw.
Das bedeutet im Umkehrschluss dass für einen Artikel ohne weitere Vorschaubilder CSS Angaben für die Vorschaubilder im kritischen CSS vorhanden sind - das sind aus unseren Erfahrungswerten jedoch nicht wesentliche.
Das würde auch die "fehlende URLs"-Problematik beheben, zusätzlich würden wir noch die Möglichkeit auf URL Basis anbieten um z.B. spezielle Landingspages zu inkludieren (Nach dem Ablauf: Wenn individuelle Seiten-CSS vorhanden sind, nehme diese andernfalls die vom Seitentyp).
Dabei ist zu beachten, dass immer das vollständige minifizierte CSS natürlich nachgeladen wird - es kommt daher nicht zu Fehlanzeigen.

Ein Feedback hierzu würde uns weiterhelfen - um auch eine Meinung außerhalb unserer Reihen zu bekommen.

 

[saw]

Ein Feedback hierzu würde uns weiterhelfen - um auch eine Meinung außerhalb unserer Reihen zu bekommen.

Da bin ich überfordert, ich hoffe das @css-umsetzung sich hier einklinkt. Der Retter in (fast) allen Problemen

 

[css-umsetzung]

Da bin ich überfordert, ich hoffe das @css-umsetzung sich hier einklinkt. Der Retter in (fast) allen Problemen

Danke für die Blumen

Ich habe es in den letzten Tagen gar nicht mehr geschafft das Plugin anzuschauen, aber ich bin von dem was ich bisher gesehen habe echt begeistert und jedem der das wissen möchte erzähle ich das da was gutes in Arbeit ist.

Wir experementieren hier gerade mit dem Ansatz das nicht mehr auf jeder Seitenurl zu prüfen sondern auf dem Seitentyp (z.B: Startseite/Artikelseite/404/...) basierend.

Das war so meine erste Idee damals als es um das crawlen der einzelnen Seiten ging.
Ich würde das optional machen, so das der Shop Besitzer dann entscheiden kann, denn der weiß ja am besten, ob er z.B. den Dropper in den jeweiligen Seitentypen verwendet.

Ich denke mal das bei den meisten Anwendern in den Artikel und Kategorie Seiten keine wesentlichen Unterschiede sind.

 

[swiss-sale.ch]

Wir verwenden verschiedene Drops in den Kategorie- und Artikelseiten.
Wie könnte dies vom Optimizer erkannt werden?
Ansonsten wäre ein optionales Crawling auf Seitentyp-Ebene oder ein Ausschluss der entsprechenden Seiten wünschenswert.