This issue is evolution of #1413

I dedicated to making it done by 1.6.0 (tested, reviewed, ready for production). That's why I put Milestone (Deadline motivation)

My first idea in #1413 was based on hacking backdrop_render in a way of making md5 on all INPUT data to theme function and caching it output.

New idea based on: - if no $elements['#cache'] provided - build cid based on md5 of INPUT data. (proactive caching) By default most of the theme functions are cachable. There is an exception to the pager, node_view and few more theme functions. - we need to build exception if INPUT data contain object of class (like Node). Then $elements['#cache'] should be FALSE until developer properly set this value to do caching. - implementing $elements['#cache'] into each theme function in CORE that require custom handling: node_view, views, pager and etc. - implementing $elements['#cache'] = FALSE; and properly handling it in backdrop_render. - handle backdrop_add_css & backdrop_add_js inside function (It was done in #1413 code. Not a problem anymore)

Benefits

• it will speed up backdrop core out of the box up to 40% after cache warmed up.
• make developer live easier and make code faster by default. No need to think about $elements['#cache'] except if theme function contains logic or data that require custom cache settings.

There is a change of behavior from default Drupal 7 and backdrop before 1.6 (or whatever release number will be ). It is under concern and feature need to be documented properly.

At this point, I need all your ideas about this feature. I want to go throw all contrib modules and themes to make sure new feature compatibility. I will need hands and help on that task for sure.

Looking forward to your feedback.

PS: Yes, this feature should be optional by admin section. We can start with disabled by default until we decide to make it enabled by default due to stability.