Caching [3] - Wo das technische Problem liegt.

WBCE ist recht flott – deswegen gab es nie ernsthafte Anstalten, Caching in den Core zu integrieren. Und es ist auch nicht so einfach.

Komplette Seiten oder nur Teile?

WBCE ist sehr stark modular – und das bedeutet auch, dass die Module für ihren Teil der Chef sind. Es ist im Core nicht vorgesehen, in Module einzugreifen und wenn es ein partielles Caching geben soll, muss das vom Modul ausgehen. Manche Module machen das, die meisten nicht, es wäre den Modulautoren unbenommen.

Etwas anderes ist die Ausgabe der gesamten Seite: Hier kann von Core WBCE eingriffen werden. Typisch in Form von Output-Filtern, aber hier würde eben auch ein Caching der gesamten Inhalte ansetzen.

Das könnte blockweise sein – also Block 1, 2, 3... gesammelt in einer Datenbanktabelle oder einzelnen Dateien. In der Praxis wird das aber  entweder wenig bringen oder sehr viele Ausnahmen brauchen; etwa Code-Snippets oder wiederum die Output-Filter. Das kann undurchsichtig werden und ist sicher nichts für die Masse der Nutzer.

Bleibt praktisch nur ein Caching der gesamten Seiten. 

Änderungen auf einer Seite kann man natürlich leicht berücksichtigen und den Cache auf Wunsch aktualisieren. Was aber, wenn irgendwo eine Seite hinzugefügt wird?: Die muss ja auch im Menü stehen, und damit sind ALLE Seiten betroffen.  Es müsste dann der Cache aller Seiten neu erstellt werden. An sich kein Problem, aber wer triggert das? Ohne ungünstige Nebeneffekte.

Eine weitere Frage: Wenn ich eine Seite ändere, aber öffentlich soll die Cache-Version sichtbar sein: Wie ermögliche ich, dass der Nutzer die bearbeitete Seite sieht, ein – nicht angemeldeter – Besucher aber den Cache? Ohne dass ich die komplette Maschine WBCE hochfahre, um die Nutzerrechte zu überprüfen. Damit würde ich die Vorteile eines Caches zunichte machen.

Eine lauwarme Suppe mit Haaren drin?

Was haben wir also: Ein Problem, das nur so halb existiert und dessen Lösung viele ganze Probleme verursacht. ;-)
Es scheint das Thema Caching ist nur verlockend, solange es nicht konkret und durchgängig umgesetzt wird. Ich weiß das genau, weil ich mich seit fast 10 Jahren immer wieder mit dem Thema befasse und es bis jetzt nicht auf die Reihe bekommen habe. 

Aber!: Dass ich nicht recht weitergekommen bin, könnte auch ein Indiz für meine Blödheit sein; da muss man aufpassen! Immerhin habe ich bisher nicht ganz aufgegeben – was wiederum ein Indiz wäre, dass das Thema nicht unspannend wäre ;-)

Praxistest - Stand 07.01.2023

Auch hier, auf wbce.at läuft Caching, zu Testzwecken. Was die Ladezeit betrifft gibt es praktisch keinen Unterschied zwischen Seiten mit und ohne Cache. 

Was alles NICHT funktioniert: Die "Recent Downloads", die hier auf jeder Seite in der rechten Spalte sind, ändern sich auf gecachten Seiten nicht mehr, auf anderen Seiten schon. Das fällt wohl kaum jemandem auf. Ebenso verhalten sich die "Letzten Kommentare". 

Ich könnte das Caching-Script so erweitern, dass der Cache automatisch erneuert wird. Das war/ist auch so vorgesehen, allerdings kommen mir Zweifel zur Sinnhaftigkeit.

Zurück

Kommentare:

Cache nur gegen Cash!

Spaß beiseite: In der Tat ist es ja oft so, dass sich der Inhalt der Seiten über längere Zeit nicht ändert, da wäre es natürlich schon verlockend, so wie bei lokal laufenden Website-Editoren à la Website X5 o.ä. einen Knopf "Publizieren" zu haben, und einen statischen Abzug der Website zu generieren, der dann noch schneller ausgeliefert werden kann oder sogar auf Webspaces läuft, auf denen keine Datenbank verfügbar ist.
Auch das Thema Staging - also Website lokal bearbeiten und dann nach Kundenfreigabe veröffentlichen - könnte so elegant angegangen werden.
(Exkurs: Für das Staging gab es in grauer Vorzeit bei den backenden Kollegen übrigens mal ein Script. Das ging davon aus, dass die Felder ohne Präfix in einer Datenbank die produktive Seite abbildeten und diejenigen mit dem ebensolchen die Entwicklungsversion (oder umgekehrt, weiß ich nicht mehr genau). Auf Knopfdruck sind dann die einen DB-Tabellen mit den anderen überschrieben worden und vermutlich sind dann auch die Accessfiles und /­media-Inhalte rüberkopiert worden. Wobei das jetzt nicht wirklich Caching oder Freezing war, weil auch in der Produktivseite eine CMS-Instanz lief.)
Aber, wie Du schon schriebest, der Teufel ist ein Eichhörnchen und steckt im Detail und ein wirklicher Leidensdruck besteht im Normalfall nicht.
Für das Zusammenfassen und Komprimieren der zugegebenermaßen nicht wirklich SEO-freundlichen Vielzahl von zu ladenden frontend.css- und frontend.js-Dateien gibt es von Dev4Me übrigens durchaus eine Lösung, nämlich Minified CSS&JS, und das funktioniert i.d.R. auch ganz hervorragend (https:/­/­addons.wbce.org/­pages/­addons.php?do=item&item=107).

Antworten

Danke Florian, das sind ein paar recht gute Argumente.

Trotzdem: Für mich bleibt es eine lauwarme Suppe mit Haaren drin. Zuvielen Haaren. Immer mehr, je mehr ich mich mit dem Thema befasse.
Ja - Staging - das wäre ein Thema, aber WBCE ist kein Tool, um statische Seiten zu erzeugen. Muss man klar sagen: Das wäre missbräuchliche Verwendung.

Die Erwartungen, die manche vom Caching haben, sind genauso diffus wie das Plichtenheft für ein Caching-Script. Vielleicht sollte man DA mal anfangen. Was - außer ein genereller Heilsbringer - soll Caching denn sein? Was soll es können? Da wird die Luft dünn, glaube ich.

Antworten