A short guide to static site generation

This is one of those topics that looks small until it costs you something. Everything we would tell a client about static site generation in the time it takes to drink a coffee.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What is actually at stake

Static files are the fastest and cheapest thing to serve. Where this goes wrong is almost never a lack of knowledge. Doing this properly once is usually cheaper than doing it approximately three times.

Where to start

No server means dramatically less to attack or patch. It is worth being explicit about, because assumptions differ quietly. If it only works because one person remembers to do something, it does not work yet.

Common failure modes

Rebuilds can be automated on every content change. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

Most development decisions are really maintenance decisions wearing a different hat. 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

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.