Granular control of the block cache

Permalink
Concrete5 needs more granular control of the block cache.

( For those with access to the leaders forum, the thread on improved granular control of the block cache has become active again.
http://www.concrete5.org/developers/pro-accounts/community-leaders-... )

For those not on the leaders forum, a summary of the arguments by myself (and others) for c5 needing a more granular control of the block cache:

When a block is first coded, developers hard-code in flags governing when a block can or cannot be cached. These flags affect the block globally across all uses of the block.

The c5 block cache can only be switched on globally. So when the block cache is enabled, blocks are cached according to basic rules set by these flags. Furthermore, the full page cache uses the block cache flags when deciding whether a page can be cached.

Thus an inappropriate decision by the developer when a block is first coded can have widespread consequences for future caching. Such a decision cant be expected to be perfect for all future uses of a block. We just don't know how our blocks will be used or what block templates will be added in the future. The current all or nothing approach to the block cache is a poor and unnecessary constraint.

If we had an a page or block level dialog for users to provide their own settings where necessary, then situations where original assumptions about block caching are inappropriate would no longer hobble an entire site.

- Where block caching was unnecessarily permissive, block caching could be forcibly disabled just in that location.

- Where block caching was unnecessarily restrictive, block caching could be forcibly enabled in just that location.

Overall, we would see better use of the block cache, better use of the page cache, and faster concrete5 sites, especially where there is lots of user interaction.

If you agree with the above, please either respond on the leaders forum or here, even if you only have time to say +1.

Showing support is the best way to make this happen.

Thank you all

John

JohntheFish
 
mesuva replied on at Permalink Reply
mesuva
I'll +1 this purely because John is making the argument!

(but it also does sound very sensible to me)
Phallanx replied on at Permalink Reply
Phallanx
Just to be clear.

Are you proposing these extra settings because a block on one page may be cachable in the *block cache*, but not on another page (others on the page may not be cachable in the *block cache* even if yours is and prevent Full Page Caching). Or are you proposing this because an uncachable block prevents Full Page Cacheing?
JohntheFish replied on at Permalink Reply
JohntheFish
I think your first option best covers my intention. Your second option is a benefit, but of course can also be achieved by explicitly setting the page cache for specific pages.
Phallanx replied on at Permalink Reply
Phallanx
@JohntheFish
I can't get excited about block cache. I have doubts as to how effective it is. It's always off on my sites and I see no difference when turning it on. When I bench-marked all functions in CC5 a while ago, it was the On_Start event that weighed down performance and the cure was to not use blocks where developers load it up.

Without block cache:
http://www.webpagetest.org/result/140327_XN_2W8/...

With Block Cache:
http://www.webpagetest.org/result/140327_B0_2X0/...

No difference there!
I am, however, very interested in the full page cache as that definitely makes a huge difference. The full page cache bypasses the On_Start event and that's where a big chunk of the performance gain comes from.

Without Block Cache. With FPC
http://www.webpagetest.org/result/140327_M5_2RD/...

And with the event *on_page_output* in the full page cache, I can also use Miser.(I think I said before it was on_page_render-that's incorrect)

No Block Cache. With FPC. With Miser (check out the start render time :) )
http://www.webpagetest.org/result/140327_W6_2MK/...
JohntheFish replied on at Permalink Reply
JohntheFish
Is that with c5.6.2.1?
Phallanx replied on at Permalink Reply
Phallanx
===>Is that with c5.6.2.1?<===

Yes.
mnakalay replied on at Permalink Reply
mnakalay
Having absolutely no idea of the technical difficulty to achieve this, I still vote +1 because I can see the benefit.