There’s a flurry of conversation among those who build and host blogs on the subject of “baking”, i.e. causing your blog’s pages to be served using of ordinary “static” files stored on disk, as opposed to assembled at request time with calls to a database. Brent Simmons is sort of driving; see A plea for baked weblogs and More on baked blogs.

First, a couple of add-on technical points:

  • Serving pages out of flat files is even better than you think it is, because when the load gets heavy, your operating system tends to cache these pages in memory, and so if a page is getting requested steadily, the disks may not be involved at all.

    This site, which runs on a perfectly ordinary mid-range Linux server shared with several other applications, can soak up a heavy simultaneous flow from Hacker News and Reddit and Daring Fireball and Slashdot without even breathing hard.

  • You can serve static pages and still be dynamic. For example, on the pages here, there’s run-time stuff that twiddles the little picture on the right and decides whether comments are accepted. But it works by having JavaScript code on the client fetch static XML files and splice bits and pieces right there on your computer. So from the server’s point of view, you’re still just fetching static files.

How I Do It · The way this blog is baked is bone-crushingly simple; not all that flexible but very lightweight, and has served me well. Maybe some variation of it will be useful for others.

There’s a Magic Number, and that number is 20. The 20 most recent pieces (excluding “Short-form fragment” Twitter roll-ups) appear in the Atom feed and are eligible for commenting.

The site is republished automatically every eleven minutes or so by a cron job. “Republishing” means going through the Magic 20 and checking, for each, whether the source has been updated, or one of the pictures has been refreshed, or whether new comments have arrived. There’s a dorky little MySQL database to make this easier.

If any of these changes have happened, the piece in question has its static form rebuilt; this includes splicing any assembled comments onto the end of the article.

That’s all.


Comment feed for ongoing:Comments feed

From: Kevin Spencer (Mar 18 2011, at 14:47)

Serving static pages is always what I've loved about Movable Type since I started using it all those years ago.


From: Hub (Mar 18 2011, at 15:15)

Any chance that you publish the software?

Just wondering.


From: Ed Davies (Mar 18 2011, at 15:32)

For Brent Simmons's dynamic authoring/static publishing/multiple authors case it seems to me that a DVCS would make good glue. E.g., have your cron job do "$dvcs pull;$dvcs up" as its first step. Pushing the publish button does "$dvcs push" as the final step.


From: Tony Fisk (Mar 18 2011, at 17:51)

I run a simple but pretty well featured wiki for my Bushwalking club at that uses static pages. This was a necessity since the host doesn't provide database support. Can't complain for the cost!

I haven't configured it as a blog, but I think there's cookbook articles on the topic.

The engine is 'pmwiki'


From: Amitai Schlair (Mar 19 2011, at 04:24)

ikiwiki ( is very good blog software. It publishes baked content and integrates with your VCS of choice.


From: len (Mar 19 2011, at 11:41)

I hardcoded the web pages for my last employer. They were more reliable and easier for me to maintain because once the owner *finally* made up his mind, the rate of change was zilch. The original design out of India was database driven with a template. It tended to look very cookie cutter and updates through the communications channels were poor. Give me a directory, ftp privileges and it's easy. Given all the moving parts and technologies in web sites these days, simpler is better. If there is a higher rate of change below the level of the page, I'd do it differently but given low rate of change and low granularity, it isn't worth it.

As I recall, there were some long threads about this on XML-Dev back in the day. Deep linking makes a difference. d'oh.


From: Derek K. Miller (Mar 19 2011, at 12:11)

I've always published my blog as static files, and it has been able to handle steady traffic growth and occasional heavy spikes (on a cheap shared host) without trouble for more than 10 years. Plus if my blog software or database is disabled for any reason, my blog doesn't just disappear.

Built-in static publishing is why I chose Movable Type when switching blog platforms last year, when every other criterion was pushing me in the direction of WordPress. Some background:


From: Nick Johnson (Mar 19 2011, at 20:32)

This is what I based my "how to build a blog on App Engine" series on ( - though I didn't call it baking, since I didn't know there was a term for it at the time. Since you can't write to the filesystem in App Engine, it stores rendered pages in the datastore, but the pipeline is still a lot shorter and more efficient than your typical dynamic rendering one.


From: Rui Carmo (Mar 20 2011, at 12:23)

I've been doing that for a while - in fact, ever since I realized the bloat and waste involved in the "layered" models for something as simple as rendering web pages.

It's gotten so streamlined that I don't think twice about it these days, but the key to doing it right is (I believe) proper HTTP header handling even if you don't bake stuff.

And, of course, you can streamline baking quite a bit, and do it speedily - hence my Yaki's "grilling" metaphor :)


From: Charles (Mar 20 2011, at 16:21)

Have you looked at FlatPress?


From: ebenezer (Mar 21 2011, at 13:58)

@Hub: There seems to be little chance. See :

"I will never release the core publishing software for ongoing to the world, simply because I wrote it in a big hurry and with no other objective than supporting my idiosyncratic writing workflow."

That said, I would like to see it.


author · Dad · software · colophon · rights
picture of the day
March 18, 2011
· Technology (77 fragments)
· · Publishing (154 more)
· · Web (385 more)

By .

I am an employee
of, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.