What do SSR, CSR, ISR and SSG mean? A complete guide for web developers

If seeing all those acronyms makes you want to explode and say WTF, you're in the right place. I'm going to explain to you what SSR, CSR, ISR, SSG and all those acronyms mean, what the differences are between them, when you would want to use them, as well as the pros and cons between all of them. This is going to be the complete guide you need to know about how all these different acronyms work. Welcome back to Web Dev Simplified, my name is Kyle and my job is to simplify the web for you, so you can start building your dream project as soon as possible. First I want to define what SSR, CSR, SSG and ISR mean. SSR stands for server-side rendering, CSR stands for client-side rendering, SSG stands for static site generation, and ISR stands for incremental static regeneration. Now, if this all sounds like a lot of goobly Glo and nonsense to you, don't worry, because I'm going to explain exactly what each of these categories means and when you might want to use them. Now, to do that, we first need to understand all the steps that a website goes through from the development process to when it is rendered in a person's browser. Because the actual steps in this process are what all these different acronyms really influence. So the first step you have is the construction process. After you finish writing your code, you need to build your code, compile it, transpile it, whatever you need to do to convert your code from your original source code to code that is going to be used and rendered on the site. The next step is that someone is going to request a URL on your server and your server is going to do some kind of work to process the page, process the request and then send the page to the user. Then, when the page reaches the user on the client, the client needs to go through and render all that information to the screen and do any additional processing work it needs to do. Now, depending on which of these different acronyms you decide to use, the time each of these steps is going to take is going to be different and depending on your use cases, you're going to want to choose one over the other. Now, you might think that every website falls under one of these four categories, but there's actually almost like a fifth category which is how the web worked before front-end frameworks and all this client-side routing. And that's just a normal application rendered by the server. So if we look at the graph of what this would look like, the build time for a server-rendered application is going to be relatively small. Basically, all you're going to need to do if you're writing in JavaScript is package and transpile your JavaScript code into the version of Node your server is running. Then, when someone makes a request to your server, this is the place where the vast majority of the time is going to be consumed. And that's because what happens is it takes the request and then what your server needs to do is build the entire HTML page and all the data that goes into that page, wait for all that information to compile, and then send it to the client. And then this last step from the client is practically zero. And that's because there is almost no client-side code. There may not actually be any. Really all the client needs to do is render the HTML that was given to it by the server and then run some JavaScript if you have something on your page. So as you can see from this graph, the server-side part is where almost all the work is happening. So you need to make sure you weigh the pros and cons. You can have a more powerful server that can handle these requests and go through them fairly quickly and your client doesn't need to have a very powerful device because it doesn't really do any work. Now when it comes to examples of sites like this, pretty much any site where when you