Server-Side Rendering (SSR)

SSR is the abbreviation of Server-Side Render. Simply put: Server-Side Rendering means that the content presented on the web page has been generated on the server side. When the user browses the web page, the server responds to the browser with the complete HTML structure content generated on the server side, and the browser directly displays (renders) the complete HTML structure content on the page. The framework uses server-side rendering by default

Advantages of SSR:

  • Faster first screen load: SSR renders the page on the server and then sends it to the user’s browser, so the initial page loads faster. This is especially beneficial for users with slow Internet speeds or mobile devices, because the client does not need to wait for JavaScript code to load before presenting the content. The increase in loading speed brings a better user experience

  • Beneficial to SEO: Browser crawlers will not wait for our data to be completed before crawling our page data. What the server-side rendering returns to the client is the final HTML that has obtained asynchronous data and executed JavaScript scripts. The complete page information can be directly captured during web crawling, thereby improving indexing efficiency (although Google has improved the JS reading mechanism in recent years and can wait for CSR to draw the page, the efficiency is definitely not as high as SSR. In addition to Google, there are many other search engines on the market, such as Yahoo, Bing, Baidu, etc., and the JS drawing effect of each engine may not be the same. The ranking difference will be very large)

  • Enhanced security: Rendering HTML on the server reduces the risk of security vulnerabilities. This is because SSR does not expose any application logic or code to the client. Instead, the core implementation details remain on the server. This approach allows us to protect sensitive user data and website information, while better preventing malicious attacks

Disadvantages of SSR:

  • Poor page switching experience: Although server-side rendering loads quickly for the first time, there will be a sense of interruption when jumping to the page, which is an experience disadvantage. Because it needs to refresh the entire page every time to re-render

  • Increase server load: SSR needs to render the entire page on the server every time and then output it to the browser, so in the case of concurrency, it will add more pressure to the server compared to the client-side rendering mode (CSR)

How to implement server-side rendering (SSR)

my-nodestack-app
├── src
│   ├── pages
│   │   │── ssr      
│   │   │   │── index.js 
│   ├── routes
│   │   │── ssr      
│   │   │   │── index.js 
├── ndsk.config.js
└── package.json

export default (props)=>{  
    return (
      <html lang="en">
        <head>
          <title>{props.title}</title> 
        </head>
        <body>
            {props.name}
        </body>
      </html>
    );
}

export default ()=>{
    return {
        title:'ssr',
        name:'this is ssr page'
    }
}
  • Create pages/ssr/index.js file. Create routing configuration file routes/ssr/index.js and pass server-side data title name to the page
  • In SSR mode, each page can configure routing to pass data

Next step

Client rendering