(Disclaimer: I thought this question should be asked on SuperUser, but it seems that was not the right place. Hope this one is more appropiate.)I'm exploring several options for setting up a static blogging engine and migrating there some contents for some blogs I've got. I'd like to test the performance of these engines, and I've heard great things of Jekyll and Octopress.I wonder though if these kind of engines would be suitable for heavy sites, which are updated 20-30 times a day (or more) and receive a good amount of visits each day (let's put a starting hypothetical number: 1M uniques per month). WordPress is a fantastic CMS, with lots of potential on every aspect, but although there are caching plugins such as W3 Total Cache that allow certain parts of the blog/magazine to behave as static, the dependence of other parts and above all the need to access MySQL all the time can make the blog problematic. Given that static blogging engines don't need a database, I wonder if it would be crazy to try to adapt one of them to publish a magazine in which all articles would be static web pages and that would have comments based for example in Disqus. Are there technical issues with this idea? Recalling my ideas, these would be the pros and cons:ProsEverything static (except comments, Disqus there) No access to database, probably better load/response timesConsNot much plugins (yes, Octopress does have some)Customization not as easy or powerfulSchedule posts?Docs and community inferior to Wordpress if you need help - one fantasticexample ;)
Could Jekyll/Octopress and other static blogging engines be a good option for a heavy online magazine?
wordpress;blog;mysql
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 timeThere'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 functionalityYou 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 domainusing 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 infrequentlyusing client-side cachingconsolidating resources to minimize HTTP requestsincreasing parallel downloadsIf 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.