 Hello everyone, the topic for this session is what is React server side rendering and do I really need it? The topics we are going to cover in this talk are different ways to render a web page, what exactly is happening during each rendering and the comparison between them. As most of you know, there are two ways to render a web page that is client side and server side. Let's start with client side rendering. So this is how the whole process of client side rendering will look like, when the server sends a response to the browser in form of HTML, which will just have the skeleton of the web page or bare minimum code. Browser downloads such as to have the page in an intractable state, browser executes React, any other templating library that you might be using. But all this is happening, you will be seeing a loading icon on your browser to maintain the calm of the user. Once the browser completes execution, the page will be both variable and intractable now. So let's see server side rendering, it's a little bit different than CSR. Server side rendering, server sends very to be rendered HTML response to the browser. The browser renders the page and now it will be variable. And then browser downloads the JS, the browser executes it. When all this is happening, you will be seeing a variable screen on your browser. Once the execution is completed, the page will become now intractable. So this is to highlight the difference between these two. In CSR, though the page will be up a little bit later, but once it's up, it will be both variable and intractable. Whereas in SSR, the page will be up sooner, but you need to wait a little bit longer to have the page in an intractable state. So as you have seen, the server side rendering renders the initial load faster. It is because in CSR, it requires more JavaScript to be downloaded and passed and also needs to make a second HTTP request to load the content. Whereas in SSR, your server's response to the browser is HTML of a page that is ready to be rendered. Hence, the rendering is faster. So you might be thinking, which is better for me then? It's not all black and white, depends on different conditions and scenarios and priorities that you might be having while building your web application. These have a quick comparison between these two to understand that. The advantages of SSR over CSR are initial page load is faster. As we have just discussed, a blank page flicker that happens with CSR isn't a concern for SSR now. It's great for search engine optimizations and the content is up before we get it. The search engine can crawl it and index it efficiently, which is not so possible with CSR. At least not simply. It's great for static sites. If you think of heavily tech-speed sites like New York Times, SSR is a preferable approach in those scenarios. The disadvantages of SSR over CSR are the required frequency of server requests and hence can create bottleneck for the sites which are highly interactive. The throughput of your server is also less compared to CSR. The method that we use in React app to enable server-side rendering, that is React DOM server.render to string is a synchronous CPU pound call which will hold the event loop and hence the server will not be able to process any other request that it completes. It's a big consideration for the application which are going to be highly interactive. And overall slow page rendering since the content, so though the content is rendered and the consumer can see it sooner, but you won't be able to interact it until the browser completes execution. All these reasons lead to non-rig site interactions. So when to use SSR, you might want to use SSR if you needed for search engine optimization, already have a working React app near the best possible performance and are willing to pay for the extra resources. And also if you're planning to have a heavily tech-speed sites, you might don't want to use SSR. If your React app isn't finished yet, get it up and running, then worry about the optimization step. Server resources are scarce, perhaps due to low budget or inability to scale. Yeah, that's all. Thank you.