How to get static site generation right
It comes up on almost every project, usually later than it should. The short answer to static site generation is that it is mostly a sequence of small decisions, not one big one.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What it costs to ignore
Static files are the fastest and cheapest thing to serve. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.
The steps
- Establish what you have today before changing anything
- No server means dramatically less to attack or patch
- Rebuilds can be automated on every content change
- Write down the decision so the next person does not re-litigate it
Rebuilds can be automated on every content change. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Making it stick
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
- Static files are the fastest and cheapest thing to serve — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.