I've been mainly dealing with CSR React UI applications, and the way i understand it is that the reason SSR is more ideal for initial load (not interactivity) is because the JS gets executed on the server. But then, hydration means React needs to re-create the VDOM that had been created on the server, attach event handlers and so on..
So does that mean that the "cost" (executing JS) that comes with CSR also applies to SSR, but in the case of SSR we at least get a faster initial load?
As you can see in the diagrams above, both flows go through these steps:
In the SSR flow, these steps are simply moved to run on the server instead of the client (browser).
Additionally, SSR requires an extra step called hydration. During hydration, the browser executes JS again, allowing React to take control of the generated HTML by mapping the DOM to the Fiber tree (VDOM) and attaching event listeners. This means JS runs twice in SSR flow: once on the server and once on the client.
The browser requires HTML and CSS to render a page.
In the CSR flow, the user has to wait for all steps to complete before seeing the UI.
In the SSR flow, even though there are more steps, it still delivers a faster initial load in most cases due to two key reasons:
Caching: You can cache part or all of the rendering phase on the server. This is usually a shared cache, meaning multiple clients can reuse the same data. As a result, the client can instantly receive the HTML from the server. The browser can render the page as soon as it fetches enough CSS. Although the page remains non-interactive before hydration, the UI is visible, allowing users to see progress, which significantly improves the user experience.
Server power: Servers typically have more computing power than client devices. While servers handle multiple requests at once, they still generally render pages faster than individual clients.