In this article we'll explore the pros and cons of server-side rendering as opposed to "client-only" single-page apps (and statically generated sites). We'll go through the UX 📱, business 🧳, and product development 👩🏿💻perspectives. You'll learn when you should opt for server-side rendering, when statically generated sites are a better choice, and under which circumstances you'll be better off with a "basic" SPA.
The first argument which favours using SSR is the improved page speed.
However, like with every tool, it might be an overkill for your use-case. Think about if improving your page load by some hundreds of milliseconds is worth it. It might be crucial in for e-commerce sites (which are in an extremely competitive environment), but might be an overkill for application which are only usable after logging in
With the growing popularity of the JAM Stack, you can get similar benefits (even better) in terms of speed for pages which don't require to be highly dynamic -- blogs, marketing sites or even some e-commerce sites.
I've seen the SEO argument being used countless times, but frankly, I don't believe it is such a big deal all the time. Let's first clarify why some people claim it to be a big deal.
The way Google (and other) crawlers 🦎 (which are scraping your website to display it in the search results) has traditionally worked is following:
1) Visit a website
2) Read the HTML delivered from the server/CDN
3) Save it.
Where it might still be necessary is if you want to get a preview of your page when sharing to social media. But if this were your only concern, I think prerendering using a tool like react-snap might be a better solution. 💡
You may still get some SEO improvements by using SSR even for crawlers which wait until all the content loads up. Indirectly -- if the search ranking algorithm accounts for the page speed (which should improve when using SSR), your site should rank higher 📈 in the search results.
As opposed to the "traditional" SPAs where you don't even need a server to run your code, you need a server to render the code on the server (it's called server side rendering after all...). What this means is that you have to pay 💰💰💰 for a server to execute your "front-end" code. If you already have a server, the resource consumption might go up.
What can you do about it? Well, think about if SSR is the right solution for your use-case. You might be better off leveraging JAM Stack or a traditional SPA. Or, with the new 9.3 Next.js release, you can easily combine SSR with static pages which prevents wasting 🗑 server resources.
If you were to roll your own SSR solution, you might be surprised that it's not as straightforward as creating a "traditional" SPA. You have to take care of rendering the components to HTML, sending them to the browser, hydration, making sure that you can fetch the data both on the server and the client... 😿
Of course, if you use frameworks like Next.js or Nuxt.js, they abstract a lot of these pain points away so you don't have to worry about them 😌. However, for larger projects which want to start using SSR or which were using SSR before these frameworks existed, the migration process to such a framework might seem daunting and they need to implement SSR by themselves.
In this acricle, we explored which applications benefit from using SSR and what are the potential downsides. My personal view is that the need for SSR gradually decreases 📉. Especially, it's really easy to use statically generated sites with the newest edition of Next.js.