When to use SSR instead of static
I’ve talked before about the benefits of a static frontend for scalability, performance, and cost. I’ve used it to great effect in my own projects. However, there are some situations where server-side rendering (SSR) is actually a better choice.
When it actually needs to be dynamic
The obvious case where SSR is preferable to static is one where you actually need your content to be dynamic.
One example I’ve seen in the wild is meta information for a page. These are tags that go in the head of your HTML document, like:
<meta
content="This is the description of my very cool site!"
name="description"
/>These meta tags can provide all kinds of information, like your site title, description, or Open Graph image URLs.
This last category—Open Graph properties—is particularly tricky. They’re used when you post a link somewhere like Twitter, Slack, or send it in a text message. If a title, description, or image pop up, they were likely powered by those Open Graph properties. The tricky bit is that Twitter, Slack, etc. aren’t executing any Javascript on the page when they look at these tags. So that means the tag must have a value without executing any Javascript. This prevents us from fetching data to hydrate the tag values. Rather, they must be there when the HTML comes from the server.
If the tags aren’t going to change and don’t need to be fetched, you can still build the page statically. The tags will have values. But if you’re in a situation where the tags can change based on URL parameters to your page then you basically have two options:
- Build a static page for every possible combination of input parameters, or
- If you have a prohibitively large number of inputs and can’t build that many static pages, you’ll have to render on the server before sending the HTML to the client.
When there are multiple calls to co-located servers
Another situation where SSR could be preferable to a static site is when you need to fetch a lot of data to hydrate your page. If you’re doing this from the page in your client’s browser, each call could take a few hundred milliseconds, just due to the round trip delay between their browser and your servers.
If your servers are all co-located within the same datacenter though, making those calls server-side could be nearly two orders of magnitude faster (single or low double digit milliseconds, as opposed to three or even four digit milliseconds). Normally a static page will be rendered and usable faster in a user’s browser than either an SSR or a CSR (client-side rendered) page, but if the cost to fetch data is too high, you might find that using SSR actually gets a usable page to the user more quickly.
In sum, static frontends tend to be easy to build and maintain, and they’re cost-effective. But when the situation actually calls for dynamic content, or when the page depends on many different network calls to your datacenter, you should use SSR.