The number of queries that run on every CMS page is still a big issue to many people, and one of the causes is the lack of virtually any template caching.

On an average page (in my test systems) I see anything between 20 and 40 queries run simply to get uncached templates. This amounts to something like 30% on some pages.

So, with the release of 4.1.11, we have added a simple mechanism which should more or less eliminate this entirely. The problem with the CMS is that you cannot do the same thing that has been traditionally done, just cache the templates that will be used, because its actually very difficult to determine (at the point the caching is done) which CMS templates will actually be used.

The quickest and most obvious answer is simply to cache them all - this is the ultimate "Sledgehammer to crack a nut" approach, but will actually work.

The best solution would be some way to know exactly which template will be used, and only cache them - however, this simply isn't possible with the way the CMS works.

Therefore what I have gone for is an in-between system, where we can predict which groups of templates will be needed (i.e. editor templates, widget templates, grid templates, comment based templates) and thus load smaller groups based on this. Its rather like a small hammer to crack the nut, not a sledgehammer, and not a precise nut cracker.

The result is basically that we predict what groups will be needed and load them - this will (and does) mean that we load more templates that are necessary, but in the end, we are trading about 30 extra queries for one extra query, and some php memory. Its far from an ideal or perfect system, but I believe the trade-off is worth it, saving up to 30% of query resources in some cases - which in turn should mean faster rendering pages, and less stressed servers.