1

(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:

Pros

  • Everything static (except comments, Disqus there)
  • No access to database, probably better load/response times

Cons

  • Not much plugins (yes, Octopress does have some)
  • Customization not as easy or powerful
  • Schedule posts?
  • Docs and community inferior to Wordpress if you need help - one fantastic example ;)
Improve this question
  • 1
    @JMC: That's a huge myth. WP is targeted by hackers because it's the most popular CMS on the web. However, actual WP vulnerabilities are very rare (on par or fewer than equivalent less popular CMSes). The main reason WP users get hacked is because: 1.) they use one of the few versions that contain a security vulnerability; 2.) they use an insecure plugin. If you only use plugins from trusted sources and keep your WP setup up to date, there is no more risk from using WP than any other CMS. – Lèse majesté Apr 20 '12 at 9:34
  • I'm with Lèse majesté, it happens the same on Windows, which is simply more popular and a more attractive goal for attackers. A well configured WordPress with an admin that takes care shouldn't be more vulnerable that any other CMS or platform. – javipas Apr 20 '12 at 11:33
  • @Lese and javipas - Thanks for bringing up the points why it can be a security nightmare. WP is targeted because it's the most popular (meaning the most hackers are going after it), and not keeping it to the newest version at all times leaves you a huge target. The majority of webapps i've used don't have the must always be up-to-date problem. Hence it can be a security nightmare. Didn't say it's impossible to secure. – JMC Apr 20 '12 at 12:27
  • @JMC: Fair enough. But while security through obscurity can have an appreciable effect in practice. It too is very dangerous when it encourages a lax attitude towards security. I've been bitten by this mistake myself in the past. Statistically, it may take longer for vulnerabilities in less popular or custom CMSes to be discovered, but over long periods of time (especially on high traffic sites), the chances of them being discovered is still 100%. So, for business sites, I wouldn't even factor in obscurity as part of your security policy. – Lèse majesté Apr 20 '12 at 13:34
  • @Lèse, my tone may not have been clear, but I was actually thanking you for highlighting the reasons, since I hadn't looked into the root causes. I've done a lot of wordpress database cleanup for people over the last two years who had hacked wp blogs (spam links injected in articles and total display presentation changes through injected iframes). There was also one that was turned into a bank phishing site. One common thread between each blog was that it was an outdated version. – JMC Apr 20 '12 at 14:44
1

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.

Improve this answer
  • Thank you so much for your insight Lèsse majesté, your points are really reasonable. I've been using a Nginx+Varnish+Varnish+Memcache configuration -with cache plugins, yes- and the performance is really nice, but I kind of felt that maybe static blogging services could be useful. The site generation time is a problem for a magazine, because you don't want to wait an hour to publish hot news, but there are other options (Pelican, skrivr?). Anyway, caching can in fact be really helpful, and with a good CDN and other ideas such as yours the WP option probably wins on my case study.Thank you. – javipas Apr 20 '12 at 17:54
0

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.)

Improve this answer
  • Unique visitors is not an estimation of traffic load, which is represented by hits/pageviews. A site with 1M unique visitors per month could have 1M hits per month or 2B hits per month, depending on usage patterns. Also, you're assuming a constant traffic load. Most sites have peak and off load periods where they get above/below average traffic loads. Having a server that can handle your average load isn't much use if your site keeps crashing during peak loads. – Lèse majesté Apr 20 '12 at 9:41
  • Fair point john, I probably should have given some estimate data for pageviews, which for a magazine like the one I am talking about would be around 2 or 3 times the uniques. As you may know, an online magazine is not a social network: users check once or twice, but not necessarily 20 times a day. Also, not everything can be cached, so using static for everything would be interesting, I think, although I don't know if it would be so interesting to sacrifice WP benefits. – javipas Apr 20 '12 at 11:32
  • @Lèse majesté: All your points are correct of course, yet to make a specific analysis you need specific input, which we don't have. So, we can just make a simple average estimation to get a feeling about it. In practice, unless your site is being Digg'd, your load during peak time will not be orders of magnitude more that the average. – john Apr 20 '12 at 11:59
  • 1
    @javipas: When you do full page caching, everything that matters gets cached :) Just make a nice setup (APC/Memcached etc). Many plugins can do it, here 's one of the lesser known as I assume you 've done your research: petermolnar.eu/open-source/wordpress/wp-ffpc - I 'd create a demo site and stress it with "fake" traffic while using various plugins to find the best that suits my specific needs. – john Apr 20 '12 at 12:10
  • 1
    @john: I think you're correct up to a point. Many sites certainly don't have extreme peak/off-peak hours. However, a good portion of sites do get 90% of their traffic either during typical business hours or "primetime" after-work browsing hours. Still, I agree with your point about premature optimization. – Lèse majesté Apr 20 '12 at 13:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.