A practical checklist for server-side rendering
We end up explaining this on discovery calls often enough that it deserved writing down. Run through this the next time server-side rendering comes up.
The question is rarely whether something can be built, but what it costs to keep running afterwards. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
The checklist
- Rendering on the server gets content in front of people sooner
- Crawlers see finished HTML instead of an empty shell
- It adds infrastructure, so only pay for it when you need it
- Someone is named as the owner
- There is a date to review it again
The reason this keeps coming up
Rendering on the server gets content in front of people sooner. This is the sort of thing that compounds, quietly, in both directions. Write the reasoning down alongside the decision, because the reasoning is what changes first.
How to tell if yours is fine
Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about server-side rendering before you move on:
- Someone can say what the current setup is without going to look
- It adds infrastructure, so only pay for it when you need it — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.