What is CSR v SSR v SSG v ISR?
One of the benefits of NextJS is that it offers Server Side Rendering (SSR), alongside traditional Client Side Rendering (CSR). It also supports Static Site Generation (SSG) alongside Incremental Static Regeneration (ISR).
In this article, we will explore what these terms mean and why they matter.
Client Side Rendering — CSR
CSR is what most people will be familiar with. It is the standard React way of serving a website. The request comes in, the server hands the files over and the client renders a page in the browser.
For dynamic, interactive applications where the data served should be live — like a messaging app for example — this makes sense. But in other situations, it is totally inadequate. If you had a one and done, never needs to be updated website (perhaps an About Us page), why should you force the client to get the latest data?
Server Side Rendering — SSR
SSR is where the server does some of the work for the browser. It renders the page and serves it to the client. The important thing to note is that this isn’t fully interactive. The page is displayed but not interactable; in the background, the browser must still download the JS files to make it interactive.
However, the appearance is that of a faster load time. There is less white page waiting before a user can begin to look at the page. Additionally, this improves SEO performance as the page can be indexed faster and the First Contentful Paint time (moment when some content is rendered after the request) is decreased.
The cost of using SSR is the increased server load. Every request requires the server to do the work of rendering the page and with many users this can lead to bottlenecks.
Static Site Generation — SSG
SSG takes it a step further then SSR and builds the entire page at build time. This page is then reused for each request, easing the strain on the server that SSR brings. SSG can be built while fetching data from external sources if that data is accessible at build time.
The downside to this is an increased build time but also that old data is being served. If you built the site a week ago and updated it today, you would need to rebuild the site again in order to display the updated data. Which leads us to..
Incremental Static Regeneration-ISR
Imagine that you had used SSG to build a blog site. Then you create a new blog post. With SSG, that new blog won’t show on the home page or be accessible at all — it wasn’t available during build time, it isn’t available now. You would have to rebuild the site in order to serve the new blog post, which would get tedious very quickly.
Introducing ISR, where you can automate the rebuild time of a site every x seconds/minutes/days. (With NextJS, ISR is available with 1 extra line of code on top of SSG).
The disadvantages of ISR lies with the its hybrid nature of old data and new data. Which will a user see? It’s unknown and depends on the timing, potentially making it hard to debug or duplicate errors. If you were using ISR for a storefront and had limited inventory, you could potentially oversell something because the old site hadn’t updated to reflect your out of stock status.
Which Should I Use?
It really depends on what you need your site to do. It is a balance of load times, up to date content and server load. Any given application will want some things more then others.
Though, I’d argue that most sites would want to use a mixture of them. SSG for static pages (eg, About Us), CSR for dynamic, up-to-date content (eg, messaging), SSR for loading the latest data with the fastest times, and ISR for loading not the latest but pretty up to date information (eg, blog post).
If you want anything other then CSR, I would recommend you strongly consider using NextJS because it supports all of them.
