Contao SeitenCache -> ClearCache Button, wenn etwas geändert wurde.

[Metis77]

Feature Wunsch: Wenn der SeitenCache aktiviert ist und wenn etwas irgendetwas geändert wird, sollte ganz oben ein Hinweis und ein Button erscheinen, um den SeitenCache direkt zu löschen.

Ich weiß nicht wie es anderen geht, aber bei mir melden sich regelmäßig Kunden mit der Beschwerde, dass Änderungen im Frontend nicht angezeigt werden. Und da kann ich noch so auf darauf hinweisen, dass sie bitte den Cache leeren sollen.

[Aybee]

Das sollte meiner Meinung nach automatisch passieren, wenn man im BE eingeloggt ist und etwas verändert, dass der Cache dann diesbezüglich verändert wird. Bei Typo3 musste ich immer so 300 mal am Tag den Cache leeren, wenn ich Inhalte eingepflegt habe oder entwickelt habe. Das sollte mit Contao nicht auch so sein.

Hast du denn auch Probleme wenn der Cache-Modus auf "nur Servercache" steht? Denn ich denke, dass das normal ist, wenn du auch den Browsercache aktiviert hast.

[Metis77]

Stimmt, ich habe BrowserCache und ServerCache aktiviert. Allerdings funktioniert es immer sobald man den unter User den SeitenCache löscht.

Mir ist tatsächlich aufgefallen, dass viele nur den ServerCache aktivieren. Sollte es nicht aber auch mit beidem funktionieren, zumal es geht sobald man den Cache löscht?

[Aybee]

Ich bin nicht so der Cache-Fachmann, aber wenn dein Browser eine Seite cached in der ein Ablaufdatum in der Zukunft liegt, dann fordert er erst gar keine Seite an, sondern nimmt die aus dem Cache, auch wenn der Server eine neue hat.

Es kommt auch darauf an, wie dein Browser eingestellt ist. FF ist z.B. default auf browser.cache.check_doc_frequency = 3 (Check when the page is out of date) eingestellt, checkt also das Ablaufdatum. 1 wäre "check every time". Manche Entwickler-Erweiterungen stellen das während des Entwickelns von 3 auf 1.

Wenn du in Contao den Browsercache nicht aktivierst, sollte der Server also eine Seite ausliefern mit einem Ablaufdatum in der Vergangenheit, wenn du sicherstellen möchtest, dass alle Browser die Seite direkt vom Server holen. Mit Shift F5 kann man im FF die Seite auch direkt vom Server holen.

[Metis77]

@Aybee eben leider nicht. Da hilft auf Reload (F5 oder CMD+R) nichts. Wenn es so wäre, wie du beschreibst wäre es ja super.

Dieses Verhalten fällt mir bei allen Browsern auf, und eben immer wieder meinen Kunden. Erst wenn wenn man den Contao Seiten Cache leert, wird per reload die veränderte Seite geladen.

Einfach mal mit Contao Server+Browser Cache testen. Dazwischen auch ausloggen, damit der HTML Page Cache von Contao aufgebaut wird. Sonst lässt sich das nicht nachvollziehen.

[Toflar]

Zur Klarstellung:

• Server-Cache Ist eine Contao-spezifische Implementation. Wenn er aktiviert ist, versucht Contao beim ersten Besucher einer Seite (wir nennen sie mal beispiel.html) das generierte HTML zu speichern. So kann die Last für die Ausführung von Contao verringert werden, weil der 2. Besucher dann zwar ganz normal Contao abfragt, aber Contao intern nur noch das zuvor generierte HTML ausliefert. Alles andere was ggf. aufwändig ist (wie bspw. das Generieren des Navigationsbaums) wird übersprungen. Es liegt in der Natur dieses Caches, dass er ein shared Cache ist - also für alle Besucher gilt.
• Browser-Cache Ist die Implementation eines der Caching-Features von HTTP. Das HTT-Protokoll verfügt über sehr mächtige Caching-Mechanismen, mit denen man sich lange beschäftigen kann (und sollte). Im Prinzip ist es aber so, dass man zwei Möglichkeiten hat: Entweder man sagt dem Browser wie lange er eine Datei cachen darf (Expires) bevor er wieder neu nachfragt oder man kümmert sich selbst um Cache-Invalidation. Beide beziehen sich (da auf dem Client) natürlich nur auf einen Besucher.
  • Expires: Die einfachere Variante des Cachings sagt dem Browser einfach "bitte behalte diese Datei für 24h im Cache und dann frag mich erneut für das File". Dies ist die Methode die Contao implementiert.
  • Cache-Invalidation: Ist die sehr viel bessere, aber auch sehr viel schwierigere Caching-Methode. Beim ersten Anfragen der Webseite liefert der Webserver nebst dem Inhalt der Webseite auch einen Hash bzw. eine "Identifikationsnummer" für den Content mit. Bekannt ist der unter ETag :) Bei der nächsten Anfrage des gleichen Clients sendet der Browser automatisch den vorher erhaltenen ETag mit dem If-None-Match Header mit. Der Webserver kann nun - wenn er weiss dass der Inhalt immer noch der selbe ist wie derjenige den er damals mit dem erhaltenen ETag generiert hat - einen 304 Not Modified header ohne Inhalt zurücksenden und der Browser nimmt die Daten aus dem Cache. Ansonsten kriegt der Browser ein 200 OK mit neuem Inhalt und neuem ETag. Diese Methode reduziert natürlich den Traffic und kann - wenn der Webserver (durch welchen Mechanismus auch immer) in der Lage ist, zu bestimmen ob sich der Inhalt verändert hat ohne ihn bereits wieder komplett zu generieren - zu weniger Last auf dem Webserver führen. Contao nutzt das aufgrund der Komplexität nicht und deaktiviert in der .htaccess standardmässig sogar das Senden des ETag.

Caching kann allerdings sehr oft nicht für ganze Seiten vorgenommen werden. Nehmen wir mal an ihr würdet ein Login-Modul in der rechten Spalte platzieren. Es wäre ja schon komisch, wenn immer noch das Formular angezeigt würde auch wenn ihr eingeloggt seid, nur weil der Browser die Seite gecached hat. Da gibt es dann Methoden, die Seite in einzelne Subelemente aufzuteilen und daraus mehrere HTTP-Requests (welche wiederum gemäss obenstehender Erklärung gecached werden können) zu machen. Stichwort für's Weiter-Googeln wer mag: Edge-Side-Includes. Auch da reden wir von komplexem und professionellem Caching. Es ist sehr schwierig bzw. fast unmöglich das generell zu implementieren, weshalb Contao auch das nicht macht.

Lange Rede kurzer Sinn: Wenn ihr Caching aktiviert, versucht zu verstehen wie er funktioniert. Wenn der Server-Cache geleert wird, heisst das noch lange nicht, dass der Browser die Resource neu anfragen wird. Hoffe das bringt ein bisschen Licht ins Dunkel am Morgen früh :-)

Weiterer Lesestoff: RFC 2616 (das ist im Prinzip unsere Bibel, sie ist nicht einfach zu lesen, aber jeder Webentwickler sollte es tun ;-))

[frontendschlampe]

sehr gut @Toflar ... dankeschön ... kannst du das auch gleich so ins Wiki schreiben? ;-)

[Metis77]

@Toflar super Anleitung, herzlichen Dank dafür.

Nichts desto trotz ändert das nichts an dem Problem. Bitte steinigt mich wenn es wirklich nur an mir liegt.

1.) Contao nur Server Caching an. (mit Server + Browser Caching ist das Verhalten aber identisch) 2.) Irgendeine Änderung machen. 3.) Anderer Browser oder Coockies löschen. 4.) keine Änderung im Frontend sichtbar, solange nicht in Contao der Cache gelöscht wird.

D.h. man muss IMMER den Cache löschen (was ja irgendwie logisch ist), wenn man möchte dass anderen noch innerhalb der Cachevorhaltezeit diese Änderungen sehen. Deshalb halte ich einen Hinweis / Button für sinnvoll, der direkt die Redakteure erinnert und den Cache mit einem Click leeren lässt.

[Toflar]

Ja logisch. Solange der Server-Cache an ist, kriegst du nie eine Änderung im Frontend. Das habe ich ja erklärt :) Aber ich denke es ist falsch den Kunden darüber zu informieren, dass er den Cache leeren muss. Entweder er versteht wozu er da ist (und ist dementsprechend einverstanden damit, dass seine Änderungen erst in z.B. 4 Stunden ersichtlich sind) oder er will das nicht, was soviel heisst wie: die Cache Zeit ist falsch oder überhaupt sollte kein Caching stattfinden.

[Metis77]

@Toflar Ja das erkläre ich den Kunden auch immer. Sind sind auch jedes mal davon überzeugt, vergessen dann aber doch wieder den Cache zu leeren und fragen dann verwundert nach.

Inzwischen bin ich der Überzeugung, dass hier ein Hinweis (mit direkter Möglichkeit zum Cache leeren) für die Usability wichtig wären.

[Toflar]

Und dann kommt noch hinzu, dass das ja eigentlich gar nicht geht. Du müsstest ja wissen, welcher Inhalt auf welcher Seite ausgegeben wird. Wenn z.B. die News auf einer nicht-gecachten Seite ausgegeben werden, dann muss diese Meldung ja nicht erscheinen, da ja nix passiert. Das herauszufinden ist fast unmöglich, weil das Modul im Seitenlayout, im Artikel, per InsertTag etc. eingebunden werden kann. Insofern bleibt die Möglichkeit bei jeder Änderung eine Nachricht à la "Hallo, Sie haben was geändert, evtl. müssen sie den Cache löschen" auszugeben, was aber nutzlos und somit Unsinn wäre.

[Metis77]

@Toflar das Stimmt natürlich. Mir geht es letztendlich darum, einfach eine schnellere / einfache / direktere Möglichkeit zu haben, den Cache zu leeren.

Mein Vorschlag kommt im Grunde eher von meinem Kunden, welche die aktuelle Situation als "Umständlich" empfinden. Vielleicht sind sie auch einfach nur die immer präsenten Cache Leeren Buttons von anderen System gewöhnt.

[Aybee]

@Toflar danke für den Artikel

Aber Contao ist doch so intelligent, dass es den serverseitigen Cache aktualisiert sobald ich eine Änderung irgendwo vornehme, oder etwa nicht?

Ich habe das gerade mal in der Demo auf Contao 3.3.3 getestet. Nur Servercache eingestellt. Seite Home 30 min Cachezeit eingestellt. Überschrift in einem CE geändert.

Die geänderte Überschrift ist bei mir im FE sofort sichtbar.

Das ganze funktioniert bei mir sogar mit "Server und Browsercache". Und auch auf anderen Seiten. D.h. bei mir bekomme ich das überhaupt nicht simmuliert, dass im FE was altes aus irgendeinem Cache angezeigt wird.?

ps Mein "interner Cache" ist deaktiviert, aber der hat damit doch nichts zu tun, oder?

[Toflar]

Aber Contao ist doch so intelligent, dass es den serverseitigen Cache aktualisiert sobald ich eine Änderung irgendwo vornehme, oder etwa nicht?

Nein. Nur wenn du es manuell machst. Die einzigen Ausnahmen dazu sind:

• Bildercache leeren, leert auch den Seiten-Cache (Bilder sollen ja neu geladen werden)
• Scriptcache leeren, leert auch den Seiten-Cache (Skripte sollen ja neu geladen werden)
• XML-Dateien neu schreiben, leert auch den Seiten-Cache (wegen ungültigen Links)

Wobei du ausserdem den Cache nicht zu Gesicht bekommst im Frontend wenn du:

• POST-Daten sendest (Formulare abschickst)
• Im Frontend eingeloggt bist
• Im Backend eingeloggt bist
• Den Debug-Modus aktiviert hast

ps Mein "interner Cache" ist deaktiviert, aber der hat damit doch nichts zu tun, oder?

Nein :)

[tsarma]

I have some kind a solution to it, by giving a visual feed back of cached page and making it possible to remove cache individually instead of purging the whole website.

I have implemented it this as shown below in my own dca/tl_page.php. This is just to give you an idea, it may not work as i have this since long time back and never reviewed it.

<?php

/**
 * Add fields to tl_page
 */

// This finds out home page ID and store it in session
$GLOBALS['TL_DCA']['tl_page']['config']['onload_callback'][] = array('tl_page_bus', 'myOnload') ;

array_insert($GLOBALS['TL_DCA']['tl_page']['list']['operations'], 0, array (
    'cached'  => array(
        'label'               => &$GLOBALS['TL_LANG']['tl_news']['feature'],
        'icon'                => 'blank.gif',
        'button_callback'     => array('tl_page_bus', 'pageCacheIcon')      
    )
)); 

/**
 * Class tl_page_bus
 *
 * Provide miscellaneous methods that are used by the data configuration array.
 */
class tl_page_bus extends \Backend
{

    public function myOnload()
    {
        /* This is here just because home page url can be only the domain name, or domain + home.html */
        if($this->Session->get('HOME_PAGE') == '')  {
            // there no Model for finding first published root page.
            $objHomeRoot = $this->Database->prepare("SELECT id, language FROM tl_page WHERE pid=0 AND published=1 ORDER BY sorting")->execute();
            $objHomePage = \PageModel::findFirstPublishedByPid($objHomeRoot->id);
            $this->Session->set('HOME_PAGE',  $objHomePage->id);
            $this->Session->set('HOME_LANG',  $objHomeRoot->language);
        }

    }

    /**
     * Return the "cached" button
     * @param array
     * @param string
     * @param string
     * @param string
     * @param string
     * @param string
     * @return string
     */
    public function pageCacheIcon($row, $href, $label, $title, $icon, $attributes)
    {

        if( in_array($row['type'], array('regular', 'error_403', 'error_404') ) ) {
            // Get the default URL      
            $objPage = \PageModel::findWithDetails($row['id']);

            $strCacheKey = \Environment::get('base') . $this->generateFrontendUrl($objPage->row()); 

            // HOOK: add custom logic // This is copied from FrontendTemplate.php, as it is
            if (isset($GLOBALS['TL_HOOKS']['getCacheKey']) && is_array($GLOBALS['TL_HOOKS']['getCacheKey']))
            {
                foreach ($GLOBALS['TL_HOOKS']['getCacheKey'] as $callback)
                {
                    $this->import($callback[0]);
                    $strCacheKey = $this->$callback[0]->$callback[1]($strCacheKey);
                }
            }           

            $hashed = md5($strCacheKey);

            $strCacheFile = TL_ROOT . '/system/cache/html/' . substr($hashed, 0, 1) . '/' . $hashed . '.html';

            /* only for the home page compare the row id with stored home ID*/
            if($row['id'] == $this->Session->get('HOME_PAGE')) {
                $homeHashed = md5(\Environment::get('base') . 'empty.' . $this->Session->get('HOME_LANG'));
                $strHomeCacheFile = TL_ROOT . '/system/cache/html/' . substr($homeHashed, 0, 1) . '/' . $homeHashed . '.html';
            }

            //execute delete action
            if (strlen(\Input::get('rid')) && strlen(\Input::get('paged')) )
            {
                @unlink(TL_ROOT . '/system/cache/html/' . substr(\Input::get('paged'), 0, 1) . '/' . \Input::get('paged') . '.html');

                /* only for the home page */                
                if($row['id'] == $this->Session->get('HOME_PAGE')) {
                    @unlink( TL_ROOT . '/system/cache/html/' . substr($homeHashed, 0, 1) . '/' . $homeHashed . '.html');
                }

                $this->redirect($this->getReferer());
            }

            // check if file is cached
            if (file_exists($strCacheFile) OR (($row['id'] == $this->Session->get('HOME_PAGE')) AND  file_exists($strHomeCacheFile)) )
            {
                 $icon = 'cache.gif';  
                 $href .= '&amp;rid='.$row['id'].'&amp;paged='. $hashed;

                // return icon with link    
                 return '<a href="'.$this->addToUrl($href).'" title="delete '.specialchars($title).'"'.$attributes.'>'. \Image::getHtml($icon, $label).'</a> ';
            }  else{
                 // return passive icon
                 return $this->generateImage($icon, $label);                 
            }
        }   // end if;      
    }

}

?>

[Aybee]

@Toflar Nur wenn du es manuell machst.

Ok, habe das FE jetzt in einem 2. Browser getestet und da sehe ich dann tatsächlich die Veränderungen nicht.

Ist das zu schwer zu realisieren? Oder warum macht Contao das nicht (Servercache aktualisieren bei Veränderung)?

Ich bin bis jetzt immer davon ausgegangen, dass andere die Veränderungen auch sehen, da ich sie ja auch sofort in meinem FE sehe. Aber wenn das daran liegt, dass ich im BE eingeloggt bin, dann wäre ich auch dafür sogar einen Button in den Header zu bringen, mit dem man den Seitencache sofort aktualisieren kann. Sonst ist das immer doof wenn man dem Kunden sagt "ich habe es korrigiert" aber er sieht es nicht.

Mir ist das ganze Cachingverhalten noch nicht so bewusst geworden, weil ich die Seiten meistens nicht cache. Die Kunden stellen meistens auch nur "Server und Browsercache" in den Einstellungen ein, ohne zu wissen, dass nichts gecachet wird, solange die Seiten nicht auch eine Cacheeinstellung bekommen.

[Toflar]

Ist das zu schwer zu realisieren? Oder warum macht Contao das nicht (Servercache aktualisieren bei Veränderung)?

Wie gesagt, Contao weiss nicht welche Änderungen (News, Events, Artikel etc. pp.) sich auf welche Seiten auswirkt. Insofern müsste es ja bei jeder Änderung irgendwo in Contao den gesamten Seiten-Cache leeren. Dann kannst du ihn ja gleich bleiben lassen.

@tsarma: Indicating that a page is being cached is indeed a nice addition. However, it does usually not affect the regular editors. They will most likely not have access to the site structure because they are only editing articles and news and stuff. So I stick with my opinion: either editors fully understand the caching mechanism and do not care if their content is only visible after 4 (or whatever) hours or they don't want it to be cached which means you as a site administrator should disable it. It's a matter of training, not of Contao doing cache magic.

[Ruudt]

I would find it acceptable if the entire page-cache is emptied whenever I manually need it to. A button to quickly do that would be great. Showing important content quickly trumps efficiency of the system. But it shouldn't popup at the top because the system can't possibly know when cache clearing is desired.

How about a core setting/module/extension so a button can be enabled and configured per user, to set which cache to clear when pressed?

@Toflar: I think the customer should not need to understand caching. Most barely understand adding content, and unfortunately almost none appreciate waiting for content to show.

@tsarma: There is already an extension by aschempp for that, but it isn't well maintained unfortunately: cacheicon (https://contao.org/en/extension-list/view/cacheicon.10000029.en.html)

[Aybee]

@Ruudt @tsarma [cacheicon] is only to show if a page has cache activated or not in the page settings.

[Toflar]

A button to quickly do that would be great.

Maintenance -> checkbox for page cache -> submit -> done. Can't be much quicker I think. Where else would you like to put it?

@Toflar: I think the customer should not need to understand caching. Most barely understand adding content, and unfortunately almost none appreciate waiting for content to show.

Disagree. Again: if they don't understand it, then the system administrator should not enable caching. If, however, the system administrator feels like caching is (due to the number of requests or so) needed, he or she should explain it to the customer so that they understand. It's as easy as that.

[tsarma]

@Aybee:[cacheicon] is only to show if a page has cache activated or not in the page settings.

Not just show if a page has cache activated. Mine implementation above shows icon only if the page is cached.

@Ruudt : Thanks for info, I just went my way.

Actually I think, with little bit of work we can also make it possible to purge page's cache if some editor edit and save content with use of save_callback.

[Metis77]

Disagree. Again: if they don't understand it, then the system administrator should not enable caching.

Thats like: "if the customer does not understand web, he should not have a website"

Maybe I am the only one with that kind of customers, but most of my customers either do not understand it, do not care about it or just forget it. But whenever asking an explaining it to them they prefer to keep caching on.

That is why i still stick to my feature request: Add a link/button "clear PageCache (x)" next to the user settings at the top of the contao backend. Maybe even with "x" indicating the number of currently disk cached contao pages.

[Ruudt]

Maintenance -> checkbox for page cache -> submit -> done. Can't be much quicker I think. Where else would you like to put it?

That's actually not as quick because there are a lot of caching options to choose from. Doesn't get much more complicated for the layperson. I mostly have the type of customer @derhaeuptling describes.

Disagree. Again: if they don't understand it, then the system administrator should not enable caching.

The typical client needs to know the effect, not the mechanism; push button -> refresh browser -> see contents now! If new important content is a daily occurrence the administrator should consider disabling/altering of some/all caching; different scenario and you could be right there.

[Toflar]

So to sum up for @leofeyer: People would like to have a "Clear cache" button in the top bar that clears the page cache on click. :smile: For the record: I'm still :-1: on this for a few reasons I have mentioned in my comments.

[Ruudt]

How about I'll create an extension for it instead? Button can't be in the header in that case because I'd not like to edit the original template. What would be the best alternative for a single click button?

@leofeyer: Is it possible to make the top links editable through the dca?

[Metis77]

@Ruudt I'd prefer the "button" to be in the same look an feel as the other top links (like user settings, logout, ...)

Also i think this should be not a plugin. This feature should present itself by default particularly to not so experienced users, who do not know of helpful plugins like this. (same as the ticket about the sticky footer buttons like save)

[leofeyer]

I am with @Toflar on this one. An extra button does not solve any problem.

Also, constantly purging the cache causes more harm than simply decreasing the cache timeout. Why do you set a cache timeout of 4 hours for a dynamic page? What are the positive effects you are hoping to accomplish?

[Aybee]

I think it's the wish to simulate a static page for speed up page rendering. Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month. Then they like to see new content immediately and not waiting one year ;) and they don't know anything about clearing cache.

[Metis77]

I think it's the wish to simulate a static page for speed up page rendering. Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month. Then they like to see new content immediately and not waiting one year ;) and they don't know anything about clearing cache.

that is absolutely a good point.

another is: especially rarely visited pages with a cache time of 5 min would actually never be cached, as there are no two visitors visiting within 5 min. so it could be a good idea, to set caching time to weeks or longer.

[aschempp]

Don't forget about the client cache. So if you set the chache to 1 year the previous visitors will not see the updated version even though you clean the server cache. I suggest you do not use 1-year caches... make the caches reasonable, like several hours. The load on the server will still be dramatically less (if you have a lot of visitors), and everyone will see new news within an hour.

[Ruudt]

Does the frontend preview bypass cache? If so it can be used to see changes right away for the customer while waiting for the 1 hour cache to expire. On Jul 16, 2014 10:51 PM, "Andreas Schempp" notifications@github.com wrote:

Don't forget about the client cache. So if you set the chache to 1 year the previous visitors will not see the updated version even though you clean the server cache. I suggest you do not use 1-year caches... make the caches reasonable, like several hours. The load on the server will still be dramatically less (if you have a lot of visitors), and everyone will see new news within an hour.

— Reply to this email directly or view it on GitHub https://github.com/contao/core/issues/7155#issuecomment-49225065.

[Aybee]

@aschempp I think we're only talking' about server cache as there is no chance to clear the clients browser cache. Or is there?

[leofeyer]

Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month.

especially rarely visited pages with a cache time of 5 min would actually never be cached, as there are no two visitors visiting within 5 min

Both are very good examples of how to use caching in an unreasonable way (no hard feelings).

If there are less than two visitors within 5 minutes, it means there are only about 12 page requests per hour. You certainly do not need any kind of cache in this situation.

And it does not make sense to set a cache timeout of one year for a dynamic page, either. It will cause more problems than it solves, as we can learn from the problems described above.

I find the cache on contao.org to be most efficient if it is set to a timeout of 60 seconds. There are enough hits to slightly decrease the server load and we do not have any problems with outdated content.

[Toflar]

Does the frontend preview bypass cache?

@Ruudt: Yes, I also stated that here: https://github.com/contao/core/issues/7155#issuecomment-48292799 (in German, sorry).

I think we're only talking' about server cache as there is no chance to clear the clients browser cache. Or is there?

@Aybee: Of course not, that's why it's called "Client" cache :-D

This discussion shows that this additional button will not help but rather confuse people. Given the fact that when logged in as a back end user and using e.g. the front end preview the cache will be omitted, a regular user will always think that their changes are applied now because they will not understand that the behavior is differently when they're logged in. So I stick with my opinion: Anything different from user training will not help understanding the mechanism of caching at all.

[Toflar]

What we can and should do, however, is document my comments in the manual in both, German and English.

[Metis77]

Some customers like to set their cache to 1 year and maybe change some content (news, event ...) only once a month. especially rarely visited pages with a cache time of 5 min would actually never be cached, as there are no two visitors visiting within 5 min

Both are very good examples of how to use caching in an unreasonable way (no hard feelings).

While this is absolutely true for big sites, this is a cut off to many other pages that are rarely visited.

Like comprehensible from some comment above, the cache can be used to simulate a static page. Nowadays page load speed has become very important. (say for google page rank).

Additional Contao used with some plugins (say MetaModels) can result in way to slow server response times.

So many users actually use long cache setting regardless of what the cache is made for. And I think they do it for a good reason.

But back to topic: this is about a Clear Cache reminder and a simple clear cache button, that would help at least my kind of customers a lot.

[Ruudt]

@derhaeuptling I think mostly clients wouldn't care that much if the update is delayed for on hour if they can see it themselves. They may not even notice because cache is bypassed when you are logged into the backend/use the frontend preview.

For those clients that want instantaneous updates perhaps an extension can add a button alike the synchronize button that will execute and open the maintenance page.

Do you have any references that confirm the importance of page speed in relation to page rank?

Most pages I have with MetaModels contain dynamic content like a filtered and/or paginated list of catalog items. That's almost uncachable...

If there are less than two visitors within 5 minutes, it means there are only about 12 page requests per hour. You certainly do not need any kind of cache in this situation.

@leofeyer Does that also work for shared hosting? I host all of my clients on one very fast machine. Only customers that need/want to get (virtual) dedication.

Is it sensible to be able to set client and server cache duration as two different settings?? I could set client refresh to a shorter duration then server cache for websites that we manage. I'll update all I need, then refresh caches. Using a server cache of a month would be no problem, but client cache of 30 days is very, very long.

[Metis77]

Do you have any references that confirm the importance of page speed in relation to page rank?

https://www.google.com/search?q=google+page+speed+page+rank there are lots of relevant hits

I could set client refresh to a shorter duration then server cache for websites that we manage.

@Toflar mentioned, that contao caches client side by default for 24h?

[Toflar]

@Toflar mentioned, that contao caches client side by default for 24h?

I did not say that anywhere at all!?!?

[Ruudt]

@derhaeuptling The first result not from Google:

our data shows no clear correlation between document complete or fully rendered times with search engine rank

[Metis77]

@Toflar Expires: Die einfachere Variante des Cachings sagt dem Browser einfach "bitte behalte diese Datei für 24h im Cache und dann frag mich erneut für das File". Dies ist die Methode die Contao implementiert.

this was a generic example? Sorry if misunderstood.

@Ruudt you find what you search. The majority of answers concerning impact of page speed and page rank might show a trend. And it is, that there is an important and even increasing impact.

our data shows no clear correlation between document complete or fully rendered times with search engine rank

True but issn´t this more about loading content with AJAX and/or BigPipe? When talking about caching it is more about the static (document ready) part.

[Aybee]

@leofeyer If there are less than two visitors within 5 minutes, it means there are only about 12 page requests per hour. You certainly do not need any kind of cache in this situation.

But on every request the contao engine gets started which I do not need, or do I?

I'm talking about realy small sites with no dynamic content like a business card - maybe about 5 pages. (Yes it's worth to even build up such small sites with Contao. The clients can upgrade at any time and easily change agency if they want to.)

Clients sometimes ask me 'where are the html-files?' ;) I have no benchmark about it but I think a cached page is loaded way more faster than to run the Contao framework. Or do you think I should simply ignore this?

I can simulate a static page by setting server cache to 30 days and no browser cache. But then I need the option that cache gets rebuild as soon as my client does some BE changes. I always thought Contao will do that. Now I know it does not.

[fritzmg]

If there are less than two visitors within 5 minutes, it means there are only about 12 page requests per hour. You certainly do not need any kind of cache in this situation.

Why would you not need any kind of cache in this situation? These 12 page requests will be slower when not loaded from Contao's cache. Even if your website does not get a lot of traffic, you still want your visitors to see and move on your website as quickly as possible, would you not?

[leofeyer]

These 12 page requests will be slower when not loaded from Contao's cache

We are talking about a few milliseconds here! Not something a visitor would notice. Have you set up a test scenario and compared the two values (delivery with and without cache)?

Caching can speed up your website if your server is exceeding its limits, because it might decrease the number of processes or the amount of RAM required to deliver the site. At a rate of 12 requests per hour, the server is probably thankful that it gets something to do at all ;)

[Metis77]

We are talking about a few milliseconds here! Not something a visitor would notice. Have you set up a test scenario and compared the two values (delivery with and without cache)?

I have. no cache: 900-1000 milliseconds. (with some plugins sometimes more than 2 seconds) cache: 50-250ms.

Not something a visitor would notice.

Sure they can not tell the amount of milliseconds, but they notice if the website feels fast an fluid or not.

And exactly this feeling is, what search machines reward (see page speed).

[fritzmg]

We are talking about a few milliseconds here!

How can you even say that... the difference between dynamically creating one page in Contao (or Typo3, or WordPress) and loading it from the HTML cache simply depends at the very least on two major things: server environment & content on the page.

For instance - a random test on a page with ~13 modules in the frontend (of which the most important ones are 3 news lists, the other ones are from changelanguage, mod_navigation etc.) on a Hetzner Root Server EX40:

• Uncached: ~500 to 600ms
• Cached: 50 to 70ms

Whereas in another random example, where there are not as many modules (but still 3 news related ones), but running only on a Hetzner Webhosting Level 4, there is no difference at all. It's always around 250 to 300ms. Simply because the shared hosting environment won't give you a better server-side performance. The request itself simply takes up the most time.

Not something a visitor would notice.

I am sure that even a layperson will notice the difference between 50ms ("instant") and 500ms.

[Ruudt]

At a rate of 12 requests per hour, the server is probably thankful that it gets something to do at all ;)

Most websites are on shared hosting. We have our own servers and want to get the most out of them. The benchmarks above prove the need for cache but don't help this feature request

[Metis77]

The benchmarks above prove the need for cache but don't help this feature request

whenever huge cache times are in use, a simple and fast way to clear page cache is what id love to see.

[Aybee]

but don't help this feature request

To finaly come to a well elaborated solution I think discussing the cache is usefull.

This discussion turns out that people have different things in mind when thinking about cache.

Some are thinking of keeping heavy loads away from the server.

Others are thinking of delivering a page very quick and "fluid".

Both aspects are worth to find best solutions for handling the cache.

[Metis77]

Wegen: https://contao.org/de/news/github-tickets-aufraeumen.html

Ja ich finde das immer noch sehr wichtig.

1.) Meine Kunden vergessen das immer wieder und fragen, warum sie Ihre Änderungen nicht sehen. Sie wissen es zwar, aber denken nicht daran. Ist auch verständlich, wenn man nicht täglich mit Contao arbeitet.

2.) Der Workflow zum löschen ist umständlich, weil man jedesmal aus dem Element raus muss, wo man gerade gearbeitet hat.

Speichern & Zurück würde helfen, besser wäre aber ein "Seitencache leeren" Link direkt oben im Header vom Contao Backend, wenn der Seitencache aktiv ist.

[fritzmg]

Speichern & Zurück würde helfen

Das geht bereits. Einfach oben auf den Benutzernamen klicken, dann Seitencache aktivieren bei Cache leeren (oder so ähnlich) und dann Speichern und schließen.

Allerdings: 'Speichern und zurück' bzw. 'Speichern und schließen' funktioniert oft nicht. Der Grund warum das so ist wurde leider bis heute noch nicht gefunden.

Übrigens gibt es nun die Extension netzmacht/contao-cache-control, damit kann man gezielt den Cache von bestimmten Seiten löschen, allerdings auch nur über die Seitenstruktur.