4.3 BF-Cache header no-store

[angieradtke]

Hi
I have recently taken a closer look at performance and Co2 consumption.
In the context of this, the focus was on the BF Cache.
The topic at now picked up speed again, because now also chrome has implemented this technique and that means,
if there is something wrong, you can see it now in lighthouse.
Previously, only the edge dev-tools have complained about this. Firefox and Safari have this technique for a longer time
Anyway, whenever the http header is output with no-store, the BF cache cannot take effect. I have almost only multilingual sites and see the use of no-store there. Does anyone know why the header is using no-store and how we can change that.

Links:

• https://csswizardry.com/2019/03/cache-control-for-civilians/ -> in the middle ao the article
• https://chromestatus.com/feature/6705326844805120
• https://web.dev/bfcache/

Kind regards Angie

[wilsonge]

In core it's going to be there for anything that requires authentication - we can't have conditional content shown to users because it could cause security leaks on shared computers.

Also on any page that contains a form (even if everything is public) it also can't be cached by the browser because the CSRF token would be cached (so even if there's a login form with public content we can't use browser cache)

So that's going to be all the backend where we can't cache and obviously the frontend will depend on how your using authenticated items and forms. Basically we can probably only enable this if we have Joomla's full page cache enabled on the page - on all other pages we probably can't.

[angieradtke]

Hi George,
as I understand, no cache and no store are two different things. Whenever we have sensitive data like logins etc "no store" really makes sense, but when it comes to the output of content it is not needed and no-cache is enough. Right?

[wilsonge]

For pure content no-cache is enough as long as you're using full page cache still (because you need to validate the etag and that's part of the PageController)

You'll need no-store on any page with a form (because you can't cache the CSRF token) and for the sensitive data as we agree. And yes for the rest no-cache as long as you use the full page cache controller should be enough - in those specific scenarios we can probably remove no-store.

[angieradtke]

That would be great. Is that complicated?

[SniperSister]

What about using the private keyword? It's supposed to be used for anything that's session based and therefore might contain user-specific contents. How does that work with BF-Cache @angieradtke ?

[rabidgrowth]

Plugin, com_ajax + Joomla.getOptions('csrf.token', '') for security. I have no form. BF-Cache breaks the fetch com_ajax, no?

Module, scroll of comments. Its writing refreshes when you visit other page. BF-Cache breaks refresh, no?

BF-Cache appears good for newspapers, portofolios, such sites. You can make it option with the plugin System - Page Cache.

[angieradtke]

This seems to be more complicated than I thought. But he integration in lighthouse will lead to many questions.

@SniperSister , what do you mean by private function ?
Do you mean that no-store could be replaced by private?

$this->app->setHeader('Cache-Control', 'pivate, no-cache, must-revalidate', false);
instead of
$this->app->setHeader('Cache-Control', 'no-store, no-cache, must-revalidate', false);

What are the implications of this?