Is Server-Side Rendering the Right Choice?

I have worked a fair amount with projects using server-side rendering. I have also worked full time with server-side rendering in the period, where using client-side rendering was the coolest way of working with the web. But now, it seems that server-side rendering is coming back in a cool way.

As I see it, server-side rendering is the OG of rendering web content. The way it works is that the client sends a request to the server. The server fetches all the required data and renders the application before sending the content to the client. When the client has received the content, it is almost directly available to the user. If you were using client-side rendering, the server might respond more quickly with a simple HTML document, Javascript and CSS, but the client would have more JavaScript to execute.

You are not required to have a budget on your JavaScript in the same way as when working with client-side rendering. We don’t need JavaScript to render the site and because of that, we are more likely to get faster FCP and TTI. We also are more likely to get better SEO, because the search engine crawlers easily are able to crawl the content of the site.

That all sounds great, but we should be aware of TTFB, as all of the processing is being handled by the server. With a slow server response time, the user experience will decrease, if the users are required to wait longer than necessary.

Today, there are frameworks that both support rendering on the server and the client for the same application.