Skip to main content

[Next.js] What is Rendering in Next.js?

Next.js is a server-side rendering (SSR) solution based on React

Next.js has two pre-rendering methods​

  • Server-side Rendering
  • Static-site Generation (Recommended)

Server-side Rendering​

For every request , Next.js dynamically generates HTML pages. However, server-side rendering (SSR) can result in slower performance compared to static generation. Therefore, it should only be used when absolutely necessary.

附圖參考

info

Each time a client requests a page, the server fetches the data for that page (e.g. calling an API) and generates the HTML for the page (e.g. rendering the view). Only after completing all of these operations, the HTML is sent back to the client.

Pros​

  1. Server-side rendering eliminates the need to worry about browser compatibility issues, as the HTML pages are generated on the server and not dependent on client-side rendering.

  2. It can help solve SEO issues, as the server-side rendered HTML pages contain complete content, including meta tags, titles, descriptions, etc., which can be properly parsed and indexed by search engine crawlers, potentially improving the website's visibility and search rankings.

Cons​

  1. Re-rendering with every request can increase the load on the server, leading to increased backend workload and potentially impacting performance. It may also result in a poorer user experience due to longer load times and increased server processing.

  2. While server-side rendered pages may appear interactive, they may still require JavaScript execution to complete interactions. In other words, it may increase the Time to Interactive (TTI), which refers to the time it takes for a web page to become fully interactive for users.

During compilation, the HTML is generated and reused for each request.

info

By generating HTML pages during the build/compile time instead of dynamically during requests, it is possible to pre-generate HTML files for each URL, resulting in excellent First Contentful Paint (FCP) performance. This eliminates the need for dynamic rendering during requests, reducing backend workload and improving FCP performance.

附圖參考

implementation:

  1. Use next export: Export all pages to static HTML files that can be used with any host.
  2. Use nginx as reverse proxy: Start Next.js server targeting the out folder.

How to choose between Server-side Rendering and Static Generation:​

To choose between Server-side Rendering (SSR) or Static Generation (SG):

For static pages such as blogs, official websites, product listings for e-commerce, etc., it is recommended to use Static Generation. This is because the content of these pages is relatively static and can be generated as static HTML files during the build process, providing better performance.

Both SSR and SG can solve SEO issues as both can generate HTML pages that can be indexed by search engines. However, if SEO is a high priority and accurate indexing and ranking are required, then using Server-side Rendering (SSR) may be a better choice, as search engines can directly read and index HTML pages generated on the server side.

P.s This image refers to content from another article, so there is no English version available.👇

附圖參考

Picture reference URL：https://zhuanlan.zhihu.com/p/113853235

bonus : csr vs. ssr vs. Static Rendering 👈​

Refer to : https://developers.google.com/web/updates/2019/02/rendering-on-the-web

Client-Side Rendering (CSR)​

Performing rendering on the front-end with the back-end serving as the API layer for data supply. When new data is needed, the front-end sends a request and only updates the relevant parts of the UI.

Rendering process:

  1. Client initiates a page request, and the server sends the page (response string) to the client.
  2. Client parses the response from top to bottom, and during the parsing process, it detects network requests and sends additional network requests to the server. Once the client receives the response, it renders the HTML page.

附圖參考

Pros:​

  1. Flexible and separate frontend-backend , making it convenient for each side to update and maintain independently.

Cons:​

  1. Some client-side rendered (CSR) websites may result in incomplete pages obtained by web crawlers, causing SEO issues.
  2. The initial page load may result in a blank screen until the frontend is fully loaded.

Server-side Rendering​

Server-side rendering (SSR) allows the server to process and modify the content of the HTML document before returning it to the client. This means that data can be inserted into the HTML string on the server before it is sent back to the client.

Rendering process:

  1. The backend receives a request and generates an HTML page for the frontend.
  2. The server generates the corresponding static webpage each time it receives a request.

Simply, the client does not need to download a large amount of JavaScript, as the HTML rendering is completed on the server side and the rendered HTML is sent to the client's browser for display.

Whenever a client initiates a request for a particular page, the server fetches the corresponding data, generates a complete HTML page, and then returns it to the client. The client does not need to download a bunch of JS and CSS files before being able to see the page (Fast Content Paint - FCP is fast), even though the JS may not have been executed yet, so the page may not have interactivity. However, allowing users to see the page first and then leveraging human perception of delayed time to execute JS code can greatly reduce user bounce rates.

附圖參考

Pros:​

  1. SEO.
  2. The page does not require downloading a large number of JS and CSS files before being able to view the content (Fast Content Paint - FCP loads quickly).

Cons:​

  1. Because rendering is done on the server side, this approach involves redrawing the entire page every time a user clicks on a link or interacts with a functionality. This can result in a poor user experience, especially in cases where the network bandwidth is slow, as the entire page needs to be reloaded repeatedly.

Static-site Rendering​

Need to generate a separate HTML file for each URL during build-time, and use these pre-generated static pages when the server receives a request, avoiding dynamic generation of HTML on the server.

Rendering process: The HTML is generated on the backend upon receiving a request and is reused for each subsequent client request.

附圖參考

References​

Tags:
Last updated on