Rails cache optimize

This uses the Rails caching mechanism to optimize database load on the application layer.
These optimizations were initially developed in #112 and rebased to the current staging branch.
Have you tested the view fragment caching with changing languages?

> On Dec 9, 2014, at 10:15, Will Jordan <notifications@github.com> wrote:
> 
> In dashboard/app/views/shared/_user_stats.html.haml:
> 
> > -                - if unplugged
> > -                  %span.puzzle-named
> > -                    =sl.level_display_text
> > -                - elsif css_class == 'passed'
> > -                  = check_mark_html
> > -                - elsif css_class == 'perfect'
> > -                  = check_mark_html
> > -                - else 
> > -                  %span.puzzle-number
> > -                    =sl.level_display_text
> > -  = render partial: 'shared/user_stats_key'
> > --if script.trophies?
> > -  %div{style:"clear:both"}
> > -  #trophies
> > -    =render partial: 'shared/concept_trophy_block', locals: { concept_progress: concept_progress, user: user, added_style: 'padding:10px;' }
> > +- cache([@script, user || session[:progress]]) do
> According to the doc:
> 
> Behind the scenes, a method called cache_key will be invoked on the model and it returns a string like products/23-20130109142513. The cache key includes the model name, the id and finally the updated_at timestamp. Thus it will automatically generate a new fragment when the product is updated because the key changes.
> 
> It might not be helpful for logged-in users that update for this reason, i'm not 100% sure and haven't tested specific edge cases. It might be more useful for a large volume of anonymous users with matching progress histories.
> 
> —
> Reply to this email directly or view it on GitHub.
>