Understanding SSR and CSR, the popular rendering patterns in the web dev world.

It's been a while since I put my feet into the world of NextJS. I absolutely love what NextJS brings to the table but one thing, the main thing in fact which took me the longest time to fully wrap my head around was Server Side Rendering (aka SSR). Not in the sense of what it is but when should we pick it over Client Side Rendering (aka CSR) really, what is the actual use case for it. Hence in this blog I am going to dispense a few nuggets from my understanding of this duo.

What is What, in simple terms.

Simply put, SSR means your code gets executed on the server and the result is sent to the client for rendering. It reduces the loading time on client side and the user can see the webpage faster. Here the client means the device's web browser on which you are loading the webpage and server is the machine which is supposed to send content for this website. Whereas in CSR, the client is responsible for executing your code and generating the rendering content. Because of this, the loading time is generally slower. That's it, that's the basic difference.

What is What, in technical terms.

In SSR, when a client requests for a website, JS is executed on the server and the HTML is loaded with content. A fully rendered page is sent to the web browser however this document is also a static representation of the webpage. The browser after loading the HTML and JS bundles, goes through the process of attaching the event listeners to the webpage. This process is called hydration. Quoting this line that I read on Reddit, "the idea of hydration is that it lets you start with a completely rendered page, then it makes that rendered page "work". This leads to the execution of the same JS on the client side too but the result in terms of the HTML content is same as what was returned from the server.

In CSR, when a client requests for a webpage a HTML is served and the JS from the loaded bundle is executed on the client side in an async or defer manner. The web browser executing the JS essentially means attaching the event listeners therefore hydration is not needed in CSR. The HTML is already hydrated with interactivity as the web page loads.

When to use What.

1. SSR is great when you want good SEO for your webpage. As a fully rendered page is served, it helps the search engine to index the page well and better crawling. Whereas in CSR, since the client takes some time to render the content after loading the JS from server, it provides an incomplete page for the search engine to crawl.

2. If your webpage has hyper-interactive content and you expect user to navigate from the main page to other pages in the same session then CSR is the way to go. The first page load time is faster in SSR but due to hydration it takes some time for the user to be able to interact with the page. Meanwhile, if a user tries to navigate to another page then the server needs to build the static HTML for the new page and send to the client. Thus, CSR is the better choice if the web page serves dynamic content, involves a bit of browsing around and does not need much SEO.

3. Another deciding factor could be the user base. If you expect a lot of users to browse the webpage on their mobiles then SSR is a great choice as it delegates the responsibility of putting together the webpage to the server and client has to do minimal computation, which leads to better and faster performance.

4. We can also make the best of both worlds by following a hybrid approach where we use SSR for the initial load and then hand it over to CSR for further rendering of the other webpages. For example, to load the landing page, you can use SSR and for the other routes likes /products, /user etc you can use CSR. Frameworks like NextJS provide you this flexibility to combine different rendering patterns.

Static Site Generator (aka SSG)

SSG is another great rendering pattern that is widely used. As the name suggests, it is mostly used to serve static content where you don't expect the data to change frequently because in SSG the webpage is rendered during build time. When a client requests for a webpage, a pre-rendered and pre-generated HTML is sent by the server. Hence, when a user visits the webpage this HTML is served immediately to the browser with no additional time.

Another flavor of rendering pattern built on top of SSG is Incremental Site Regeneration (aka ISR) which works same as SSG but with the certain added benefits like cache invalidation to refresh the webpage at certain intervals. This can be used to help static content and at the same time reload it when needed.

---

That's it for this article. Hope it helped you in gaining some understanding of the different rendering patterns available. Thank you for reading. ❤