Every time we start a new web-app, one of the most important decisions that we face is how we're going to render our web-app. This choice will make an impact in how our application will behave for our users.
In this post, I will introduce you to the following rendering approaches:
- Server Side Rendering (SSR)
- Static Rendering (SR)
- Client Side Rendering (CSR)
- SSR with (Re) hydration
- CSR with Pre-rendering
Performance metrics
Before we start explaining anything, I will introduce you to some words that we'll use in this post, that are related on how to measure the performance of any rendering approach:
Time to First Byte (TTFB): seen as the time between clicking a link and the first byte of content coming in.
First Paint (FP): the first time any pixel becomes visible to the user.
First Contentful Paint (FCP): the time when requested content (article body, etc) becomes visible.
Time To Interactive (TTI): the time at which a page becomes interactive (events wired up, etc).
Server Side Rendering (SSR)
Server Side rendering generates the full HTML for a page on the server in response to navigation.
This avoids additional round-trips for data fetching and templating on the client, since it's handled before the browser gets a response.
Pros: the FCP is pretty equal to the TTI.
Cons: the TTFB is tied to the capabilities of the server.
Static Rendering (SR)
Static rendering is an evolution over Server Side Rendering.
The main difference between SSR and SR is that Static Rendering happens at build time, instead of SSR that happens at runtime.
Pros: the FCP is pretty equal to the TTI. TTFB will be fast.
Cons: if you rely on javascript to boot up a SPA this will lead into client-side hydration.
Client Side Rendering (CSR)
Client-side rendering (CSR) means rendering pages directly in the browser using Javascript. All logic, data fetching, templating and routing are handled on the client rather than the server.
Pros: the FCP is pretty good.
Cons: because you need to wait until the JS is loaded, uncompressed, parsed and executed, the TTI results are greater than the FCP.
SSR with (Re) Hydration
Server Side Rendering with (Re) Hydration is a rendering approach that combines SSR and CSR.
When the user requests a page, the HTML is pre-rendered in the server and it starts streaming to the browser. After all HTML and JS are fully loaded it boots a SPA and the next pages are handled client-side.
Pros: It gives you flexibility because you can have different rendering approaches combined.
Cons: the flexibility it gives you comes with the cost of a slower TTFB, FCP, and a pretty long delay for TTI because all the server rendered content will re-render on the client-side.
CSR with Pre-Rendering
It's an evolution over CSR approach that consists of rendering the web-app skeleton at build time to generate static HTML.
Pros: you can get a faster TTFB because app skeleton is pre-rendered.
Cons: with this approach you inherit all the cons of CSR.
Awesome, but, which will adjust better for me?
Well, it really depends on your use case, and which metrics are important to your business.
Here's a quick summary of how each rendering approach stacks up across the key performance metrics:
| Rendering Approach | TTFB | FCP | TTI |
|---|---|---|---|
| Server Side Rendering | Slow (server-bound) | Fast | Fast (equal to FCP) |
| Static Rendering | Very fast | Fast | Fast (equal to FCP) |
| Client Side Rendering | Fast | Moderate | Slow (JS-dependent) |
| SSR with (Re) Hydration | Slow | Slow | Very slow (re-render cost) |
| CSR with Pre-Rendering | Fast | Fast (skeleton only) | Slow (JS-dependent) |
Well, that's all, in the following posts we will keep exploring more concepts related to web apps architecture.
If you like this post, subscribe to our newsletter to receive the latest news about technology, software architecture and product development!
