Static site generation, explained without the jargon

It comes up on almost every project, usually later than it should. Here is static site generation without the vocabulary that usually surrounds it.

Most development decisions are really maintenance decisions wearing a different hat. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

Static files are the fastest and cheapest thing to serve. This is the sort of thing that compounds, quietly, in both directions. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The cost of getting this wrong is rarely visible on the day it happens.

No server means dramatically less to attack or patch. None of that requires a large budget, only a decision and someone to own it. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Where to go from here

Rebuilds can be automated on every content change. Where this goes wrong is almost never a lack of knowledge. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about static site generation before you move on:

• Someone can say what the current setup is without going to look
• No server means dramatically less to attack or patch — 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.