Last night for “fun” I did some performance analysis of the CloudFlare service. For those of you that don’t know, CloudFlare is a DNS that also acts as a cache using a reverse proxy - what this means is that you set CloudFlare up as your DNS and it has servers that sit in-between your host and the client. For example www.mysite.com would actually point to a CloudFlare server that then points to your host.
I used a currently in-development python/django web app. The setup for this has a single apache install serving static files on one virtual host directly from the file system and another virtual host serving out the dynamic python pages. I can then access the two parts via two different URLs - www.myapp.com and static.myapp.com. I used a fresh browser session and ensured that every request did not use the browser cache.
All three of the pages tested on average were faster with CloudFlare. Two of the pages (Login and Job Search) on average had over 1 second taken off the time with CloudFlare. On average pages loaded in 72% of the non-CloudFlare times. Interestingly, on average images were slowed down by CloudFlare. Without CloudFlare images loaded on average in 172.62ms with CloudFlare the average increases to 247.38ms. Ignoring images an average page loaded in 59% of the non-CloudFlare version. The HTML was a little faster through CloudFlare but I didn’t really expect this to change as this is bypassing CloudFlare’s caches. All results can be found on a Google Drive spreadsheet here.
I think its pretty cool that just by configuring your DNS you can see page load times almost halved especially as you can fulfill most of your needs on the free plan. Its strange that the images take longer – I wonder if this indicates that a lot of the performance gains are in the minification (although this doesn’t look to be the case all of the JS is already minified!).
This is all a little fabricated as all of these examples would have their load times reduced dramatically the second time anyway as the browser is going to cache static content. I see real potential for websites that are updated infrequently and that have the majority of content as static: blogs, company websites, personal websites. Either everything can be cached and you manually flush the CloudFlare cache if you do an update or carefully tune the TTL on the CloudFlare caches.
Caching on a remote server that you have no control over might seem like it comes with issues but CloudFlare provide some pretty cool mechanisms for dealing with this. Firstly the caching strategy can be configured, should it take into account URL parameters for example. The URL pattern based rules also allow for further config. Theres a control to purge the CloudFlare caches entirely for your site or do it on a file by file basis following a release of new code. They also provide a developer mode that disables the cache for 3 hours so you can deploy over and over without having to worry about hitting the cache or forgetting to turn it back on at the end.
Because CloudFlare is a proxy it can ruin logs from your hosts webserver because it will appear that all requests have come from the same location (CloudFlares servers) but they provide the originator IP address in the HTTP request header that is forwarded to your host and they also provide an apache module that can be installed to get apache to rewrite things back to normal as if CloudFlare were never contacted.
Un addition CloudFlare provide an HTTP header to the client indicating if a file was a cache hit which can be useful for debugging.
Theres loads of other features provided such as analytics and security with the ability to mask actual servers addresses. You can see more here.
I like it, its really well setup and easy to use with a nice interface you can get performance gains for almost zero effort. I’ve now enabled it for this blog and have installed the CloudFlare WordPress plugin.