{"id":3299,"date":"2021-05-27T13:41:23","date_gmt":"2021-05-27T13:41:23","guid":{"rendered":"https:\/\/csdev.site\/creole_new\/?p=3299"},"modified":"2024-05-17T12:34:43","modified_gmt":"2024-05-17T12:34:43","slug":"server-side-rendering-with-react","status":"publish","type":"post","link":"https:\/\/csdev.site\/creole_new\/server-side-rendering-with-react\/","title":{"rendered":"Server Side Rendering with React"},"content":{"rendered":"\n

A Little Bit About React<\/h2>\n\n\n\n

React<\/a> is an open source frontend JavaScript library, which is created and maintained by the Facebook Developer Community. It is used to build User Interfaces or UI Components. <\/p>\n\n\n\n

However, this definition might not be completely comprehensible to novices. We have the perfect blog post which walks you through a brief explanation of React, all the way up to a very detailed technical description of it, which you can find over here<\/a>.<\/p>\n\n\n\n

The Journey of a Web Page | From Server to your Browser<\/h2>\n\n\n\n

To understand what Server Side Rendering is, first it\u2019s important to get an overview of how a webpage appears on your screen, which is elucidated by the diagram below:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
    \n
  1. Whenever you type in the URL of a website or click a link to the website, your browser sends a request for some files to the appropriate server, identified by the URL. <\/li>\n\n\n\n
  2. The server sends some files such as the HTML and JavaScript files among others, over to your browser.<\/li>\n\n\n\n
  3. Your browser downloads and \u2018renders\u2019 or processes these files and you can see and interact with the web page you requested.<\/li>\n<\/ol>\n\n\n\n

    This is a very big oversimplification of the journey of a webpage, but is a good enough preface into explaining the different sub steps and different ways (including Server Side Rendering) to accomplish this task.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Journey of a \u2018Normal\u2019 Client Side Rendering Web Page<\/h2>\n\n\n\n

    Diving deeper into the process mentioned in the previous section, we have a technique known as Client Side Rendering or CSR, which has been in use since a long time, to display a website on user\u2019s screens. This is explained in the following diagram:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
      \n
    1. On typing in the URL of a website or clicking a link to the website, your browser sends a request for some files to the appropriate server, identified by the URL. <\/li>\n\n\n\n
    2. Server sends over the HTML file which contains the references to other assets such as image files, CSS files and JavaScript files. <\/li>\n\n\n\n
    3. Browser sends a request again to the server and downloads all the files, including the CSS and JavaScript files referenced in the HTML file.\n
        \n
      1. This can be a contributing factor in increasing the loading time of a website if the users are on a poor connection and the JavaScript file is large in size. <\/li>\n<\/ol>\n<\/li>\n\n\n\n
      2. Once these files are downloaded by the browser, the browser then executes the framework or library (for example React) and parses the JavaScript files, which are responsible for making the web page interactive.\n
          \n
        1. From a speed optimization perspective, this point is dependent on the client machine and if the client is a low powered hardware, this can take significant time. <\/li>\n\n\n\n
        2. The user still sees the loading screen when these steps are undergoing<\/li>\n<\/ol>\n<\/li>\n\n\n\n
        3. The web page is finally loaded completely and the user can see and interact with the web page.<\/li>\n<\/ol>\n\n\n\n

          As is clear with the steps mentioned above, from a user\u2019s perspective, they can only see and interact with the website at the final step, after all the necessary files have been downloaded and rendered by the client machine. <\/p>\n\n\n\n

          This can take a huge amount of time as it is dependent on the performance of the client machine in executing the framework and parsing the JavaScript files.<\/p>\n\n\n\n

          The Server Side Rendering Web Page\u2019s Journey<\/h2>\n\n\n\n

          Explaining it in a single line, Server Side Rendering or SSR is the process of taking a client side JavaScript framework website and rendering it to static HTML and CSS on the server instead of the client, as was the case in CSR.<\/p>\n\n\n\n

          Below mentioned is a pictorial representation of the journey a web page takes with Server Side Rendering, with React:<\/p>\n\n\n\n

          \"\"<\/figure>\n\n\n\n
            \n
          1. On typing in the URL of a website or clicking a link to the website, your browser sends a request for some files to the appropriate server, identified by the URL. <\/li>\n\n\n\n
          2. Server, instead of just sending over vanilla HTML files like in CSR, renders the app into string using the renderToString<\/strong> function imported from react-dom\/server<\/strong>\n
              \n
            1. This is then injected to the index.html file and is sent to the browser.<\/li>\n\n\n\n
            2. This is where the crux of SSR lies, functionally speaking, as this is where the server renders the page, and not the client machine. <\/li>\n<\/ol>\n<\/li>\n\n\n\n
            3. Browser renders this HTML file resulting in the view being populated in the browser.\n
                \n
              1. However, this is not yet interactive, but the user can see the final view of the web page.  <\/li>\n<\/ol>\n<\/li>\n\n\n\n
              2. Browser sends a request again to the server and downloads all the files referenced in the HTML file, including JavaScript files. <\/li>\n\n\n\n
              3. Once all the scripts are downloaded, the React component is again rendered on the client. However, this time, it hydrates the existing view instead of overwriting it.\n
                  \n
                1. \u2018Hydrating\u2019 a view means that it attaches any event handlers to the rendered DOM (Document Object Model) elements but keeps the rendered DOM elements intact. This way, the state of the DOM elements is preserved and there is no resetting of the view that happens. <\/li>\n<\/ol>\n<\/li>\n\n\n\n
                2. The web page is finally completely loaded and the user can now interact with the page which they were able to see from step 3 itself.<\/li>\n<\/ol>\n\n\n\n

                  Thus, one of the biggest visual changes from the user\u2019s perspective is that the web page becomes \u2018visible\u2019 pretty quick, as rendering HTML is not that resource intensive, talking from the browser\u2019s perspective. <\/p>\n\n\n\n

                  This doesn\u2019t inherently make the page load faster than a non SSR app, but it does give the users the view of the web page as the JavaScript files download and parse in the background, after which the web page becomes interactive. This means that the TTI, i.e. Time To Interactive (this is the time it takes for the web page to be completely interactive from when the user requests the web page) is a bit more than the time it takes for the web page to be visible in the browser.<\/p>\n\n\n\n

                  So, in an SSR scenario, for faster first render time, your HTML and CSS needs to be meaningful to the users, and JavaScript can be the enhancement for HTML and CSS, since its loading is deferred. <\/p>\n\n\n\n

                  A common misconception about the workings of SSR with React<\/strong> is that after every change, such as a user requesting any new data, the server again completes all the steps and sends the HTML file with new UI to the browser, but this is not the case. Only a partial update to the page is done. Although the rendering is done by the server, the finalized output is inserted into the DOM by \u2018hydrating\u2019 it, as explained earlier.<\/p>\n\n\n\n

                  \"\"<\/figure>\n\n\n\n

                  Server Side Rendering | When and When Not to Use<\/h2>\n\n\n\n