: Could Jekyll/Octopress and other static blogging engines be a good option for a heavy online magazine? (Disclaimer: I thought this question should be asked on SuperUser, but it seems that was

@Shanna517

Quite a few very high profile/traffic sites have switched over to static site generators like Jekyll and Octopress. However, while there are some performance, deployment and security benefits to a static site, there are also a lot of drawbacks. There is a reason why most sites on the web today are dynamic, and why most CMSes aren't static site generators.

The main drawbacks you need to consider are:

Site generation time

There's no such thing as a free lunch. Static site generators don't get rid of the page-generation and processing that conventional CMSes do; they simply divert this task to a different time/place. The same work still has to be done, but instead of splitting that work over hundreds or thousands of requests, the generator does it all at once. This may save your visitors precious milliseconds, but it can really add up in site generation time.

As your site grows larger (or if you're converting a site that already has a significant amount of pages), your generation times for things like making layout changes (nav, heading, footer, sidebar content, etc.), generating tag or archive pages, etc. starts to take more and more time. I highly recommend reading this webmaster's account of his switch before taking the plunge yourself.

So if you have a large site that depends on timely updates, you may need to get rid of features like tags, related posts, archive pages, etc. so it doesn't take you an hour to generate the site each time you make a post.

Luckily, if content update lag time doesn't affect your site, you can probably automate the process such that your content writers simply submit their posts to an update queue, and the update script handles the site generation in the background unattended. It may still take an hour before the post is up, but it's not wasting anyone's time.

Static sites are very limited in functionality

You can embed non-static components into your site, but this gets rid of many of the benefits of running a static site, and it also requires you to manage your site from multiple locations. And some features simply can't be provided via an embedded SaaS service, e.g. live content management, JS-free + search-engine-friendly comments, user management, etc.

Other features, like faceted search, dynamic navigation (e.g. most popular posts, recent pages, community tagging, etc.), web services (SOAP/XML-RPC), session management, etc. become really difficult and awkward to implement. Basically, you should be sure you don't want to extend your site beyond a basic blog.



Luckily, however, most blog sites can have their core features implemented on a static site. So the drawbacks aren't as serious as for other types of sites (e.g. community or membership sites, e-commerce stores, etc.); so it's really just about weighing the costs vs. benefits. There isn't really a right or wrong answer here, and it depends as much on personal preference as it does site requirements.

However, if your main motive for switching to a static site generator is performance, you should probably first explore other options like:


offloading static assets to a lightweight web server like nginx + a cookieless domain
using full-page caching (which after the first request for the page will essentially be like having a static page)
query caching so that DB requests happen infrequently
using client-side caching
consolidating resources to minimize HTTP requests
increasing parallel downloads


If you set up the dynamic site correctly, it could potentially be faster-loading than a static site that uses a bunch of 3rd-party JS embeds for things like comments, trackbacks, etc. So as john suggests in your comments, you should actually benchmark your site and find out where your true performance bottlenecks are. It may be that a CDN or CSS/JS consolidation would have a greater performance benefit for your site than switching to a static site that adds even more linked JS & 3rd-party dependencies.

Vote Up Vote Down

@Radia820

I don't get it. If you are doing proper caching, what needs to query the DB all the time as you say? And is that something that you need to use? If yes, will you not have to use it on a static site?

1M uniques per month is like 24 uniques per minute. That 's rather not a heavy load even for a mid-ranged VPS. Especially if you 're caching things. And you can always use something like nginx to make the serving of the static parts more efficient (images etc.)

Vote Up Vote Down