Neu Plugin JTL Speed Optimizer verfügbar

[eRock Marketing]

Der JTL Cache ist zwingend erforderlich.
Welche Methode dabei gewählt wird, ist jedem selbst überlassen.

Redis ist allerdings die beste Methode.

 

[css-umsetzung]

In einem normalem Hosting wie z.B. JTL wird der Redis Cache mit Sicherheit auch limitiert sein.

 

[eRock Marketing]

Das ist kein Problem - lediglich die Methode für "kritisches" CSS kann dann an seine Grenzen kommen.

 

[css-umsetzung]

Ich meinte das eher im Bezug auf die Gesamtmenge aller Daten im cache.
Ein Kunde von mir kam beim JTL Hosting nie über 250 MB bei Redis, schaue ich mir andere Kunden im Hosting an, haben die auch nicht mehr als 255 MB. Nun auf einem eigenem Server wo es keine Limitierung gibt liegt er bei über 800MB.

Kann aber auch sein das ich falsch liege und es nur Zufall ist, aber wenn ich recht habe und der Shop selbst den Cache schon voll auslastet wäre es nicht so schön wenn da dann noch die css Daten drin sind oder?
Da die CSS Daten ja vermutlich als fertiges css hinterlegt ist würde ich also direkt mein eigenes caching verwenden denn eine Datei aufzurufen kostet ja nicht so viel Ressourcen, bzw. muss man abwägen, ob es wichtiger ist Daten von einem Listing im cache zu haben oder ein paar css Informationen.

Um das nochmals festzuhalten, was du da gebaut hast finde ich bisher echt Klasse, man muss nur sehen das es nachher auch richtig cool läuft und nicht andere Probleme bringt.

 

[eRock Marketing]

@css-umsetzung Sollte es mal jemanden "Nicht gefallen" ist es Geschmackssache und absolut legitim.
Hier hingegen höre ich lauter konstruktive Kritik - absolut klasse!

Nach wie vor stoßen wir erst langsam in den Bereich der "allgemeinen" Plugins / Templates vor - was sich von der "perfekten Abstimmung auf 1 Shop" nun doch unterscheidet.
Bislang entwickelten wir stets individual Lösungen. Statt einem Optimizer Plugin gab es dann die entsprechende Anpassung im Template/Server, die mit Sicherheit nochmals deutlich effizienter ist.
Haben wir einen größeren Cache gebraucht - so wurde es eben in den Servereinstellungen angepasst. Das geht nun leider nicht überall.
Was wir hier tun sind ja gewisse Automatismen, die man ebenso im Template umsetzen kann - aber das will und mag nicht jeder so realisieren (allein durch die Problematik von Updates) - so kam erst die Idee.

Der Redis-Cache ist halt schneller wie der Zugriff auf Dateien. Aber auch das schaue ich mir an und werde es beachten.

 

[eRock Marketing]

Wie versprochen: Wir haben eine überarbeitete Version.

Allerdings arbeitet dies in der Verarbeitung der Optimierungen vollständig anders: Die Optimierungen werden extern (Per Cronjob) erstellt.
Damit wird der normale Shopbesucher nicht mehr belastet - ist die aktuell angeforderte Seite noch nicht durch den Optimierer gelaufen wird die Standardsversion ausgeliefert.

Das bringt den Vorteil, dass wir pro Aufruf viel geringer prüfen müssen ob die Seite optimiert wurde oder nicht - das Ergebnis: eine nochmals bessere Performance.

Auch die Verarbeitung des JavaScript Optimizer haben wir verbessert: Es werden nun ohne Ausnahme (außer explizit in den Einstellungen angegeben) alle JavaScripts nachgeladen und in eine Datei gepackt.
Auch kann ab sofort die CSS und JavaScript Zusammenfassung im Template deaktiviert werden - das übernimmt vollständig der Optimizer und kann somit nochmals Performance bei den Seitenaufrufen sparen.

Wie arbeitet der Optimizer dann?
Dieser wird entweder an Hand der Shop-Sitemap (oder einer anderweitig generierten Sitemap) oder eine Liste an URLs (Im Plugin einstellbar) durchgearbeitet.
Der Start des Optimizer kann im Idealfall per Cronjob laufen - alternativ per Aufruf durch einen Admin. Dabei wird ein Mehrfach-Aufruf verhindert.

Die Ergebnisse speichern wir im eigenen Datei- Cache, sodass der JTL Cache hier keine Rolle spielt. Allerdings wird der JTL-Cache benötigt um den Ablauf des Cronjobs zu gewähren.

Notwendige Anpassung für den JavaScript Optimizer:
Bitte deaktiviert den Cronjob per Blindgrafik. Da dies bei jedem 10ten Aufruf durchgeführt wird, kann es gut sein, dass der Optimizer auf diesen Aufruf stößt - und generiert dann inkl. diesem die JavaScript Datei.
Generell sollte dies ebenfalls über einen Cronjob laufen: https://guide.jtl-software.de/Aufgabenplaner_für_Exporte_einrichten#Aufgabenplaner_per_Cronjob_ansto.C3.9Fen

Eine Empfehlung für einen ersten Testlauf:
Im Plugin die Einstellung "Seiten definieren durch" auf "URL-Liste" umstellen und dort 2-3 URLs zum testen reinsetzen.
Dann kann der Optimizer auch einmal per Hand aufgerufen werden, was in etwa so aussieht wie www.domain.de/includes/plugins/km_optimizer/cron.php

Sofern hier die Werte verbessert wurde (wovon wir deutlich ausgehen! ) und alles wie gewünscht funktioniert kann der Cronjob fest eingerichtet werden.
Hier dann am besten an die Doku halten oder auch gerne uns kontaktieren.
Doku: https://shop.knoell-marketing.de/Doku-Speed-Optimizer


Download der aktuellen Version: https://shop.knoell-marketing.de/zips/km_speed_optimizer_v104.zip

 

[hula1499]

Kleine Anmerkungen nach dem kurzen reinschnuppern:

1.)
Aufruf der direkten cron-Url ->

Forbidden
You don't have permission to access /includes/plugins/km_optimizer/cron.php on this server.

Egal ob im Browser als Admin eingeloggt oder nicht. Aber ich finds eh gut, wenn er von aussen nicht (an)steuerbar ist. Vermutlich jedoch problematisch für diejenigen, die keine internen cronjobs starten können.

Console/putty start mit: php blabla/cron.php, startet die Erstellung einwandfrei.
Pro Url braucht unser System (managed server) 12-20s / Url.
5400 Urls x20s = rund 29 Stunden.
Also wer da jetzt öfters seine CSS oder so ändert, wird weniger seine Freude haben.


2.)
Performance fürs Erstellen und Auslastung des Servers:
Serverload vor dem Caching start: ~ 0.5 im Mittel
Beim cachen ~1.5-1.8
Also der zieht hier schon ordentlich power ab.

3.)
Das in unserem Telefonat angesprochene Problem auf der Startseite mit Lazyload/nicht geladenen Bildern ist weiterhin vorhanden (wo du meintest, du weisst woran es liegt) - hier muss kurz gescrollt werden, damit die Bilder angezeigt werden, d.h. der Bug ist noch da. Lazyload Einstellung bei uns ist nicht aktiv.

Einiges mag vielleicht nach Kritik klingen, ist es aber nicht.
Erstellen bei grössen Seiten (wir haben 5 Sprachen, das Artikelurls x5, CMS x5 etc) ist das zeitlich schon ein Horror.
Eigentlich haben wir auch 3 Währungen - die in der Sitemap so nicht vermerkt sind, ob hier jetzt ein Cache Unterschied vorhanden ist - werd ich mir dann ansehen, wenn er fertig ist.

Plugin mal wieder deaktiviert, aufgrund Punkt 3.

 

[eRock Marketing]

Hallo und vielen Dank für die Rückmeldung.

zu 1:
Für den direkten Aufruf ist der plugin Ordner gesperrt. Beim Packen fehlt die .htaccess Datei, die dieser einzelnen Datei den Aufruf gewährt.
Diese ist nun dabei. Wer den Cronjob jedoch per Konsole aufruft darf die .htaccess aus dem Plugin Ordner gerne löschen.

Zu 2:
Ja die Verarbeitung ist aufwendig. Daher die Zeit. Da wir die Seite selbst wie JTL laden müssen.
Im Standard ist zwischen jeder URL eine Pause von 3s eingebaut - die Seite selbst braucht von JTL ja auch immer rund 1 bis 2Sekunden - das ist ein Teil der Zeit, den anderen brauchen wir leider für die kritischen CSS Berechnungen, sowie lesen aller CSS und JS Dateien (wobei zweiteres verkürzt wird bei weiteren Aufrufen, wenn diese identisch sind zu einer bereits verarbeitetenden Seite werden die nicht neu verarbeitet).
Wer sich das vom Server leisten kann, kann z.b. den Delay von 3s auf 0 setzen (bei 5.400 URLs sind das nochmal 4,5 Std gesparrt).
Insgesamt hat die Dauer des Parsen des CSS auch mit der Größe und der Komplexität der CSS Dateien zu tun, nicht falsch zu verstehen: Beim Hypnos dauert die Verarbeitung ca. 40-60% länger.
Der Optimizer muss auch nicht zwingend täglich gestartet werden, oder man beschränkt sich nach wie vor wieder auf die wichtigen URLs, z.B. per anderweitig generierter Sitemap, oder Ameisen Export der Artikel und fügt diese in die URL Liste ein. Die Zeit des verarbeitens haben wir soweit runtergebrochen wie nur irgend möglich - zum CSS Parsen setzen wir auf den PHP Parser Sabberworm - der einzige der CSS in den aktuellen Techniken sauber verarbeiten kann. JTL arbeitet mit PHPQuery, leider lange nicht mehr weiterentwickelt - etwas vergleichbares haben wir jedoch nicht gefunden (wäre auch suboptimal dann würde erst JTL die Seite verarbeiten und dann wir nochmals, das würde auf das gleiche hinaus kommen).
Sorry, aber seid euch sicher - hier haben wir tief reingeschaut um alles rauszuholen.

Zu 3:
Das konnte ich jetzt leider nicht so nachstellen, ggf. aber auch weil ich nicht genug Daten für das Hypnos Template habe. Der Ansatz von JavaScript ist umgebaut. Hier muss sicherlich nur die Funktion gestartet werden, die auch dem Scroll-Event beiliegt - bekomme ich per PN Zugriff auf den Admin (Verwaltung des Plugins reicht) ?

 

[hula1499]

2
Hab ja geschrieben, manches klingt nach Kritik, ist es aber nicht
Wollte nur darauf hinweisen, dass es einfach unheimlich lange dauert und das bei nur 5400 Seiten (29h ist halt schon eine Hausnummer). Aber, wer jetzt nicht jede Woche css ändert oder im "Aufbau" ist, dem kanns eh egal sein.
15% gespart mit den 3 auf 0 ist natürlich toll, aber obs jetzt 29h oder 24.5h sind, ist doch auch schon wurscht

Täglich starten ist vollkommen illusorisch (jetzt abgesehen davon, dass auch 24.5h > 1d sind) - css/js brauchst ja dann nur bei Änderungen an den datein / pluginupdates oder ähnliches gemacht werden oder halt von mir aus 1x in der Woche "just for fun".

Nur einzelne Urls zu nehmen ist wie mit dem Auto nur im 2ten Gang zu fahren. Entweder ich verwende ein Auto (mit seinen Möglichkeiten bis zur max. zulässigen rechtlichen Gegebenheit) oder ich fahr (weiter) Uber/Bahn/Fahrrad/EinsetzenWasManMöchte.

3
Das hatten wir sogar telefonisch durchgesprochen.
Ich seh auch grad, nachdem ich wieder kurz aktiviert habe, dass die Hypnos "Sondereinstellungen" (owl etc) weg sind, auch in der Doku draussen, nicht mehr erforderlich aufgrund des js umbaus?
Da ich leider noch immer nicht dazugekommen bin, nach den letzten grösseren Änderungen den DEV vollständig upzudaten, hab ich kurz wieder im Live-System getestet, aufgrund der Bildergeschichte kann ichs jedoch nicht laufen lassen.
Gerne morgen, wenn Zeit ist, wieder kurz TV oder so.

 

[Dustin]

Also bei uns lässt sich der Cron nicht starten:

Cronstatus(1) ungueltig.

Kommt als Meldung

 

[eRock Marketing]

Dann wurde er bereits gestartet? Hier ist ein Mechanismus drin doppelte Aufrufe zu blockieren.
Was sagt denn im Plugin der Tab "Cron und Cache" zum Status?

@hula1499 Ja die Änderungen im JS sind so stark, dass diese Einstellung nicht mehr notwendig sind. Wir haben das Prinzip hier verändert - so viele Ausnahmen fanden wir einfach störend!
Gerne - rufe gerne wieder durch, dann schauen wir uns das an.

 

[Dustin]

Er sagt wird gestartet passiert aber anscheinend nix.

 

[eRock Marketing]

Anzahl Seiten gesamt steht bei 0.
Auf was ist die Einstellung gesetzt? Sitemap oder URL Liste?
Und ist die Sitemap erstellt, respektive die URL Liste befüllt?

Hilft das nichts: Auf Wunsch auch gerne mal bei uns im Büro durchklingeln und zu mir (Konstantin) durchstellen lassen, dann schauen wir gemeinsam rein.

 

[Dustin]

Vielen Dank an Herr Knoell, er hat Problemlos geholfen, wir schauen jetzt mal wie lange es dauert bis alle Seiten verarbeitet sind.

 

[peterwill]

Hallo geht das Plugin jetzt richtig für Hypnos?
Ist ein eigener Webserver jetzt die Vorraussetzung oder läft es auch auf normalen Webspace?

 

[eRock Marketing]

Hallo,

ja das Plugin läuft - auch im Hypnos.
Es sollte auch auf dem "Normalen" Webspace gehen.
Hier wird wohl der Cronjob nicht per Konsole sondern per Webaufruf gestartet werden müssen.
Dazu am besten das private Fenster des Browers nutzen oder auch einen sonst nicht verwendeten, sodann blockiert der Cronjob nicht den Rest (das ist benutzerabhängig).
Hier sollte wohl auch die Auszeit zwischen den Seiten auf dem Standard von 3 Sekunden gelassen werden (eigene Webserver mit genug Power können das bis auf 0 runterstellen).

@hula1499 hat in seiner Konstellation noch Probleme mit den LazyLoader Bildern, das konnte ich mir bislang noch nicht mit der neuen Version des Plugins anschauen, andere Umgebungen hatten das Problem bislang allerdings noch nicht.

Auch habe ich über das zahlreiche Feedback gestern noch ein paar Feintuning auf die ToDo genommen, die aber nicht essentiell sind (wird dann in der nächsten Version mit drin sein).
Das sind Punkte wie:

• Ein kleiner Check, der:
  • Datei / Verzeichnisrechte prüft, falls nicht bereits richtig gesetzt
  • Prüft ob die .htaccess mit übernommen wurde (liegt im Plugin bei, aber in 1 Fall wurde die einfach trotz mehrfachen Versuchen nicht eingespielt)
  • Prüfen ob die angegebene Sitemap vorhanden und gültig ist (noch vor dem Cronjob)
  • Ggf. ein Check der Serverkonfiguration um Hinweise auf die idealen Einstellungen zu geben - aber das ist noch intern zu besprechen ob das sinnvoll ist
• Ein "Live"-Cronjob der sich selbst wieder aufruft (aktuell läuft der einfach durch, man muss warten bis der fertig ist, das ist kein Problem denn im Plugin sieht man eigentlich den Status im Tab "Cron und Cache", manche verwirrt es einfach, ist mehr eine Schöhnheitssache) - sprich dass man diesen "sehen und verfolgen" kann wie z.B. die Bildergenerierung im Shopbackend
• Zwischencache der einzelnen CSS / JS Dateien während dem Cronjob (aktuell werden die Dateien neu geladen, falls die neue Seite eine andere Struktur aufweißt muss diese ja neu verarbeitet werden (eine Prüfung wenn die Struktur identisch ist und damit nicht neu verarbeitet werden muss ist bereits vorhanden), hier können wir uns ggf. minimal noch was sparen in der Verarbeitung - bei vielen Seiten zählt wohl jede Sekunde - das geht aber nich um die "Live"-Seite sondern um die Verarbeitung der Optimierungen via dem Cronjob)

 

[saw]

Ich habe jetzt auch die testversion installiert und habe Fragen:
Sitemap Konfig, da steht Standardmäßig unter /sitemap_index.xml zu erreichen, sollte das nicht eher /export/sitemap_index.xml sein?
Es wäre für mich sehr gut wenn das Plugin mir zeigt das es z.B. die Sitemap gefunden hat. (Hast Du ja auf der ToDo, wollte es nur verstärken)
Der Cron Status macht mich etwas krank. Da steht bei mir - inaktiv.
Darunter
1 CSS Datei im Cache
28 kritische CSS im Cache
28 Javascript im Cache

Ich habe bestimmt 50+ Quellcodes angesehen und jedesmal sehe ich das dns prefetch und die inline CSS, also hat das plugin erfolgreich gearbeitet, aber der Status ist trotzdem inaktiv, verstehe ich nicht.
Den Cron habe ich vor ca. 20 Stunden angestoßen. Über cronjob de, aber da sieht man beim kostenlosen leider keinen Status oder Meldung. Bei meinem JTL Hosting kann ich offensichtlich keinen Cron einrichten.

Die Tests mit pagespeed sind aber viel versprechend, da hat sich einiges in der sehr kurzen Zeit verbessert.
Startseite mobil von 59 auf jetzt gerade 84, wow.
FCP und FID sind quasi unverändert, aber z.B.: Erste Inhalte gezeichnet 3,2 s ist jetzt ein "grünes" 0,9
Geschwindigkeitsindex 5,5 s runter auf 2,8 s usw..
Sehr sehr cool.
Ich hoffe das die Berge an inline CSS das ranking nicht beeinflussen, habe mal bei google irgendwo gelesen das man nur "kleine" inlines haben sollte.
Ich schaue jeden Tag in unser ranking mit dem Haupt Keyword und da stehen wir heute 0,1 besser als die letzten Tage, von 3,3 auf 3,2. Vielleicht andere Faktoren, vielleicht auch nicht. An unseren Produkten haben wir in den letzten 2 Wochen nicht viel gemacht.

grüße
Mathias

 

[css-umsetzung]

Google selbst (der Support von Google der mit mir diverse Optimierungsmöglichkeiten am Telefon besprochen hat) sagt, das man bis zu 50kb styles direkt im Headbereich einfügen darf.

 

[saw]

Danke für die Info.
Ich habe mal die Startseite abespeichert, alles nach /head und grob was kein css war gelöscht und komme auf rund 134kb.
Bei den Detailseiten auf bis zu 410kb, gute 1800 Zeilen.
Hm.

 

[eRock Marketing]

Hallo,

erst einmal super, dass es die gewünschten Verbesserungen bringt.

Einmal im Detail:

Sitemap
Diese wird ja per Rewrite auf den Unterordner in Export geschrieben, daher geht auch die "verkürzte" Angabe.
Wer ganz sicher gehen will, gibt es mit https usw. an. Aktuell wird die Sitemap nur beim Starten des Cronjobs geprüft, daher gibt es bislang auch nur dort die Meldung ob diese gelesen werden konnte usw. Wie versprochen wird das in der nächsten Version auch im Adminbereich sein,gehört sicherlich eher in die Kategorie "Usability des Plugins".

Status inaktiv
Das betrifft den Cronjob, sprich dieser ist wohl fertig durchgelaufen? Während dem Durchlaufen steht hier "in Verarbeitung" und wieviele von wievielen Seiten bereits durchgearbeitet wurden. Sollte der Cronjob nach x Seiten abbrechen liegt es häufig daran, dass die Skriptlaufzeit nicht verändert werden darf und die Zeit einfach abgelaufen ist. Dann kann der Cronjob mehrfach angestoßen werden, dazu: https://shop.knoell-marketing.de/Doku-Speed-Optimizer Abschnitt "Einstellungen" 2. Absatz.

CSS und inline
Grundlegend kann man recht leicht nachschauen wie groß die CSS Dateien sind:
Im Plugin unter /temp/critical werden die CSS abgespeichert, die Dateinamen sind dabei (bis auf bestimmte Zeichen) identisch zur jeweiligen URL.
Diese Größe ist die, die inline geladen wird. die weiteren CSS Angaben werden ja ebenfalls per CSS Datei (unter /temp/css zu finden, hier jedoch nicht zuordbar, da diese nur anders ist, falls Seiten unterschiedliche CSS Dateien haben) und sind minifiziert, um hier auf "weniger" zu kommen hilft nur das CSS generell zu überdenken (Aufgabe des Templates).
So kann man auch sehen, ob das kritische oder das "Normale" CSS geladen wurde: Ist ein Inline-Style mit Code + eine nachgeladene CSS in der Seite vorhanden (nicht im QUelltext schauen, die nachgeladene steht nicht von Anfang an drin, eher Tools wie den Chrome Developer nutzen), dann wird das kritische geladen.

Das kritische ist dabei das minimale was geht, bedeutet: Es sind nur CSS Angaben vorhanden, wie auch Elemente im HTML vorhanden sind.
Gibt es wieder Erwartens z.B: keine Bilder (HTML img-Tag), dann gibt es dazu auch keine CSS Angaben (es kann aber mehr als 1 Angabe zu gefundenen Werten geben - dazu habe ich im letzten Part der Antwort mehr stehen).

Erst noch was zur der 50KB Angabe - hier muss ich leider wiedersprechen.
Das ist ein empfohlener Richtwert, aber selbst beim AMP Projekt gibt es hier immer wieder Diskussionen was das richtige ist. Auch der Google Entwickler-Support (die Stufe nach dem "normalen" Support, die - nicht falsch zu verstehen - nur Richtwerte weitertragen) hatten wir hier länger gesprochen und auch mit den Speed Optimizer Integrations by Google bereits 2 Kundenprojekte verarbeitet. Typisch wie immer: Nichts schwarz auf weiß, aber: Die Daten werden etwas tiefer geprüft. So werden z.B. Inline Bilder im CSS nicht gezählt (data-Werte). Hinzukommend wurden uns Richtlinen "zwischen 75-100KB je nach Seitenart" genannt und eine Prozentuale Toleranzgrenze gäbe es auch, sowie der stetige Vergleich mit vergleichbaren Seiten und Lösungen. Sprich: wir gehen aktuell davon aus dass es unter 100KB sein sollte, umso weniger umso besser natürlich.

Wenn das kritische CSS immernoch zu hohe Werte hat, kann das Ursachen haben wie das ewige hin und her überschreiben von Werten im eigentlichen CSS.
Auch das ist nicht falsch zu verstehen - aber wir sehen nicht selten Angaben die vom EVO-Template kommen in eigenen Templates wieder überschrieben werden. Faktisch sind jedoch beide Angaben im CSS vorhanden, das zweite meistens dann noch mit Werten wie "!important"... so etwas fangen wir nicht ab, da hilft in der Tat auch nur: Template aufbessern.