In Server-side rendering, the full HTML is rendered on the server and sent to the client. The content we need to display on the screen is available as soon as the HTML is parsed; hence the first content paint loads faster than the CSR.
Now let’s understand how the SSR works:
The browser requests the HTML from the server.
The server makes API requests and renders the HTML content on itself.
The compiled HTML is then sent to the browser.
Once the browser loads and parsers the HTML, the web app is made available to the end-user without waiting for the JS bundles to load.
Then the browser downloads and executes the JS bundles to make the page interactive.
Since the APIs are usually co-located within the server, and initial JavaScript doesn’t block the content, in SSR, the initial content comparatively loads super fast.
Server-side rendering
In SSR, though we get a fast first contentful paint, the page isn’t interactive until we download the JS bundles and execute them on the browser.
We can indeed overcome the drawbacks of CSR using SSR. But still, there are some major drawbacks like rendering both critical and non-critical content before sending it to the client.
I know what you’re thinking now 
How cool it is if there’s an approach where we can mix both the techniques mentioned above, right? I have good news for you! Using Progressive Rendering, you can bridge the benefits of both CSR and SSR.
Now let’s look at how we can give your users a better user experience using the progressive rending technique.