Before you invest in server-side rendering

The advice here is unglamorous, which is probably why it gets skipped. Before you spend anything on server-side rendering, it is worth confirming a few things are already true.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Rendering on the server gets content in front of people sooner
• You have a way to tell whether it worked

Where it usually goes wrong

Crawlers see finished HTML instead of an empty shell. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

It adds infrastructure, so only pay for it when you need it. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

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
• Crawlers see finished HTML instead of an empty shell — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.