» « 

improving Octopress/Jekyll site performance – part 1 – DNS, hosting and CDN

By Damon Mannion · · ·

The performance of any website can be vastly improved by careful selection of service providers, and the correct configuration of these services. This article is the first in a series of three and covers the following services: DNS, Hosting and CDN. Part 2 covers configuration of Heroku and Sinatra and part 3 covers search engine optimization.


For a global site, the best performing DNS is an anycast network1, as this ensures DNS lookup times are consistent regardless of the geographical location of the browser. Given that this blog doesn’t generate any revenue, a cost-effective service was important. After some searching, I evaluated three options:

  • AWS Route53 – part of Amazon Web Services, but was the slowest. Their pricing is complex but for comparison purposes, 10 domains and 5m DNS lookups per month is $90 per year, and for one domain with 1m DNS lookups per month it’s $12 per year.
  • CloudFlare – is more than just a DNS, their service includes a CDN, page acceleration, security checking, DDOS protection, and more. However, you can switch all that off and just use their DNS. They delivered marginally the best performance. In terms of pricing, if you don’t need SSL, it’s free; if you do need SSL, then your first site is $240 per year, subsequent sites $60 per year.
  • DNSMadeEasy – was a very close second in terms of performance. They charge $30 per year for up to 10 domains with 5m DNS lookups per month.

My method for testing wasn’t overly rigorous, I used webpagetest from London, New York and Hong Kong and averaged the DNS lookup times over many tests. However, my results do agree with other published work from SolveDNS2 and CloudHarmony.

Despite CloudFlare being the fastest and cheapest, I moved my domains over to DNSMadeEasy. The cost is small, and I wanted to move all my domains to the same DNS service, and some require SSL support. If you want to save the $30 a year, and have no need for SSL, I would recommend CloudFlare.


Octopress/Jekyll produces static HTML, so the next piece of infrastructure is where the static site is hosted. The two popular hosting options for Octopress are the two I looked at:

Heroku runs on Amazon’s EC2 service out of their US east coast data centre. For comparison purposes, I created my S3 instance in the same data centre. Somewhat counter-intuitively, S3 was slower than Heroku, both for connection time and download speed.

Also configuring S3 for optimal browser caching/performance was difficult:

  • HTTP headers can be set correctly (for browser caching) but this has to be done on a per-object basis, the concept of (say) setting all assets to expire in the far future doesn’t exist.
  • Similarly for the redirect functionality, despite some recent improvements, it is set up on an individual files3, so wildcards are not possible.

As Heroku is easier to use, faster and cheaper (free), the decision was to use Heroku.


I looked at four CDN services:

  • AWS CloudFront – Amazon’s offering is simply a CDN and does exactly what you’d expect. Pricing is complex, but I estimate for low-volume sites it will be ~$2 per month.
  • CloudFlare – an ‘application CDN’ with performance optimization and security features, but I saw issues with variability in performance and this experience appears to be echoed by other users. Also, because you have to use their DNS, it becomes an ‘all or nothing’ choice, which I never like. The pricing is the same as described under DNS: free if you don’t need SSL.
  • Incapsula – an ‘application CDN’ with performance optimization and security features, their entry-level service is free but doesn’t really support Heroku as you have to direct the resulting traffic to an IP address instead of a CNAME. However, their support team (kudos to them, responding quickly to me even as a free-tier user) did set me up to correctly to use a CNAME record. Their free-tier includes on-the-fly image optimization, which would be of interest to many sites.
  • Fastly – an ‘application CDN’, free to develop on but does not specify what are the limits of this developer trial.

Here’s a summary of the CDN performance in seconds, using webpagetest from Tokyo and IE9, against damon.io/test:

service first byte start to render page complete
CloudFront 0.186 0.525 0.888
CloudFlare 0.637 0.996 1.339
Fastly 0.576 1.014 1.671
Incapsula 0.424 1.142 1.926
no CDN 0.658 1.129 2.137

In this test, using a well-optimized test page, the greatest performance gain was from using CloudFront. Be aware of these points, though:

  • CloudFront only refreshes its cache every 24 hours, to see changes you either wait or manually invalidate the cache. The other CDN services automatically spot changes and perform the refresh for you. If you have a requirement for frequent cache clears, and cannot automate the invalidation (I use cloudfront-invalidator), then CloudFront won’t work for you.
  • My blog pages are now well-optimized (see part 2 of this post for more details), so it can be argued (although I don’t agree) that this test is an unrealistic one. However, for less well-optimized sites, I do recommend that the other CDNs are evaluated as I suspect that their page optimization may win out over the additional work they do, see this post for more details. Also, for a more in-depth analysis of CloudFlare vs Incapsula I recommend you read husdal’s review.
  • After speaking to Fastly, I realized that this test is a little unfair to them, as they only have POPs in US and Europe (this is being expanded this year). Running a like-for-like test from the US, Fastly delivered the best performance of all. Depending on your requirements, this service could work best for you, certainly one to watch.


A surprising set of results. I expected S3 to be quicker than Heroku; Heroku won. I expected Route53 to be a very strong performer; it wasn’t. I also expected the ‘added value’ CDNs to work much better, but they didn’t. Two key take-aways from this:

  • there are big performance gains to be had from getting your DNS, hosting, and CDN right – this blog is over twice as quick as a result.
  • when it comes to performance (or anything else for that matter) never make assumptions!

Finally, I have left some of the examples above ‘live’, all of which are based on the same Heroku instance. I have pointed the URLs below at a test page, which removes the external links, so performance is solely based on assets served from the site:

www.damon.io is currently set to use DNSMadeEasy and Fastly.

Related posts:

  1. The traffic to this site from outside of the UK/US is negligible, but that’s not the point…

  2. Note that the figures are all from a US-based server, so not a good test for anycast DNS.

  3. And, it just seems wrong to have to create a file just to hang a redirect on it, when the very reason you’re creating the redirect is because you no longer have a page there…