
### Rendering Patterns

Knowing how to apply the right rendering patterns in our applications can massively improve our app's performance.

Usually when we talk about web performance, we think about optimizing for the **Core Web Vitals**.

These are a set of useful measurements that tell us how well our site performs, for example the TTFB measures the time it takes for the server to respond with the initial data, and the FCP measures how quickly your users see useful content on their screen for the first time, and so on.

![Core web Vitals](/images/rendering/webvitals.webp)

But that’s not all, we also want to have the best developer experience!

We want a project with short build times to be able to quickly iterate, low server costs so we don’t go bankrupt, show dynamic content in a performant way if needed, and generally no scalability issues further down the line when our website goes viral.

![Performance](/images/rendering/performance.webp)

All patterns out there have their use case, there is not one pattern that’s better than the others, as long as you know their tradeoffs.

All patterns out there have their use case, there is not one pattern that’s better than the others, as long as you know their tradeoffs.

Lets now look at some of the common rendering patterns :

#### Static Rendering

![Static](/images/rendering/static.webp)

With static rendering, the entire HTML gets generated at build time.

Since the files are static, they’re easily cacheable by a CDN, or on Vercel by the Edge Network. This makes it possible to get extremely fast responses, since the CDN can quickly return the cached file instead of having to request it from the origin server.

There are many variations to static rendering to serve a lot of different use cases.

##### Plain Static Rendering

![Plain Static Rendering](/images/rendering/static-rendering.webp)

Plain Static Rendering is a technique we can use for very non-dynamic pages.
This page is absolutely perfect for static rendering as it just shows the same data for everyone globally. We aren’t fetching any data or showing any personalized components.

When we deploy this, in this case to Vercel, the HTML gets generated for the pages, and persisted to static storage.

When a user visits the website, a request is made to the server.

The server can quickly return the pre-generated HTML to the client, and as it gets returned, the Edge location closest to the user caches the response.

The browser renders the HTML, and requests a JavaScript bundle to hydrate the page.

![Static Rendering Performance](/images/rendering/static-rendering-performance.webp)

We can have an extremely quick TTFB since the server already contains the pre-generated HTML, and the browser can quickly render something to the screen, resulting in a fast FCP and LCP. We also don’t have to worry about layout shift since we’re not dynamically loading components.

![Static Rendering Advantages](/images/rendering/static-rendering-pros.webp)

Plain Static Rendering is great for your Core Web Vitals, especially in combination with a CDN. However, in most cases, we'll probably want to show some dynamic data.

Say that instead of showing some services here, we actually want to show some recent listings. We could just hard-code that data right in the page, but in reality we’re probably using some data provider to get our listings from.

##### Static with client side fetch

![Static with client side fetch](/images/rendering/static-with-client.webp)

One approach we can take here, is to use Static Rendering with Client-Side fetch. This is usually a great pattern for pages that contain data that should be updated on every request.

![SWR](/images/rendering/swr.webp)

We can statically render the website like we did before, and fetch the data using for example SWR on the client as soon as the page has loaded. While the data is being fetched, we’ll show a skeleton component.

![custom API](/images/rendering/custom-api.webp)

We also need create a custom API route to fetch the data from. Within the API route, we retrieve the data from our CMS, and return this data.

![Edge](/images/rendering/edge.webp)

Now when the user request the page, the server again returns with the pre-generated HTML file. The user initially sees the skeleton UI since the data hasn't been fetched yet.

After parsing and rendering the initial content, the client fetches the data from the API route, and after getting a successful response, we can finally show the listings.

![Performance](/images/rendering/static-client-fetch-performance.webp)

Although using Static Rendering with Client-Side fetch gives us a good TTFB and FCP, the LCP is not as good as it used to be, since we have to wait for the API route to return data in order to show the listings.

![Static with client side fetch](/images/rendering/static-client-fetch-pros.webp)

We might also **run into layout shifts**, which can happen if our skeleton component doesn't match with the content that eventually gets rendered after receiving the data.

Since we're calling the API route on every page request, we can also run into higher server costs as we pay for every execution.

When you use Next.js, you can actually choose between a few more static approaches that really improve the performance of your app when working with dynamic data.

##### Static with get Static Props

![Get Static Props](/images/rendering/get-static-props.webp)

The first approach, is using Static with getStaticProps. This method runs server-side at build time, meaning that we can directly call our data provider within this method. If your data is available at build time, this can be a really good solution to add dynamic data to a static page.

Since the getStaticProps method runs server-side, we no longer have to deal with custom API Routes to fetch the data from, we can do this directly within the method.

We also no longer have to show a skeleton component, as there will never be a loading state; the generated HTML already contains the fetched data.

When we build the project, the data provider gets called, and the returned data gets passed to the generated HTML.

Now when we request the page, we again fetch the HTML from the server. The response gets cached, rendered to the screen, and the browser again sends a request to fetch the JS bundles in order to hydrate the elements.

![Get Static Props Performance](/images/rendering/get-static-props-performance.webp)

The network and main thread work are identical to what we saw before when we just statically rendered the content without injecting any data at build time, so from a user perspective, we again get a great performance.

![Get Static Props Pros](/images/rendering/get-static-props-pros.webp)

However, as a developer, you can quickly run into some issues.

Imagine if we statically built hundreds of pages, which can easily happen on a blog or ecommerce website, and we’re calling the getStaticProps method for all these pages. This can result in really long build times, and if you’re using an external API, you can even hit the request limit pretty fast, or get charged a lot of money if they charge per request.

Another issue is that we’re only renewing the data at build time, meaning we’d have to redeploy the website to update the content.

Next we will discuss about Incremental Static Generation and On Demand Incremental Static Generation , Edge Server Side Rendering , Edge Streaming Server Side Rendering and React Server Components.

![Bye](https://c.tenor.com/911_8wQdrUoAAAAC/mandalorian-the-mandalorian.gif)

_References_ :

- Lydia Hallie - Reactathon 2022
