Neu Plugin JTL Speed Optimizer verfügbar

[saw]

Hi,
ich hatte vorhin mit Herrn Petermann (css-umsetzung) telefoniert und wir kamen auch auf das PlugIn zu sprechen und haben etwas genauer geschaut.
Da ich im JTL- Hosting ja keinen Cronjob anlegen kann, habe ich es über cronjob de gemacht, wie oben schon geschrieben.
Die Script Ausführungszeit steht bei mir schon auf beachtlichen 300 Sekunden, aber danach bricht der Cronjob auch ab und ich bekomme nur ca. 30 css Dateien in /temp/critical
Insgesamt wurde der Job in den letzten 4 Tagen mindestens 8 mal angestoßen und offensichtlich weiß der job auch nicht mehr wo er abbrach und fängt immer wieder bei null an und kommt bei 5 Minuten nicht wirklich weit (Pause 2 Sekunden).
Wenn er angestoßen wurde sagt er mir im Plugin auch schön: Seiten insgesamt 3080, verbleibende Seiten 3077...3058....3055...3051, dann bricht der cron mit Internal Server Error ab, 30 css Dateien in /critical und im Plugin BackEnd keine Aktualisierung mehr.
Das klappt so nicht.

Was mit noch auffiel; google pagespeed moniert plötzlich fehlende lange cache Dauer für die font Dateien woff2 und sehr viele Bilder, das war vorher nicht so.
https://developers.google.com/speed/pagespeed/insights/?url=https://www.softairwelt.de/

Allerdings, wie auch schon geschrieben, vergibt uns google ca. 20 Punkte mehr als ohne Plugin.

 

[eRock Marketing]

Vielen Dank für die Rückmeldung.

Bezüglich dem stetigen Neuanfang (anstatt weiter zu machen) schaue ich mir gerne an und werde eine Lösung bauen (kann sein dass das Objekt nicht mehr im Cache ist, oder einfach ein Logikfehler im Plugin vorliegt).

Die Bilder und Schriften werden nicht moniert. Diese werden als "Hinweis" ausgegeben - a la "überprüft doch bitte ob die Zeiten so sinnvoll sind, bei dem Bild aktuell sind es 30 Tage".
Vorher standen dort sicherlich einige CSS+JS Dateien die jetzt so nicht mehr vorhanden sind (da zusammengefasst) und damit ist die Liste kürzer und die weiteren rutschen nach oben "in den Teil der sichtbaren Liste" (das wird auf x Ergebnisse beschränkt).
Bei einer Seite die noch nicht optimiert ist (auf Grund des von dir beschriebenem Bugs) sieht man das: https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https://www.softairwelt.de/Handschuhe
Hier werden jtl3.js, plugin_head, ... usw. ebenfalls dargestellt und die Schriften kommen erst "danach". Sprich ist diese Liste länger, tauchen diese einfach nicht mehr auf.

Edit:
Sorry ich muss mich korrigieren: Bei mir tauchen nun alle zu prüfenden Ressourcen auf - ggf. wechselt das? Traue dem Pagespeeds sowieso nicht immer! (einfach mal 3x analysieren und sich über 3 unterschiedliche Ergebnisse - auch ohne Änderung - amüsieren).
Zusammenfassend: Auf der nicht optimierten Seite stehen z.b. auch die Schriften drin.

 

[css-umsetzung]

Da hab ich gerade einen Shopbesitzer gezwungen das zu installieren und dann das

<br />
<b>Fatal error</b>:  Uncaught Error: Call to undefined function strposa() in /www/htdocs/includes/plugins/km_optimizer/version/104/frontend/140.php:2
Stack trace:
#0 /www/htdocs/includes/plugin_inc.php(56): include()
#1 /www/htdocs/classes/class.JTL-Shop.JTLSmarty.php(397): executeHook(140)
#2 /www/htdocs/includes/vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_filterhandler.php(63): JTLSmarty-&gt;__outputFilter('    \n          ...', Object(jtlTplClass))
#3 /www/htdocs/includes/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(219): Smarty_Internal_Runtime_FilterHandler-&gt;runFilter('output', '    \n          ...', Object(jtlTplClass))
#4 /www/htdocs/classes/class.JTL-Shop.JTLSmarty.php(873): Smarty_Internal_Template-&gt;render(false, 1)
#5 /www/htdocs/includes/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(216): jtlTplClass-&gt;render(f in <b>/www/htdocs/includes/plugins/km_optimizer/version/104/frontend/140.php</b> on line <b>2</b><br />

 

[eRock Marketing]

Sorry - Bug in der Bilder LazyLoader.
Das deaktivieren dann geht es - ruft leider noch die falsche Funktion auf.

Update auch mit den anderen versprochen Punkten kommt bald.

 

[eRock Marketing]

Hallo erneut,

wie versprochen haben wir noch ein wenig Feintuning vorgenommen und auch auf das Problem bezüglich der PHP Ausführungszeit reagiert, sowie die Bugs behoben.

Ein Update ist verfügbar!

Mit folgenden Änderungen:

• Cronjob auch als Live-Version
  Aus dem Plugin heraus kann nun auch der Cronjob direkt als Live-Version gestartet werden, dabei arbeitet die Funktion jede Seite einzeln ab - sprich solange diese geöffnet ist, wird auch optimiert.
  Dadurch wird die maximale PHP Ausführungszeit irrelevant (eine Seite ist immer zu schaffen).
  Der Aufruf per Cronjob kann unverändert weitergenutzt werden (nach wie vor die empfohlene Methode!)
• Cronjob wird in der Datenbank statt im JTL Cache gespeichert
  Das verhindert Probleme beim "Fortfahren" des Cronjobs, da wurde (je nach Cache-Größe) zu schnell überschrieben @saw
  Dadurch ist nun für den kompletten Optimizer kein JTL Cache mehr erforderlich.
• Nicht kritisches CSS nicht mehr inline
  Wenn kein kritisches CSS aktiviert oder gefunden wurde, wird die minifizierte CSS-Datei (Zusammenschluss aller CSS Dateien, sprich auch von Plugins die dynamisch CSS hinzufügen, damit umfangreicher wie assets) angehängt, statt inline geladen - wir haben einfach kein Template mit ausreichend wenig CSS-Code gefunden der noch inline stehen könnte (sorry für die Eigenwerbung: Außer im Snackys Template! )
  Das kritische CSS wird nach wie vor inline geladen und lädt nach dem Seitenaufbau das restliche CSS nach (um auch dynamische Inhalte stylen zu können)
• Änderungsdatum von Seiten
  Im Plugin kann nun eingestellt werden, wenn der Optimizer erneut gestartet wird, ob nur seit dem letzten Durchlauf geänderte Seiten neu optimiert werden sollen. Das ist nur im Modus Sitemap.xml verfügbar (wir beziehen uns auf das dort angegebene Änderungsdatum)
• Vorabcheck im Plugin
  Im Plugin werden nun die wichtigsten Eckdaten für einen reibungslosen Ablauf geprüft.
• DNS Prefetch verlängert
  Über die einfachen Einstellungen war im DNS Prefetching nur eine Eingabe bis 255 Zeichen möglich, diese ist nun unbeschränkt.
• Aufgabenplaner-Blindgrafik
  Da diese für den JavaScript Optimizer ausgeschaltet sein muss, kann diese im Plugin aktiviert werden, falls es keine Möglichkeit für Cronjobs gibt - die Funktionaltität ist identisch zum JTL Standard, umgeht aber das Problem, dass diese im Optimizer quer kommen kann (bitte im Template stets ausschalten!)
• Kleine Optimierung am Optimizer
  Extern geladene Ressourcen werden während der Optimierung zwischengespeichert, sodass diese bei Folgeseiten nicht neu angefragt werden müssen
• Neu: Preloading URLs
  Hier können Dateien bereits vorgeladen werden. Dies läuft parallel zum Seitenaufbau und steht damit danach umittelbar zur Verfügung.
  Ideal für z.B. Schriften die recht groß sind und sonst erst mit nachladen des CSS angefordert werden, stehen so schneller zur Verfügung und stören dennoch nicht beim Seitenaufbau.
  Angabe bitte als vollständige URL
• Bugfixing
  • Bug im Bilder nachladen (LazyLoading) behoben (verursachte Error 500) @css-umsetzung
  • jtl.ready() Funktion überschrieben - teils gab es in der Abfolge Probleme mit dieser JavaScript Funktion (häufig Startseite nivoslider) - @hula1499 ggf. behebt das auch dein Bilderproblem?

Der allgemeine Pluginlink ist geupdatet worden - die explizite V1.05 kann hier heruntergeladen werden: https://shop.knoell-marketing.de/zips/km_speed_optimizer_v105.zip
Unsere Shopseite dazu: https://shop.knoell-marketing.de/Speed-Optimizer

Im Plugin ist eine einfache Dokumentation erhalten, die Live Dokumentation (https://shop.knoell-marketing.de/Doku-Speed-Optimizer) werden wir im Laufe der Woche updaten und auch noch ausschmücken und bebildern.

Wer nochmals testen möchte, aber der Zeitraum abgelaufen ist, bitte kurze PM.

 

[saw]

Hi,
update gemacht, cronjob angestoßen, schöne live sicht was gerade gemacht wird und der shop geht arg in die Knie (2 Sekunden Pause im plugin).

Dann habe ich mir mal 3-5 optimierte Seiten angeschaut und jetzt geht die Bildvergrößerung nicht mehr.
Z.B. https://www.softairwelt.de/Heckler-Koch-VP9-Tactical-Softair-Pistole-6mm-GBB-FDE
Beim klick auf das 1ste Bild ändert sich die uri zu
https://www.softairwelt.de/Heckler-Koch-VP9-Tactical-Softair-Pistole-6mm-GBB-FDE#&gid=1&pid=1
Entsprechend des xten anklicken des Bildes ändert sich die uri entsprechend
https://www.softairwelt.de/Heckler-Koch-VP9-Tactical-Softair-Pistole-6mm-GBB-FDE#&gid=1&pid=4

2tes Beispiel auch mit schlimmen Ladezeiten bei Passende, Ähnliche, Kunden kauften dazu... hier
https://www.softairwelt.de/Colt-Python-6-schwarz-cal-45mm-BB-Diabolo

usw..

 

[saw]

kurzes update: die rendering Zeiten scheinen nur lokal am PC zu sein wo der Cron angestoßen wurde. Bei anderen PCs, auch anderem internet Zugang ist der shop normal flüßig fix.
Die Bilder lassen sich aber überall nicht vergrößern, mehrere Browser und PCs getestet.

Den Cron habe ich jetzt erst mal gestoppt.

 

[eRock Marketing]

Hallo,

die Live-Ansicht blockiert den jeweiligen Benutzer, ähnlich wie bei den Cronjobs - daher auch hier am besten im abgesicherten Modus, oder ganz auf den Cronjob setzen, falls möglich.
Andere Benutzer sollten nicht betroffen sein - bei richtiger Serverkonfiguration (ein Nutzer sollte ja nicht die ganze Serverpower bekommen) - alle "Standardtests" dazu sahen bisher auch gut aus.
Wenn sehr viele Besucher auf dem Shop sind kann man sich auch gerne ruhigere Zeiten aussuchen. Im "Live-Cronjob" ist das beenden recht einfach: Fenster schließen.

Nach Ablauf der Zeit wie im Plugin konfiguriert (Standard 300s - sprich 5min) kann der Cronjob wieder gestartet werden und setzt an der gleichen Stelle fort.

Zu der Bilderproblematik:
Es liegt hier sogar am CSS. Die Reihenfolge ist verkehrt zwischen inline und nachgeladenem CSS, da hier ein weiteres inline CSS existiert.
Dadurch werden die pswp-open Angaben einfach wieder überschrieben (die Lightbox ist da: nur weiterhin ausgeblendet ):
Schaue ich mir an - Lösung sollte in den nächsten Stündchen kommen.

Cron kann damit aber weiter durchlaufen - das kommt nicht daher.

 

[eRock Marketing]

Erledigt.

Bitte einfach nochmal runterladen und drüberbügeln, die Reihenfolge wurde angepasst (im Testshop läuft es auch im Hypnos nun erfolgreich mit dem Bilderzoom).

 

[saw]

Das war ja schnell.

Beim Cron Aufruf in neuem privaten Fenster kommt die Meldung:
unauthorized - NSA wird benachrichtigt.

Öhm....

Bei "normalem" Start läuft er jetzt weiter, daher wieder gestoppt und erst mal komplettten Cache gelöscht. Und jetzt wieder angestoßen.
Das Plugin meint das es rund 12 Stunden braucht.

bei der ersten Seite die es optimiert hat, gehen die Bilder wieder - prima.

Ich gebe feed back...

 

[eRock Marketing]

Mit der NSA sind natürlich wir gemeint und haben nun alle Daten.

Der Live Optimizer darf nur laufen, wenn man im Admin angemeldet ist - zur Sicherheit (im privaten Fenster auch einfach vorher im Admin anmelden).
Der normale Cronjob erfordert das nicht.

 

[saw]

OK, verstanden NSA, roger und out

 

[saw]

kurzes update; der Optimizer läuft noch, von 3088 - 1820 übrig.

habe mal drei frisch optimierte Detailseiten über page speed gejagt und wow, von i.d.R. 50-60 Punkten jetzt auf bis zu 92 hoch gejagt. Respekt! Respekt!
https://www.softairwelt.de/Browning-GPDA-9-Gold-Finish-Schreckschuss-cal-9mm-PAK
https://developers.google.com/speed...-GPDA-9-Gold-Finish-Schreckschuss-cal-9mm-PAK

Page Speed möchte nochmal 0,6 sek eingespart sehen wenn die neue /temp/css/xxxxx.css aufgeschoben wird. Vielleicht können Sie da nochmal rein schauen?
Und auf der HP möchte er die 3 woff2 Dateien als "preload" sehen.

Ich sage mal danke für das tolle PlugIn!
Mathias

 

[eRock Marketing]

Die CSS ist aufgeschoben, am Ende ist die Seite einfach zu schnell für den Pagespeed-Test?

Spaß beiseite: Hier wäre es natürlich toll wenn die CSS auch sinnlose Angaben entfernt bekommt, das ist uns aber nicht möglich da wir nicht wissen können was "live" noch auf der Seite gebraucht wird (durch Änderungen von JavaScripts).
Daher laden wir das vollständige CSS nach - natürlich komprimiert! Dieser Ladevorgang findet jedoch erst nach dem vollständigen Seitenladen statt - später geht nicht mehr.

Sprich: Da ist nach meiner aktuellen Auffassung per Plugin nichts mehr rauszuholen.

Die gute Nachricht: Die Schriftarten können per Preload eingebunden werden.
Dazu im Plugin->Tab "URLS und Prefetch" in der letzten Box "Dateien vorladen (1 pro Zeile" die Schriftart angeben (bitte vollständigen Pfad mit https).
Alle Dateien werden hier versucht zu erkenn (Typ) und so eingebunden, wenn der Typ unbekannt ist, dann wird es als Typ "fetch" geladen - was nicht die Ideallösung ist.
Die Prüfung erfolgt auf Basis der Dateieendung und unterstützt aktuell: woff, woff2, ttf, eot, js, css, jpg, jpeg, png, webp, svg, mov, mp4

 

[css-umsetzung]

Wir haben das gestern in einem Evo Template getestet, da war es so das teilweise Teile des css vom Child Template fehlten auch das mit dem nivo Slider im JS ist uns aufgefallen aber das wurde ja nun mit dieser Version behoben.
Wir werden das also noch mal testen mit der aktuellen Version, doof war eben nur das man nicht nachvollziehen konnte warum es bei einigen Seiten fehlte, ich habe fast die Vermutung das das CSS da fehlte wo es das css im cache angelegt hat aber es war schon so spät und der Tag so lang.

 

[saw]

Die CSS ist aufgeschoben, am Ende ist die Seite einfach zu schnell für den Pagespeed-Test?

Stimmt, genau das war es

Ich habe die drei woff2 Dateien jetzt in die prefetch Config reingesetzt. Sorry für die vielen Fragen (wird aber auch sicherlich anderen usern helfen)
- nach der prefetch Änderung den Cron neu starten und vorher den cache löschen?

Und für heute die (wahrscheinlich) letzte Frage: wenn ich einen Artikel neu aufnehme, wie bekomme ich den optimiert?
Das Feld "URL Liste" (oder so ähnlich) gibt es in der version ja nicht mehr.
besten Dank

 

[eRock Marketing]

@css-umsetzung
CSS fehlen dürfte keins.

Es wird ein Hash aus den Dateinamen gebildet und daraus die generierte CSS Datei abgerufen (falls vorhanden, wenn nicht wird der Standardmodus ausgeliefert).
Ist es also so, dass durch ein neues Plugin weitere CSS dazukommen sind die nicht verloren.
Was jedoch ein Problem war, war die Reihenfolge. In gewissen Konstellationen konnte es sein, dass das kritische CSS nach allen Ladevorgängen in der Hierachie nach der Haupt-CSS Datei stand, das konnte zu Fehlern führen.
Das ist jedoch ebenfalls behoben.
Änderungen innerhalb der CSS allerdings bekommen wir nicht mit. Die Prüfung wäre zu zeitaufwendig und daher nur kontraproduktiv.
Da innerhalb einer CSS Umsetzung nur in einer Entwicklung passieren sollten, muss hier dann im Plugin einmal der Cache gelöscht werden.
Alternativ kann auch für erfahrene im Quelltext die Datei gesucht werden und im Plugin unter km_optimizer/temp/css/xxxxx.css die Datei einfach gelöscht werden (mehr Abhängigkeit besteht nicht).
Dann die URL einzeln per Plugin durchlaufen - und es ist geupdatet (spart ggf. einen komplett neuen Durchlauf des Optimizer, aber: Das ist sicher nur eine Lösung für versiertere Anwender, denn den Part des kritischen CSS darf man nicht vergessen)

@saw
Nach den Änderungen muss kein Neustart gemacht werden, die URLS werden "einfach" in das Dokument als Prefetch-Ressource eingefügt werden, das passiert "live".
Die URL-Liste gibt es noch: im Tab "URLs und Prefetch" die erste Box. Dazu entsprechend die Einstellung anpassen (dass aus der URL Liste statt aus der Sitemap geladen wird).
Generell kann ich das aber nur zu Testzwecken empfehlen, oder wenn man explizit nur bestimmte URLs möchte.
Andernfalls auf die sitemap.xml umstellen und den cronjob häufiger anstoßen. Im Plugin kann eingestellt werden, dass nur sich geänderte Seiten (darunter fallen auch "neue") erneut durchlaufen werden.
Damit sollte der laufende Betrieb schonend und dennoch vollständig abgedeckt sein.

 

[saw]

Im Plugin kann eingestellt werden, dass nur sich geänderte Seiten (darunter fallen auch "neue") erneut durchlaufen werden.
Damit sollte der laufende Betrieb schonend und dennoch vollständig abgedeckt sein.

Oh, das habe ich übersehen, besten Dank

 

[peterwill]

Hallo jetzt bei der 1.05 Version
muß da noch etwas besonders für das Hypnos Template eingestellt werden?

 

[eRock Marketing]

Nein, die Standards sollten hier ausreichen.

Falls es noch etwas gibt, muss meistens ein weiteres JavaScript Event ausgeführt werden um notwendige Funktionen anzustoßen.
Die eigentlich relevanten sind als Standard eingetragen in der Einstellung "Events die nochmals ausgeführt werden sollen".
Das dies nicht ausreicht haben wir nun aber sehr selten, da die aktuelle Lösung "breiter gefächert" ist - wenn dann gerne uns kontaktieren.