If I had to explain server-side rendering (SSR) from Next.js to myself a year ago, here's how the conversation would go:

Old Me: My mentor told us to work with Next.js instead of React for building the front end of this project. He must have a good reason for it.

Me: It’s because of the out-of-the-box server-side rendering (SSR) offered by Next.js.

Old Me: SSR? What does that even mean?

Me: SSR, or server-side rendering, means the server renders the page before sending it to the client.

Old Me: And how were we rendering pages before SSR?

Me: Well, before you knew what SSR was, you were using it in your first project with PHP. Back then, you didn’t realize that was actually SSR. Here is a code snippet of what it looked like :

This PHP script demonstrates server-side rendering (SSR). The server generates and sends a complete HTML page to the client. Example data is embedded directly into the HTML structure. The implode and array_map functions are used to generate the list items dynamically. This approach ensures that the client receives a fully rendered HTML page, improving performance and SEO.

When you moved to React, you started rendering pages on the client, known as client-side rendering (CSR). But with the introduction of server components in React and frameworks like Next.js, we moved back to SSR.

This HTML template is set up for client-side rendering (CSR) with React. The <div id="root"></div> element is where the React app will mount and render its components. The script tag at the end of the body loads the bundled JavaScript file (bundle.js), which contains the React app. This setup ensures that the HTML is parsed before the JavaScript is loaded, improving performance and allowing the React app to take over rendering on the client side.

Old Me: Why the shift back to SSR?

Me: There are many reasons, but the main benefit is performance. With CSR, the client device is responsible for rendering the entire content, which can lead to varied experiences based on device performance. SSR ensures consistent, smooth experiences for all users by rendering content on the server before sending it to the client. Essentially, the server does most of the work for the client.

Old Me: So, with SSR, all users will interact with my website smoothly regardless of their device specs?

Me: Exactly! Not only that, but you will also get better SEO, which leads to better ranking on search engines like Google.

Old Me: And how do both CSR and SSR work exactly?

Me: In CSR, the server sends minimal HTML to the browser, which then downloads CSS and JavaScript and starts rendering. In SSR, the server renders the HTML with CSS and JavaScript, sending the complete HTML to the client for displaying the page. You can read more details in the sequence diagram below.

In CSR, the load on the client is much higher than on the server, as the client is responsible for rendering the entire page. In SSR, the server does most of the work, generating the HTML content before sending it to the client. This reduces the load on the client and ensures better performance and SEO.

Old Me: Great! Now I understand the difference between them, but does that mean that we should all move to SSR instead of CSR?

Me: No, each rendering method has its own strengths and weaknesses. For example, CSR is great if you want to build something interactive like a dashboard or components that have a lot of interactivity. SSR is best for websites with large amounts of content, such as blogs, news sites, and eCommerce platforms

Next.js offers both rendering methods, with SSR being the default rendering method.