The real speed advantage static rendering has over dynamic rendering

March 18, 2015

This entry made the Hacker News front page for much of Sunday, spending a bunch of time at #1 (clearly Sundays are slow news days) and giving me another opportunity to beat the drum about my views that dynamic sites don't need to be slow. So today, I'll take the other side and point out the real speed advantage that static rendering has over dynamic rendering.

Put simply, the advantage is that all static rendering is fast while only carefully tuned dynamic rendering is fast. Sure, you can make dynamic rendering go fast on ordinary hardware, and this blog is an existence proof; even with a crazy lashup it runs pretty fast. But you have to work to get fast dynamic rendering, and there are a huge number of ways to get slow dynamic rendering and plenty of software that behaves this way. Slow dynamic rendering is kind of the default state with many setups, software frameworks, system designs, and so on.

By contrast, you have to work really hard to make static rendering go slowly; speed and low impact is its natural state. Pretty much any current webserver with a vaguely rational configuration is going to be really fast at serving static files (especially relatively small ones). I'm not actually sure how you'd make a modern web server do this slowly.

So the default for static rendering is fast and the practical default for dynamic rendering is slow. And this is the real speed advantage; if you pick a random static rendering system to use, you're basically guaranteed to go fast. If you pick a random dynamic rendering system, you're probably going to be slow by default and perhaps fast with some amount of careful investigation and tuning.

(This is also true if you write your own system. A static system is again intrinsically fast on the web server, while you can look forward to paying attention to your dynamic system to make sure you haven't accidentally made it slow.)

Although I continue to feel that dynamic sites have significant advantages (including a more liberal URL design) and are not particularly hard to make fast enough for most people, I have to admit that this is a not insignificant advantage to static sites in practice. Like everyone else, I've heard any number of people be unhappy about how their off the shelf dynamic site is not doing too well under load; say what you like about static site generators, but these people wouldn't be having that problem if they'd used one instead.

PS: Based on a very brief log analysis, the volume from this Hacker News appearance was about the same as the first time around so I don't intend to do a writeup on it. I also suspect that my link experiences are not necessarily a good guide to the amount of traffic that HN directs to its (really) popular links. On the other hand, maybe not.


Comments on this page:

From 46.144.78.131 at 2015-03-18 07:58:31:

Paul Vixie's point on the static/dynamic discussion from the security point of view:

http://queue.acm.org/detail.cfm?ref=rss&id=2721993

I've been favouring static rendering that goes into an in-memory data structure rather than out to disk, as in Plack::App::Hash. This can give you the advantages of both plus a theoretical shot at performance higher than going out to disk. In practice I like it mostly because it makes it easy to design a clean URI space without fiddling around trying to get a fiesystem to look like one.

By cks at 2015-03-19 13:08:39:

That's a really interesting approach given today's memory sizes and the typical (fully-rendered) size of many sites. A couple hundred MB of RAM probably cover even a relatively large site and that's not going to be noticed much on a modern server (assuming it's shared, and there are ways to arrange that).

Written on 18 March 2015.
« Solving our authenticated SMTP problem by rethinking it
A brief history of fiddling with Unix directories »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Mar 18 01:44:37 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.