Neu Neues Plugin: JTL Supercache

[eRock Marketing]

Hallo zusammen,

wir dürfen unser neustes Projekt aus unserer Tüftlerschmiede vorstellen: JTL Supercache.
Mit dem Plugin werden eure Shopseiten im Cache zwischengespeichert und damit deutlich schneller ausgeliefert.

Die Vorteile liegen auf der Hand:

• Auslieferung nach ca. 20% der eigentlichen Shopcodes
• Senkung des TTFB Wertes
• Reduzierung der Serverantwortzeit bis zu 80%
• Entlastung für eure Server

Selbstverständlich achtet das Plugin auf Konstellationen wenn es nicht aus dem Cache liefern darf (z.B. bei individuellen Preisen, Bestandsänderungen, ...)

Achtung: Da wir die komplette Shopseite im Cache speichern (den Quelltext) entstehen mitunter größere Datenmengen.
Wer nur begrenzten Cache (Genutzt wird der eingestellte JTL Cache, idealerweiße der Redis Cache) zur Verfügung hat kann alternativ in Dateien oder der Datenbank speichern lassen.
Dennoch ist auch hierfür zwingend der JTL Cache notwendig.

Um jeder Anforderung gerecht zu werden gibt es dazu zahlreiche Einstellungsmöglichkeiten:

• Supercache auf Seitentypen beschränken
• Lebensdauer des Caches festlegen
• Begrenzung auf Sprachen
• Ausschluss von URL Parametern (um z.B. Tracking Parameter nicht doppelt zu werten)
• Spezielle URLs ausschließen (z.B. Landingpages die bei jedem Aufruf anders aussehen sollen)
• Vollspeicherung im JTL Cache oder in der Datenbank oder als Dateien

Und wie geht das nun?
Simpel: Zip Herunterladen, in der Pluginverwaltung hochladen + installieren, 14 Tage testen und genießen.

Zum JTL Supercache: https://shop.knoell-marketing.de/JTL-Supercache

 

[hula1499]

Gutes Plugin, viele Einstellmöglichkeiten (auch für Hosting-Kunden geeignet mit Beschränkungen im Redis Cache etc).
Fähiger Entwickler, macht echt Spass Ideen vorzuschlagen, umgehende Umsetzung zu sehen und noch ein wenig mehr Speed für Kunden zu erhalten!

Ein wirklich sehr fairer Preis.

Auch vollständig Hypnos tauglich, ohne weitere/zusätzliche Anpassung.


Nachtrag: nein, das ist keine bezahlte Werbung, sondern meine subjektive Meinung, nach diversen Tests.

 

[saw]

läuft das parallel zu Eurem Speed Optimizer und/oder Hand in Hand?

 

[eRock Marketing]

Ja, das tut es. Wir haben extra eine höhere Priorität als der Speed Optimizer, um Fehler wirklich auszuschließen kann man noch darauf achten zuerst das Speed Plugin zu installieren, dann den Supercache.
So wird das Ergebnis vom Speed Optimizer mit in den Supercache gespeichert.

Ist im Prinzip auch die ideale Ergänzung.
Zu meiner Aussage oben, dass es 2 wesentliche Punkte der Performance gibt: Supercache = Für Schritt 1, Speed Optimizer = Für Schritt 2.

 

[saw]

Danke

 

[deliman]

Müssen die Seiten(namen) bei der URL-Sonderbehandlung für alle Sprachen einzeln angegeben werden oder reicht Deutsch und das Plugin weiß via der Sprachen unter "Allgemeine Einstellungen", was alles dazugehört?

 

[eRock Marketing]

Das ist unabhängig voneinander (sprich das wird nicht automatisch zugeordnet).

In den allgemeinen Einstellungen kann man sich z.B: auf eine Sprache beschränken.
Wenn nur deutsch im Supercache landen soll, braucht man natürlich auch nur deutsche URLs ausschließen.
Hat man aber Deutsch und Englisch im Supercache müssten auch beide URLs ausgeschlossen werden.

 

[peterwill]

Auch wir sind mal wieder begeistert!!!!! das plugin macht das was der shop schon seit Jahren machen sollte !!!!!
Frage wird es auch ein plugin für Shop 4 und Hypnos Template geben das webp Bilder umwandelt und auch verarbeitet!!!
Von jtl wird es für shop 4 wohl keine unterstützung für webp Bilder geben!!!!

 

[eRock Marketing]

Wir haben das ja bereits im Snackys implementiert mit webp und das funktioniert.
Als generelles Plugin haben wir das auch bereits in Planung, das wird sich dann jedoch leider nur auf manipulierbare Bilder beziehen - wie z.B. Artikelbilder und Kategoriebilder.

Die Generierung von webp können wir aus dem Snackys kopieren - jedoch das bei den Artikeln abzuändern wird etwas trickreich da diese ja auch weiterhin im Cache landen sollen - und webp nicht in allen Browsern unterstützt wird, muss man das Besucherabhängig machen.

Kurzum: In Planung, wann es jedoch soweit ist kann ich leider noch nicht sagen. (Im Snackys haben wir den Vorteil dass alle Bilder über unsere Funktionen nachgeladen werden, da können wir simpel die Dateiendung .webp anhängen und dann darauf reagieren - das geht als allgemeines Plugin leider nicht).

 

[peterwill]

wir hoffen das es nicht mehr soooooo lange dauern wird...
oder kann man es auch durch google mode_pagespeed auf dem server lösen ?

 

[eRock Marketing]

wenn ich die o's als Monate zähle dann definitiv weniger! Ggf. als Wochen kann es hinkommen, denke auch hier weniger, allerdings wollen wir ordentliche Lösungen bieten und nicht "schnell was rausgeben".
Wären uns Themen wie Objektcache usw. egal sähe das anders aus, aber eine Umwandlung in webp, dann jedoch langsamere Seitenberechnungen helfen auch keinem.

Daher leider: Gut Ding will Weile haben - ich denke mal Richtung Oktober ist hier ein verlässlicher Wert.
Generell sollte das aber mit mod pagespeed möglich sein: https://www.modpagespeed.com/doc/reference-image-optimize#convert_jpeg_to_webp

 

[saw]

Ist es normal das nach rund 48 Std. der Cache nur 137 Seiten cached?
Und ist es normal das sich die gecachten Seiten auch wieder verringern? Gestern waren es irgendwas mit 150.
Alles steht noch auf default, also 0 bei Speicherdauer und keine Neuerstellung.

 

[hula1499]

Der Cache wird von deinen Besuchern "ausgelöst".

Des Weiteren hängt der Cache natürlich von den Cache Zeiten ab, die du bei JTL und im Plugin angegeben hast (die kürzeste Zeit gilt), danach wird diese Seite im Cache wieder gelöscht und erst bei neuem Aufruf der Seite wieder erneuert generiert.

Verringern: ja, auch normal. Sobald etwas am Artikel geändert wird (bild, beschreibung, lagerstand etc) wird der Cache wieder gelöscht und neu generiert, beim nächsten Aufruf der Seite.

 

[saw]

Hallo hula1499,
die JTL Redis cache Zeit ist mir bewusst, die steht auf 12 Stunden. 135 Seiten kommt mir sehr wenig vor. Wir haben rund 4000 Besucher am Tag.

 

[css-umsetzung]

Immer auf den gesamten cache achten, der Redis cache ist in einem bei JTL gehostetem Shop begrenzt (behaupte ich)
Ich hab noch keinen bei JTL gehosteten Shop gesehen der mit dem Redis cache über 250MB ging.

 

[saw]

@css-umsetzung.de danke für den Hinweis, war mir nicht bekannt.
Ich habe jetzt 128 mb in Redis und 44,4 mb im supercache. Ich werde es im Auge behalten.

 

[die-andis]

ich wollte das Plugin mal ausprobieren und bekomme beim "Installieren" in der Pluginverwaltung folgende Meldung: "Fehler: Bei der Installation ist ein Fehler aufgetreten. Fehlercode: 203"

Nachtrag:
Im Log steht das "SQL Fehler beim Installieren des Plugins (KM Supercache): Specified key was too long; max key length is 767 bytes"

 

[eRock Marketing]

Hallo zusammen,

sorry da ich die letzte Woche nicht im Haus war komme ich erst jetzte dazu.
Bei dringen Fällen gerne auch immer im Büro durchklingeln, dann wird sich ein Kollege finden.

Eine kleine Info an alle:

Achtung: Das Plugin missachtet (logischerweise) Anpassungen durch Cookies auf PHP Seite.
Wer z.B. Cookie Hinweis-Plugins verwendet die per PHP abfragen ob ein Cookie-Hinweis angezeit werden soll oder nicht, wird immer die Version wie der erste Besucher der Seite sehen.
Also: Kommt ein Bestandskunde und sieht keinen Cookie-Hinweis, wird es auch so in den Cache gespeichert. Kommt ein Neukunde als erster auf die Seite wird die Version mit Cookie-Hinweis zwischen gespeichert.
Das betrifft aber nur Plugins die die Cookies auf PHP Seite ausarbeiten - wenn diese auf JavaScript-Seite verarbeitet werden (so macht es z.B. unser Snackys-Template) entsteht dieses Problem nicht.

Wir arbeiten an einer Lösung die Cookies beachten kann (muss dann jedoch sehr wahrscheinlich händisch in den Plugineinstellungen konfiguriert werden, damit es nicht zu 100 Versionen pro Seite kommt!).
@die-andis kannst du mir per PN eine Kontaktmöglichkeit von dir schicken? Wir würden dann auch dein Problem beachten (hat etwas mit der Datenbank-Tabellenkonstellation zu tun) und würden es dann gerne einmal bei dir testen (wir haben z.B. hier keine Limitierung drin, du laut Fehlermeldung jedoch hast eine).

Vielen Dank.

@saw Das Speichervolumen vom Redis-Cache (gesamt) beinhaltet dann auch den Supercache (unsere Zahl im Backend ist ja auf den Cache bezogen, jedoch eben nur auf die Cache-Inhalte die wir speichern, sprich eine Art Typ-Filter)

 

[WAWI-USER321]

Es wäre wirklich gut, wenn man den cache über eine URL ohne Log-in im Backend leeren könnte. z.b. wenn man die Preise ändert oder einen neuen Artikel in den Shop stellt, der schnell verfügbar sein soll.

Wer es braucht, kann dann auch Cronjobs verwenden, z.b. um den cache zu leeren, wenn eine Rabattaktion beginnt oder endet....

 

[hula1499]

Sobald ein Artikel ein Update erhält (Preis/Bestand/Text) wird der Cache für diesen betreffenden Artikel umgehend gelöscht.