Or: Making my blog go fast!

As you might have noticed I relaunched my blog two weeks ago. I wanted to run something that's a lot more lightweight than TYPO3 (I'm still a fan of TYPO3, but in the meantime I learned to pick to right tool for the right job...) and wanted to bring the fun back into writing blog posts by writing them using Markdown on my computer instead of dealing with an RTE. I explored a couple of static file CMS and Grav met all my requirements: It's PHP, it's free, it's truly open source, it's actively developed, it's easy to learn, easy to customize, easy to extend! Plus the developers are super responsive. Get in touch via gitter.im/getgrav/grav

But there was one tiny little problem: After exporting all my blog posts from TYPO3, converting them into Markdown and "importing" them into Grav the response times on my website were slightly slower than before. Both TYPO3 and Grav are caching content, but TYPO3 had some more secret sauce: nc_staticfilecache (checkout this new video in case you understand German)

The idea is super simple and highly effective. Of course you could come up with a much better solution that involves Varnish, CloudFront or another external cache solution, but again, let's pick the right tool for the right job! :)

This cache acts like a full page cache and stores the rendered content into a file in the file system. Using mod_rewrite this file is being directly delivered while PHP isn't even executed. And if the file doesn't exist mod_rewrite automatically falls back to hitting the CMS.

While the nc_staticfilecache module comes with a lot more features than only storing the generated content into a file (purging cached content once a page has been update, crawling,...) I consider these feature to be unnecessary (or at least "nice-to-have") for a scenario like my blog being run with Grav.

So I implemented a plugin for Grav. Check it out on GitHub:

grav-plugin-staticfilecache

My main goal was to keep everything as simple as possible. So currently every page is being cached (no whitelist/blacklist support), and the cached content will never be deleted unless you delete the cache/staticfilecache manually or you run bin/grav clear-cache --all.

Since my blog is fully static (comments are done via disqus) the only time the cache needs to be refreshed is when I add new content. The nature (and the beauty) of a flat file cms allows you to store everything in git, so my deployment strategy is to edit the content locally, commit/push it to git and "deploy" it by doing a git pull on the server followed by a clear-cache.

The first time a page is being hit the rendered output is being stored in cache/staticfilecache and mod_rewrite will deliver it from there. In case you don't have mod_rewrite in place an early event fired in the Grav request lifecycle will take care of checking if the file exists, delivering it and existing early.

It really doesn't get simpler than this. And the effects are instantly visible:

Speed comparision

Comments

This website uses disqus for the commenting functionality. In order to protect your privacy comments are disabled by default.

Enable Comments