CSR (Client-Side Rendering) is a method of rendering a page on the client-side, meaning it doesn't run on the server. CSR is essentially the same as SPA (Single Page Application), so if you're familiar with what an SPA is and how it works, you already understand CSR. But if you're not sure what SPA is or how it functions, I'll explain it to you below.
In this article, I'll describe what SPA is and how it works. After that, I’ll compare it to CSR in Next.js and show you how to implement CSR in your Next.js project.
An SPA (Single Page Application) consists of a single HTML page that dynamically rewrites content as needed, instead of loading a new HTML page for each interaction.
Before understanding SPA, you should first know about MPA. Let's learn about it:
Before SPAs became popular, websites were built using the multi-page application (MPA) approach. So how did MPAs work? Imagine you, as a developer, want to create a website with two pages: the home page ("/") and an about page ("/about"). To build this using the multipage method, you would need to create two separate HTML files for each route: main.html for "/" and about.html for "/about".
In each HTML file, you would have to write specific HTML, CSS, and JavaScript code for that page. However, some parts of the code, like the header and footer, are the same across all two pages. Even though the header and footer are identical, you, as a developer, would have to repeat them in each HTML file.
When the project is complete and deployed on a server, the server sends the complete HTML page along with all requested resources to the user. For example, when a user visits the home page for the first time, the server sends the ready main.html file, and the user can see the content immediately after a short wait. This method is good for SEO because when a search engine crawler visits your website, it can see all the content in the HTML file, as it's fully rendered beforehand.
However, when the user navigates to another page, like "/about", the process starts again. The server sends the about.html file along with all its resources (CSS, JS, etc.). The user has to wait once more for the page to load, and if their internet connection is slow, the wait is longer. What's even more inefficient is that the user must download the same code for the header and footer again, even though they haven't changed. This repetition of code (like the header and footer) is wasteful and inefficient in today’s web development practices.
Now that you understand how MPA (Multi-Page Application) works, let's dive into how a SPA functions.
Due to the delay in loading pages with each request, the repetition of code, and the need to rebuild the entire DOM every time, SPAs were introduced to solve these issues.
Imagine you're a developer creating a website with two routes: "/" and "/about". In an SPA framework, you only have one HTML file called index.html. Instead of creating separate HTML files for each route, you create components for each page and load them dynamically. For example, you would create three components—one for each route and import them into your index.html.
In SPAs, you can also separate reusable sections of your site (like the header and footer) into their own components. Instead of writing the same header and footer code for each page, you just import these components where needed, similar to how functions work. This reduces repetition and makes development easier.
When your SPA project is deployed to a server, the server no longer renders the content of the page. Instead, it serves the index.html file along with the JavaScript bundles that contain your components. Rendering happens client-side, in the browser.
When a user visits your site for the first time, the server sends the index.html file along with the necessary JavaScript files. This can cause a longer wait time compared to an MPA, because the entire DOM is constructed after the JavaScript is fully downloaded, parsed, and executed.
However, once the initial page is loaded, navigating between pages is much faster in an SPA. For example, if the user navigates from / to /about, the browser doesn't need to reload the entire page. Since common elements like the header and footer are already loaded, the browser only fetches the JavaScript for the specific content that changes (e.g., the /about page content). The DOM is updated dynamically without a full page refresh, making the user feel like they are interacting with an app rather than a traditional website. This provides a smoother, more "app-like" experience.
However, there’s a downside to SPAs, especially when it comes to SEO. Since the initial index.html file contains minimal content (with most of the data loaded through JavaScript), search engine crawlers may see an empty page and have difficulty indexing the content. This is why SEO in SPAs can be challenging compared to traditional MPAs.
Yes, CSR (Client-Side Rendering) is a rendering method, meaning the process of converting components into a format that can be displayed in the browser, allowing the user to see the page. The key thing to understand is that CSR happens entirely in the browser. For both React and Next.js, CSR works the same way, there’s no difference between the two when it comes to client-side rendering.
For example, in CSR, when you visit a website for the first time, the server sends an index.html file with minimal content. But here’s the catch—this file doesn’t have the full content yet. The actual content is rendered in the browser after all the necessary component files (JavaScript, CSS, etc.) have been downloaded. Then, React builds the DOM tree (Document Object Model), followed by creating a virtual DOM, which is like a lightweight copy of the real DOM.
Once the DOM and virtual DOM are set up, the user can see the page. This process of rendering happens in the browser, converting all the components into a displayable page.
Now, when the user navigates from one page to another (say from / to /about), React builds a new virtual DOM for the new page. It compares the old virtual DOM with the new one, finds the differences, and applies those changes to the real DOM. This process of comparing and updating the DOM happens efficiently, and it all takes place in the browser.
So, to sum it up, CSR works the same way in both React and Next.js. The rendering happens in the browser, and React handles DOM updates efficiently using the virtual DOM, making the user experience smooth and fast.
If you use client-side methods like useEffect in your component, instead of server-side methods such as getStaticProps or getServerSideProps, your page will be rendered on the client, following the CSR (Client-Side Rendering) method. This means the browser handles rendering after the initial HTML is loaded.
Additionally, using libraries like SWR or TanStack Query also enables CSR, as these libraries handle data fetching in the client after the page has loaded. This way, your component is rendered in the browser, and any updates to data happen seamlessly on the client side without server-side involvement.
CSR is a method of rendering our project in the client, and it's essentially the same as the SPA (Single Page Application) definition. React uses CSR for rendering, and this is one of the key differences between MPA (Multi-Page Applications) and SPA. Next.js also uses CSR because it's built on React, but to improve SEO and enhance user experience, Next.js has added SSG, ISR, and SSR. You can read about SSR, ISR, and SSG. If you want to stay updated with my latest articles, follow my website at https://saeed-niyabati.ir .Thank you for reading! Bye for now!
The above is the detailed content of Understanding CSR in Next.js: Client-Side Rendering Explained. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
