Caching Drupal for Authenticated Users
This past week, I was chatting with my friend - and ex-boss - Chris Fuller (cfuller12) from Optaros about caching pages for authenticated users. He'd been implementing authcache to cache pages for his latest deployment but was going to need to do some tweaking to get dynamic aspects of the page working for logged in users. I've been busy writing proposals and keeping the Achieve-machine moving forward so the development challenge was a great reason to do something else for a little while.
Chris and I chatted for a little bit, I reviewed authcache's implementation for callbacks, and I spent a little time thinking about how Drupal handles caching natively. We've done a fair bit of work on large sites here at Achieve - and Steve Rude (slantview) and I have worked together a fair bit - so I've been privileged to work, at least peripherally, on a significant amount of performance-related issues. As a result, I wanted to see if I could develop a solution that leveraged a little bit more of Drupal's built-in caching and required a little less extra development work to get things working. Thus was born ajaxify_regions.
Wow, I think I heard a groan. Yes, fine, it's not a great name - as I've already been told by the aforementioned Steve Rude, so if you have a better name, let me know - but it'll do for today. There are plenty of things that could be done to continue to improve performance on this lightweight caching system, but the beauty of ajaxify_regions is that it leverages things everyone already does to make utilizing a page-level caching system seamless.
Brian Kennedy (brianpkenne
So far, I've only tested the system with authcache, but simply enabling the module should turn any block that has been defined as unable to be cached, is cached per user, or is cached per role to be retrieved via a single ajax callback. So, if you have 3 blocks that shouldn't be cached for authenticated users, the blocks are replaced by js, the page is cached with the js, and, at runtime, the blocks are retrieved via an ajax callback this is simple and seamless. Now the pages can be cached without issue, and we simply retrieve the blocks that are unique for that user.
I'm sure the solution can be trimmed down, and I'm sure it's not the end-all be-all, but for a few hours work, we've got a solution I'm pretty happy with. If you get a chance, download the module, test it out and send me feedback. I'd love the project to evolve and make authenticated page-caching something that we do on every project large or small, and I hope this is a step in that direction.
-- Bill (csevb10)
Is this really an improvement?
It seems to me that this replaces one Drupal bootstrap (the original non-cached page) with potentially multiple Drupal bootstraps (one for each non-cached block). That only makes sense if the cost of generating the original page post-bootstrap WITHOUT the non-cached blocks is higher than multiple bootstraps. If the page a View or something similar with complex, expensive queries, that might be true, but it is also the case that often the complex and expensive queries are used to generate the blocks... so caching everything but the blocks means you are caching the "easy parts."
I suppose this strategy also makes sense if the site prefers a user experience in which the primary page content comes up as fast as possible, not caring if the blocks get filled in somewhat later (e.g. like images). That seems like it could be a valid choice. You will have to choose between using CSS to pre-size the block areas, resulting in fixed block sizes, or having the page flicker as the blocks fill in (a bigger problem if the blocks are in the header than in the sidebars or footer).
As another point, this process probably increases the overall load on the web stack, since in general bootstrap is in fact a substantial cost.
Actually...
Interesting approach
Thanks
Gave you a bunch of issues