A short guide to server-side rendering

This is cheap to get right at the start and expensive to retrofit. Everything we would tell a client about server-side rendering in the time it takes to drink a coffee.

Most development decisions are really maintenance decisions wearing a different hat. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Why this earns attention

Rendering on the server gets content in front of people sooner. This is the sort of thing that compounds, quietly, in both directions. If two people in the business would answer this differently, that gap is the actual problem.

How we handle it

Crawlers see finished HTML instead of an empty shell. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The mistakes we see most

It adds infrastructure, so only pay for it when you need it. That sounds obvious written down. It is still the thing most often skipped. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

How to tell if yours is fine

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 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 you want a second opinion on how yours is set up, ask.