Skip to content

Latest commit

 

History

History
60 lines (44 loc) · 2.76 KB

features-ssr.md

File metadata and controls

60 lines (44 loc) · 2.76 KB
Raw
id title sidebar_label
feature-ssr
Server Side Rendering
SSR

What is Server Side Rendering - SSR ?

The most common use case for server-side rendering is to handle the initial render when a user (or search engine crawler) first requests our app. When the server receives the request, it renders the required component(s) into an HTML string, and then sends it as a response to the client. From that point on, the client takes over rendering duties.

How is Server Side Rendering beneficial?

We are using server side rendering for mainly two reasons:

  • Performance benefit for our users
  • Consistent SEO performance

Here is a very simple timeline diagram(super simple) to showcase the difference between SSR and CSR.

Client Side Rendering - CSR

Our server initially sends a blank page to the user. Then the browser needs to download **bundled js** and runs it. Once the data fetching happens we show the result to the user.

Client Side Rendering

Server Side Rendering - SSR

Here is where the server-side rendering comes in to the game. Instead of leaving all the work for the browser we may do everything on the server and send the final markup. And then React is smart enough to understand the markup that is currently on the page and reuse it.

Server Side Rendering

Consider using a SSR page when:

  • The network is slow.
  • The server has plenty of resources to render the page with data. Remember, Node is single-threaded and heavy computation may block incoming requests.
  • The delay before data shows up is short. In other words, the brief flash of a blank page is perceived as fast loading or not noticed by users.
  • The main scripts is large and loads slowly. For our SSR page, the very first request asks for a rendered page with data. Unlike the CSR case, there is no delay in sending this request. In CSR, our app sends an extra request only after the app finishes loading the main scripts.
  • SEO is important. Googlebot and other search engine bots properly index a SSR page.

Consider using CSR page when:

  • The network is fast.
  • The server has few resources to spare for server-side rendering. - The delay before data shows up is significant (you have to display a lot of data). In other words, users need to see some reassurance that the page is loading, for example a progress bar, loading spinner, or some other placeholder. - The main scripts is small and loads fast. In that case, the app loads the main scripts quickly, and the extra request that asks for dynamic data gets sent sooner.