Why Server Side Rendering?

Stephen Grider
A free video tutorial from Stephen Grider
Engineering Architect
4.6 instructor rating • 26 courses • 634,331 students

Learn more from the full course

Server Side Rendering with React and Redux

Build React, Redux, and React Router apps using Server Side Rendering (SSR), Isomorphic, and Universal JS techniques

08:12:53 of on-demand video • Updated August 2020

  • Understand the challenges of Server Side Rendering
  • Build a server side rendering boilerplate project
  • Use React, Redux, and React Router to conquer Search Engine Optimization
  • Master techniques for data loading on the server
  • Construct server architectures that can easily scale for large apps
English [Auto] Now that we've gotten through some administrative stuff we're free to dive into our first technical discussion in this video. I'm going to give you a brief discussion of why we care about server side rendering and what problems that's meant to solve. Let's begin by doing a quick review of how a traditional re-act application works in the browser. I'm going to use that term by the way traditional re-act application many times throughout this course. Whenever you hear me say traditional re-act application I'm talking about a re-act app that is not rendered on the server. It's a normal re-act application that is only rendered in the browser. So again we're going to do a quick review on how a traditional re-act application works inside the browser. Now in this review I want to focus on a very specific period of time here like a very specific part of the lifecycle of a traditional re-act out. I want to review on how re-act works and the time between a user entering some you or L into the address bar of their browser and then the user actually seeing some content up here on their screen to get a better sense of this time period inside of here. I've taken the liberty of generating a brand new very vanilla re-act application and here it is running inside my browser. I have my request Lague open on the right hand side here. We're going to refresh the page and they're going to take a look at some of the requests that are being issued before any content appears on the screen. So I'm going to refresh the page and we see a handful of requests being created inside of my request like here. Now there are two requests in particular that I want to kind of zero in on and do a little bit of an inspection on the first is the route request to my running server that's at localhost 3000. You'll see it appear here as simply local host. If we inspect this request you'll see that we are getting a response of a bunch of the amount and if we take a look at this HMO it is a very sparse HTL document. There's a little bit of content inside the head tag. There is essentially no content inside the body except for a script tag. And then also very importantly a script tag to load up some javascript files with this script tag right here. It causes our browser to make a second follow up request to our running server and fetch this bundled dot G-S file which presumably contains all of the code of our re-act application so really we are not getting any content to appear on the screen until these two requests are completed. If we put this entire process into a flow diagram we might end up with something that looks a little bit like this. So we're essentially saying that to get some content on the screen our browser makes request for some document we wait. We eventually get back in each team document that tells our browser that it needs to go fetch some javascript file in order to show the page. The browser makes a follow up request for that javascript file and then we wait again until we receive that entire javascript file. And then finally boom we get some content visible on the screen. This of course is the most straightforward approach possible that we're looking at right here. If say for some reason our react app needs to fetch some particular data before rendering itself like say maybe a list of blog posts or a list of pictures that we can add it end up with a flow that looks a little bit more like this right here where we get the initial page we then get the javascript file. We then have to fetch some sun data from our back end server and then only after these three round trip requests can we get some content visible on the screen. Now this is clearly not the most efficient solution in the world in terms of getting content in front of a user as quickly as possible. We have three round trip requests here before we can get any useful information up on the screen for the user to look at. Now in the real world this is a pretty big problem. There are countless articles published online from companies like Amazon or Walmart or other big retailers that have proven that loading up a page as quickly as possible leads to improved conversion rates and increased user satisfaction. Therefore its really in our best interest as engineers to figure out some way to condense down this loading process to be as quickly as possible. And so enters server side rendering as a solution to this problem. So I want you to understand right now from the first video that the entire goal of server side rendering as we are going to approach it is to make sure that we are getting content visible on the user's screen as quickly as possible. We don't want to make these three roundtrip requests before any content appears for the user. We want to make one request and then boom has some content visible that the user can start to read and understand and youll start to enjoy our application. OK. So this is a quick review of why we might care about server side rendering at all and why we run into issues with traditional re-act applications. So let's now take a quick break and continue in the next video and start to discuss how server side rendering solves this problem.