A practical checklist for static site generation

The advice here is unglamorous, which is probably why it gets skipped. Run through this the next time static site generation comes up.

Most development decisions are really maintenance decisions wearing a different hat. The version that survives contact with a real deadline is the simple one.

The checklist

• Static files are the fastest and cheapest thing to serve
• No server means dramatically less to attack or patch
• Rebuilds can be automated on every content change
• Someone is named as the owner
• There is a date to review it again

The reason this keeps coming up

Static files are the fastest and cheapest thing to serve. The reasoning matters more than the rule, because the rule has exceptions. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about static site generation before you move on:

• Someone can say what the current setup is without going to look
• Rebuilds can be automated on every content change — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.