Rendering Strategies: which one is best for you? – Experts Zone #28

Watch the newest video by our frontend developer Ola about rendering strategies. Ola will tell present rendering strategies with pros and cons.

Transcription

Olga

Hi everybody. This is Frontend News channel. Today we'll speak with Ola about rendering strategies. Hi Ola, nice to see you here today.

Aleksandra

Nice to see you too.

Olga

Could you please tell a few words about yourself and then we will move to rendering strategies.

Aleksandra

Hello, everyone. I'm Aleksandra, and I am frontend developer in Liki and Frontend House.

Olga

And today we will speak about rendering strategies, right?

Aleksandra

Yes, that's right.

Rendering strategies

Olga

Can you please, in short, tell us what is it all about?

Aleksandra

Yes, so maybe in short we can say that it's a way in which our page is delivered and that is rendered in the browser. So on a very high level is how our code turns into the actual website that users can see and interact with.

Olga

It sounds like a very important and crucial topic.

Aleksandra

Yes, it is. You are right. And nowadays we have a few different possibilities. Of course, it's good to know all of them to make the right choice. Because rendering strategy will have a huge impact on your website performance and on search engine optimization. I guess everyone already knows how important it is. If not, you can confirm Olga as the marketing specialist, right? That it's a very important thing for us. And for me personally, it's also a very interesting topic because new ideas around it tend to change the way we create web apps and also set completely new standards. If you remember transitioning from multipage applications to single-page applications, it was a huge milestone in the history of web development. And we can notice that most of the libraries and frameworks that get a lot of attention, they usually bring something new to this topic.

Olga

You mentioned that there is a lot of different rendering strategies, but which ones do you want to cover today?

Aleksandra

So today we will speak about client side rendering, server side rendering, and static site generation. I will also mention Incremental static regeneration. And each of these approaches has pros and cons - bring some benefits, but also have limitations. And at the end of the day, it depends on what is your top priority when building a website or a web application. For example, maybe content should arrive as quickly as possible. Or maybe you have a lot of data that you need to fetch. Or it can also happen that you need a page that is very interactive and dynamic.

Olga

I've heard that you have a little presentation to show us.

Aleksandra

Yes, it would be easier to describe all the strategies.

Client side rendering (CSR)

Aleksandra

Okay, so let's start with client side rendering (CSR). All those of you who already worked with React or used Create React app, you're already familiar with this approach. So let's see how does it work? When the server gets the request for a page, it just returns files. Then a page is rendered on the client in the browser. And when the browser is busy with this rendering task, the user sees just a blank screen because all that is available initially is just very basic HTML page with empty div elements. So this initial load can take very long, especially when the network connection is slow or when the machine is not very powerful. And the browser is under very big stress because it has to download the whole page or application, parse it, execute it, and finally render the results. Also, we tend to fetch some data in our applications. For example, by using React.useRef() hook. It also takes some time, so the user has to wait quite a long. And in the worst case scenario, just imagine what happens if JavaScript is disabled. Then basically we will just stay with this empty blank page, right? But still, this approach has some advantages.

Aleksandra

So after the page is finally rendered in the browser, the experience is rather smooth. It's almost nativelike. Because we will be updating only smart parts of the application and there will be no need to download again a lot of content from the server. And there is no need to refresh the page. And when we are changing navigating through the pages, there is no need to reload the browser window. Another thing is that there is not much workload on the server, right? Because it just sends files. This solution is pretty easy to scale and to maintain from the server point of view.

Aleksandra

But we already saw some drawbacks, right? So very long initial page load time. And also when we build this kind of app, usually the bundles that we sent to the browser are really huge, right? Because we need to ship all the JavaScript. That is why it's so important towards the size of the whole bundle that you ship because it will increase the load time. And we also have to keep in mind that it's not just users who wait for our page to load, there are also search engine bots and if they visit our page and there is nothing there. Nowadays, they usually wait for some content, but anyway, they will punish us with lower performance scores.

Aleksandra

So as a result, SEO is not really supported in this case. But still, client side rendering can be useful. For example, when the user is already logged in, a user has already discovered our app, and we don't have to worry that much about SEO, right? But for example, we want to apply a lot of personalization, and a lot of dynamic content where data is updated very often. Then client side rendering is a very good choice. Also, it might happen that it's better to fetch the data only when it's needed and not in advance. This would be also the use case for a client side rendering.

Server side rendering (SSR)

Aleksandra

Okay, so let's take a look at server side rendering (SSR). Cause of all the problems with client side rendering that we just discussed, another solution was needed, right? And server side rendering is a kind of answer to this problem. So here, a page is rendered on the server for each request. Also, all the data that can be fetched on the server is retrieved there. For example, it can be data from our content management system. We have our HTML already rendered on the server, and some data and is sent to the browser.

Aleksandra

Still, on the client side, there is a need for hydration. It's a step that will make sure that our page becomes interactive. But even if JavaScript is disabled in the browser page will be available. So we will have some content rendered anyway.

Aleksandra

Some advantages of this solution. So we reduce the initial time required to render the page. Overall it means better performance compared to client side rendering apps. So the HTML file that is received by the browser already has some content and is ready to be rendered immediately. So we have good SEO support, but not least security. Everything that's connected to cookies, calling some private APIs, or maybe validation, everything happens on the server. The need to expose some data on the client is kind of limited, which makes our web app more secure.

Aleksandra

On the other hand, we have some disadvantages. So server side render applications will always mean longer server load, especially when there are a lot of requests coming in. It means, as a result, higher maintenance costs and also scanning maybe not be so easy in the future. We also have to keep in mind that if we call some data source to render the page, it will be done for every single request, right? So it can also be a lot of work on the server at some latency. Then, there might be a sad surprise for the developers because the time to first byte metric might turn out not to be so perfect, not so good because when the server has to fetch a lot of data, it can take very long. Also, we might have some issues with cumulative layout shift in case we use some JavaScript, for example, to deal with the layout or with the responsiveness. Because this work will have to be done by the client. So some metrics, and some of them are very crucial and vital, maybe not so good, but there are some ways to improve it and some use cases.

Aleksandra

So server side rendering will be perfect when we have to rely on search engine optimization and when we want fast loading, but we still want to have the possibility to add dynamic content to our page. So it's a perfect solution when page data must be fetched during the request time. And also, for example, we have a lot of pages. Let's imagine that we have an e-commerce store and there are a lot of products. We don't need to render all these pages initially, they will be rendered only on request, right? So we need to save some work.

Static site generation (SSG)

Aleksandra

Okay, let's take a look at static site generation (SSG). So here every page is rendered during build time and we will use the static files generated during build for every request. And also if we need to fetch any data, it has to happen during the build time. This data also can come from our content management system, for example.

Aleksandra

The main advantage of this approach is that this is the fastest one from what we covered so far. Because we don't fetch any data on the client. We have great support for SEO because the web server just sends the static files that are ready and the browser will just have to display them. And so this solution is very easy to scale, easy to maintain and can be cached. And here we can use a content delivery network. About security, we also don't have to send any data between client and server, because all that we need is already on this pre-rendered page.

Aleksandra

The biggest kind of compromise we have to do here, so the biggest disadvantage, is that we are not able to have any dynamic content. Because once the page is built, it will remain the same until the next build and deployment. If we have a situation where we have a lot of pages, then rebuilding can be very slow and can take a very long time. But usually, we want to use static site generation when we need pages that are very fast, and that have great SEO support. But we have to remember that data that we need must be available during this time. So here great candidates for this approach would be a blog or maybe some parts of your application that are not very frequently updated. Maybe you already have documentation that is ready, that's not work in progress - it can be a good use case for this approach, for example.

Incremental static regeneration (ISR)

Aleksandra

Okay, let's take a look at incremental static regeneration (ISR). We saw that the biggest issue with static site generation was the lack of access to the fresh latest data. And incremental static regeneration can help us here. So let's say we start off with static generation and we have our pages cached. So we deliver content the fastest way. But to get the new data, we can tell the server to trigger an update and render a static page with new content.

Aleksandra

So how it works? It's a bit complicated when you hear about it for the first time, so bear with me. Let's say we will set revalidate time to 1 minute. So first we will get the static data that was generated during the build time. And during this first minute, every user that will access our page will get this version, right? This first version was built. After this 1 minute, if a new request comes, we will again get the new data, render the page again, and save the results in the cache overriding the old version. And this is very important to remember that this request will just trigger this update process. But the user that will send this request will still get the old version, right? So this kind of this revalidation happens behind the scenes and doesn't interrupt the whole flow. So it's important to remember that this revalidation is kind of lazy, right? So if no request occurs after this first minute, no rebuild will happen. We will be still serving this first, let's say old version. So here in this approach, we kind of mix static set generation and access to the new data.

Rendering strategies - use cases

Aleksandra

So we covered all of the strategies that are available, at least for now. And maybe to recap, let's take a look at some use cases, and let's try to decide which rendering strategy we could use. It would be like a little practical exercise.

Let's start with static site generation because by default we want to use this approach every time, right? Because it gives us huge benefits. Of course, if limitations around dynamic content, dynamic data is acceptable, you are good to go with static site generation. So for example, we already mentioned a blog or maybe our homepage. We need performance, right? We need SEO. The content probably will not change that often, so SSG is here a very good candidate. In case our data is changing from time to time, we can always use the support of incremental static regeneration.

What if we have a single products page? Here we usually also need a good SEO. We need good performance, but there are also some dynamic parts. So for example, we want to be able to update the stock that is available or for example, delivery time or cost depending on the user location. So here we can combine static site generation with client side rendering, right? For these dynamic pieces that we need.

Let's say we want to build a clone of some social media app. And let's say we are rendering the page with the latest post. Here we don't really need search engine optimization, right? Because the user is usually already logged in. We will have a lot of very dynamic interactive things. And content has to be also personalized for the user. Still we might have a lot of static assets, right? So here we could also use static site generation, especially for the components that kind of repeat, like header, footer, etc. And for the rest we can use client side rendering.

Some things that would work well with client side rendering are also cart, maybe in an e-commerce shop or checkout, right? Because it also has to be very dynamic, and very interactive.

What would be a good use case for service site rendering? For example, we have a blog that has a lot of posts on it. Here a single post page is a good candidate for SSR, right? Because we have a lot of pages, we don't want to render all of them, but only the ones that are visited. And we also want good search engine optimization. So server side rendering might be a solution here. Or for example account settings - here we need good security, we need authentication. It seems that here also server side rendering could be a perfect choice.

And when it comes to incremental static regeneration, we just want to use its help every time we want to get the first data.

Okay, so you probably noticed that for some use cases I mentioned at least two strategies. And yes, the good news is that we can use all the strategies that we mentioned today in one application. The framework that enables us to do it, for now, it's Next.js and it supports all those three strategies, I think, since version 9. So we don't have to stick to one approach, but we can choose different approaches per page. And by default, Next.js will statically render our pages. This is like the default behavior. So we will use getStaticProps usually in this case. And in case we use getServerSideProps or getInitialProps, we will kind of switch to server side rendering. And of course, we can introduce client side rendering, for example, by using React hooks in our components. In case we want to use the static approach but use incremental static revalidation, we can just add revalidate property.

So for now, we can choose different strategies per page. But if we think about the latest changes that are happening in React, I mean, several site components, probably in the future we will be able to choose different rendering strategies for every component. So we will decide that, for example, this piece of our application will be statically rendered, and other parts will be rendered on the server. And yes, we will have to do this choice for maybe each and every component. So for sure, it's gonna be exciting and a lot of fun for us developers.

Olga

Thank you Aleksandra, for your presentation. I love videos with you. Really. They are always short, on topic, and cool.

Aleksandra

Thank you everyone for attention. Thank you, Olga, for having me. See you next time.

Olga

See you next time. You can watch other videos on our Frontend House channel and you can also check open positions on frontendhouse.com. See you next time. See you all next time. Bye. Thank you.