Static site generation: the questions we get asked most

The gap between knowing this and actually doing it is where most teams lose ground. The questions about static site generation that come up most often on our calls.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Do we need to care about this?

Static files are the fastest and cheapest thing to serve. Where this goes wrong is almost never a lack of knowledge. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Rebuilds can be automated on every content change. Small and consistent beats large and occasional here. If two people in the business would answer this differently, that gap is the actual problem.

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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.