Next.js is a full-stack React framework for the web that enables you to create production-grade React applications that scale.
When we use Next.js in our project, we have three options for fetching data, there are SSG (Site Static Generation), CSR (Client Server Render), SSR(Server Side Render), and ISR (Incremental Side Render). But, what do these words mean? So, in this post, I will explain with diagrams what? when? and Why?. Let's go.
I will start with the more popular and more useful: SSR (Server Side Render).
1. Server Side Rendering (SSR)
Server-Side Rendering (SSR): With SSR, when a user visits a web page, the browser sends a request to the server for that page. The server fetches the necessary data from the database, if needed, and sends it together with the page’s content to the browser. The browser then displays it to the user. This can reduce the website’s performance but is perfect for pages that consume dynamic data.
Below is a diagram of how this method works.
Why SSR ?
Server side rendering is ideal for Search Engine Optimization as the data is available on the initial load itself;
With SSR, the content is immediately available;
As the API calls occur in the server side, no client fetches is required thereby reducing the waiting time.
A best use case to use SSR could be an e-commerce application where we can pre render the data on the server side.
2. Static Site Generation (SSG)
Static Site Generation, is a method of rendering where static HTML files are generated at build time for each page of your site. This means that when a user visits your site, they are served pre-built HTML files, which can result in faster load times.
Below is a diagram of how this method works.
Why SSG ?
The content is immediately available;
This is incredibly faster as the HTML is rendered at the build time;
SSG is best suited for SEO;
SSG is ideal for webpages that have static content. eg: Blogs, Portfolio.
3. Client-Side Rendering (CSR):
With CSR, the server passes little to no HTML except a small piece of boilerplate code. The page then requests any data it needs from the server after the page load event via AJAX requests. CSR apps are often quick to load on navigation but may be slow to load initially1.
Below is a diagram of how this method works.
Why not use this approach?
Javascript bundle size can get larger. On slower connections, downloading the code on the client side will take time which in turn increase the time for initial loading of the page;
CSR is not best suited for Search Engine Optimization (SEO) indexing as content is a blank page on initial load.
You can use this approach if SEO doesn't matter to you.
4. Incremental Static Regeneration (ISR):
Next.js allows you to create or update static pages after you’ve built your site. ISR is a rendering method that blends the speed and scalability of statically generated sites with the reactivity of SSR and CSR-style apps. It allows you to update static content incrementally after the initial build, without needing to rebuild the entire site.
We can say that: SSG + update static content after the initial build = Incremental Static Regeneration.
And Now?
I hope this explication can help you decide which approach to use to fetch data using Next.js.
For me, the SSR and ISR are my favorites approach for building pages and web apps.
But, remember, each rendering method has its own advantages and disadvantages, and the one you choose will depend on your specific needs and requirements.
I use DiagramGPT for build the diagram.
You can read more about these subjects in the links of references.
References:
Top comments (3)
Hey bro
Let me first say thank you for sharing this wonderful article!
I have a question!
Do you know which one renders faster when comparing the three: SSR, SSG, and CSR?
Of course, I understood the concept of those three terms, but when I was asked in the interview which one would render the fastest, I thought, Oops!
I couldn't even consider CDN, so I just answered in the order of SSR < SSG < CSR.
I thought that SSR was slow because it established a TCP connection, retrieved data internally, created HTML, received the response, and executed the browser rendering process every time.
Since SSG already has HTML created, I thought it would of course be faster than SSR!
And in the case of the last CSR, if you receive empty HTML in the beginning, there is actually less DOM parsing, and I thought it would be faster because it only receives the necessary data and requests it to the server to refresh and render.
I want to hear your thoughts! I'll wait for your reply!
Very useful content, I learnt so much, At the begining, I had some troubles with this types of fetching data, but after more studies and practice I could increase the knowledges and understand more. Thsnks Martin, Very good Post.
Thanks bro!