You don't want to Server-side Render your Next.js App

Hello, everyone, and welcome to my talk, You Don't Want to Serve a Set Renderer, Your Next JS App. Before we start, let me please introduce myself really briefly. I am Michele. I work as a senior software architect at NearForm. I'm a Google developer expert and a Microsoft MVP. I am also the author of Real-World Next JS, which is a book that, as you may guess, talks about Next.js. So if after the talk you'd like to hang out and talk about Next.js, please feel free to reach out. I'd be glad to talk with you.

A couple of words about NearForm. We are a professional services company, and we're specialized in Node.js, React, Next.js, TypeScript, and whatever. We are maintaining a lot of open-source packages that get downloaded 1.2 billion times per month cumulatively. So if you're looking for a remote-first job and you're really committed to open source, please feel free to reach out. I'd be glad to introduce you to the company.

But that's not why we are here, so let's talk about Next.js. First of all, what is Next.js? Why do we want to use it? And why is it so beautiful? When React started to be a thing, we only had client-side rendering basically. So that was the norm. We basically generate a big bundle and serve it over the net. This bundle will contain the whole application and as soon as it gets transferred to the browser, the browser will read the file, the JavaScript file, execute it, and we'll have the DOM ready to be browsed.

So basically, the problem with this approach, but we will see many problems later on, is that this is what we see when we first download the bundle. So while it's downloading, while it's executing, we see a spinner. After several seconds, we will see the complete page ready to get browsed. So this approach has some cons and has some pros. So let's see why it might be a good or a bad choice. So first of all, it makes you feel your app, like it's a native application, and that's because page transitions are really easy to handle, and you don't have to refresh the page every single time. Every time you click on a button, for example, and you go to another page, you don't need a page refresh. You already have all the components you need that gets lazy loaded directly into the browser. So for example, you're in the home page, you click to read an article, the whole DOM refreshes, but the page doesn't. So the DOM React will swap the content with the new one, and will execute lazy components that haven't been executed yet during the first load. One other great thing about client-side rendering is that you don't need a server. And if you need because you already have one and you want to serve your client-side application from a server, it doesn't require much power.

And there's no server workload, which is pretty good because it's really easy to scale. But if you don't have a server that's still good, you can just put your files, static assets, on a CDN on S3 on AWS, for example, or using Cloudflare pages, or whatever. And you just can host an entire application directly from something that doesn't need a server at all.

While this is good for many things, it also has some problems, for example, with search engine optimization. We all know that React, it's not particularly good for search engine optimization, which is true. But it really depends on the market you care about. For example, if you care for the European and American market, we know that Google is the number one search engine and Google today is capable of indexing React content. But there might be other search engines that are more popular in other continents, such as Asia, for example, or Africa, that does not read React generated pages. So if you truly care about those continents and markets, you should definitely look into something different for building your application.

Another con is that React is really bad for the initial page load time, as we saw. So the first time you download a bundle, you just have to wait several seconds in order to be able to browse it. So this is why we begin to see server-side rendering as a different way for approaching React rendering specifically. With server-side rendering, this is what you get as soon as you request a page. It might take a couple of seconds, because the server still needs to render the application on the server side, but eventually it will send you the complete page ready for browsing.

So this approach also has some pros and cons. Let's see them. One pro, the application might be a bit more secure. That's because you might have server-side cookies, for example, for authentication, and you don't have to share those cookies with the client, which makes your application more secure. You can hide some requests from server to server without exposing them on the client. That limits the possibility for a man-in-the-middle attack, for example. Also, you end up having more compatible websites. If you don't have JavaScript enabled, you will still see the first render for your application. Search engine optimization is enhanced thanks to server-side rendering, because you basically end up having a product which is the same that you might have with Ruby on Rails, JavaScript Boot, Laravel, or whatever. The content can be highly dynamic, and you can have that kind of dynamism directly on the server. So, depending on the user that is currently logged in, for example, you might decide to render different things directly on the server. Of course, it also has some problems. For example, a server is required. Every single request gets rendered on the server and transmitted to the browsers once rendered. So, there will be an higher server workload, higher maintenance costs, because you will have to maintain a server. And this is costly.

So, you have to scale the server horizontally, for example, if you want to add more servers to serve your application, because you need to scale, or you need to add more power to the server you already have if you want to scale vertically. That depends, of course, on how you want to scale your applications.

So, there is a third option that we are going to explore, which is called static site generation. So, just like server side rendering, this is what you get when you request a static site generated page. So, basically as soon as you make a request, you don't need to server side render it, because you already rendered it during build time. So, you will serve your application as static files directly to the browser.

This approach has pros and cons of course, one pro is that it's super easy to scale, and that's because again, you don't need a server. You already have static assets, you put them in a CDN, on S3, on wherever you want, on a bucket, and you just serve them as static assets, because you don't need to render the page every single time you get a request. So, that leads to outstanding performances, because the page is ready, you don't need to render it either on the client or server side. So, the page is done, you just have to transfer it. It is really secure because you don't have a server, so there's no way to attack the server directly, so that's another thing to keep in consideration.

Of course, again, it has some cons. Let's see them. So, no dynamic content is allowed on the server side, because you don't have a server, so you can't render specific things for a specific user on the server, because you don't have a server at all. It relies on client-side rendering for all the dynamics part of your application. So, for example, if you are on Instagram and you're scrolling the feed, you could generate the feed page with the client-side rendering, sorry with static side generation, but eventually you will need to wait for the client to understand who is the user that is logged in and then render the content which is specific to them. And one other thing, which is really annoying, I would say, is that if you need to change something, for example, a typo on the home page, you will need to reload and rebuild and redeploy the whole application. That can be fixed with incremental static regeneration, but we will see that in detail later on.

So one nice thing about React is that you don't have to compromise, you don't have to choose one rendering strategy for the whole website. But you can do that granularly at the page, when you basically render the single page. This is called hybrid rendering. So basically you might say, okay, the home page for this website will be a statically generated page. If you are in a blog, the post page can be dynamically generated with the server-side rendering, for example. That's cool. And some parts of the application can be rendered on the client-side only. So you can choose how long basically the user has to wait before assessing the content. Let's see in detail what I mean by waiting. So for example, this is client-side rendering, right? We make a request and as soon as we make the request, the server or the CDN will send us an empty page. As soon as the JavaScript bundle containing the React application gets executed, we will start seeing the application getting mounted on the browser. So as you can see, the server will be really fast in sending a response, but we will have to wait.

So as time passes by, we have to wait for the page to be loaded. With server-side rendering, it is a bit different. We ask for the server for a specific page. We wait milliseconds, hopefully, or seconds depending on how good we are at writing React or how slow the APIs behind our applications are. And then when the page is correctly rendered on the server, we transmit it to the client.

Static site generation looks like the perfect match. As soon as we make a request, we get a complete response. So this is why I like to talk about incremental static regeneration because it basically solves a big problem we are having with static site generation. So we don't want to rebuild the whole website every single time we make a change, because this is good, what we are seeing right now on the slide, it's good. But for example, if I change my mind and I start loving Irish setters, for example, I will have to rebuild the whole website. But thankfully, with incremental static regeneration, that's not the case.

So let's see how it works. So basically, this is our page right now. This is a home page for my website, because I love English setters. And so let's say we have a value in our getStaticProps that is called revalidate, set to five minutes. So every five minutes, we have to revalidate that page, meaning we have to rebuild it. So I publish the page. After one minute, one user comes to the website and they will see that page. After three minutes, another user comes to the website and will see the exact same page. The same of course for the third user that looks at our website after five minutes. Remember, this is lazy. So if no users will see the page again from now on, Next.js won't reload the application itself. It won't rerender I would say the home page in that case. But we say that every five minutes when a new request comes, we have to regenerate the page. So that's what's happening basically. We regenerate the page and the next user after five minutes will see a totally new page with a new background color with an Irish setter instead of an English one and that's what will happen after four minutes for another user and after five minutes for another user. And again, from now on after five minutes if another user comes to the website we will need to revalidate the page. So basically if nothing changes we will see server-side render the page. But we will put some caching headers so that it will be able for our cache to serve a cached version of the page. If nothing changes we will still see the same page.

Okay, but that said why would I want to avoid server-side rendering? So it's my opinion that React server-side rendering it's not really efficient yet. That's not Next.js fault. This is no one fault but JSX. JSX is not really efficient as a markup language or I don't know how to call it, but it's not really efficient when it comes to server-side rendering.

So every single request requires a lot of effort on the server-side which slows down the server, so you need to scale it, so you need to add more computing power, more servers to keep up with increasing demand for your application pages. So it might be easy for an architect at a certain point to say, yeah go serverless. You know you don't have that problem if you go serverless. You basically deploy your Next.js application on AWS, Lambda, Google Cloud Functions, Azure Functions, whatever, and you don't need to scale. That's correct but at what cost? It's not cheap.

So let's see a little example on Google Cloud Platform. Let's say this is the price of Google Cloud Functions. So let's say for the first two millions of invocation per month we don't pay anything. Beyond two millions we pay 40 cents every million of invocations. Sounds cheap right? Well we will see later on how much it will cost. As you can see you also pay computer time every 100 milliseconds. I have no idea how to pronounce those small numbers so forgive me. Networking. You also pay for networking. So first gigabyte of transfer traffic are free then you pay 12 cents per gigabyte. Sounds cheap right? So let's say we have an application that handles 100 concurrent server-side renders requests per second which leads to 259 millions and 200,000 requests per month. It's incredibly hard for me as an Italian to say English numbers! I'm super sorry but it's a huge number of requests right? The average execution time, let's say is 300 milliseconds. We can use the cheapest RAM option which is 128 megabytes and we will require around 100 kilobytes of bandwidth per execution and okay and we will need more but let's say for keeping it simple that this is how much we will be transferring. How much would it cost? Yes, using Google Cloud Functions for example it will cost three thousand dollars per month but it will scale of course it will scale but if you get more requests the price will get higher and higher so it's not really sustainable for large-scale applications. If you go back for example on Compute Engine with the two virtual CPUs eight gigabyte of rams you will pay like fifty two dollars per month which is way cheaper but still you'll have the problem of server-side rendering because you will need to scale it so eventually you want to go back to serverless but it will cost a lot so you want to go back again to Compute Engine for example but it won't scale or it will become really costly. So how do we get out of that bad situation? So my suggestion would be play smart depending on the scenario. So let's start with an example scenario. Let's say we want to build a social network app just like Instagram or whatever so I want to play a little quiz game with you. I will give you a couple of seconds for thinking of an answer so this is the first question. We already discussed this let's see if you were paying attention. So let's say we have to build a feed page feature for our application for example on Instagram when scrolling the feed page the the home page of Instagram so the content it's really dynamic and it's custom for every single user it doesn't need SEO and that's because the user is logged in so the feed it's really specific for users it serves a lot of static assets and it's basically one big common page for every single user.

What would you choose for that? Would you choose server-side rendering? Would you choose server-side rendering with a caching layer? Would you choose static side generation and incremental static regeneration? Or would you choose static side generation and client-side rendering for displaying dynamic content? Let's think about it.

So in my opinion, the correct answer is static side generation with client-side rendering. That's because you don't need server-side rendering. We know that it will be different for every single user, but the page is the same. The header will be the same. The footer will be the same. It only changes the content. So the content can be lazy loaded on the client. Also, if you think of a scale of Instagram, this is too big for many of us, but you don't really want to server-side rendering that many requests. It's becoming really costly. So let's go with a single post page. So we see a nice photo. We click on the title, and we see the full post with the description and the comments and whatever. So there are a large amount of pages. It will need a good search engine optimization because this is how we get into Google with the individual posts, not with a homepage. It serves big static assets, photos, videos, and there is one single page for every single post. What would you use? So answers are the same as the previous answer but in my opinion this is a good case for server-side rendering to cache. Let me explain to you why. We will be server-side rendering this for the first time and we'll be serving a caching response every single time a new user asks for the same post. After, let's say, one hour, thirty minutes, one day, we will purge the cache and re-render it, mimic how incremental static regeneration works. If... okay, we will see later on, with another example, what might be a good alternative to that. But for the moment, let's keep our thoughts on SSR and cache.

Okay, last one. Account setting page needs high security. It doesn't need search engine optimization and it's protected under authentication. We know for sure that this is not the most visited page of every account, right? So that might be a good case, in my opinion, for server-side rendering without any cache. We don't want cache, otherwise the risk is that I do login and when another user logs in they will see my account. This is not what we want, you know. But also we have server-side cookies which are more secure than client-side cookies.

So that's a good case for server-side rendering and we can afford it because there are not many requests to that page specifically. So let's go with another example. Let's say we want to build an e-commerce. So the home page, it's really important for every single e-commerce, right? We need high performances, awesome search engine optimization, and the content changes from time to time. Not really frequently, but let's say a couple of times per week, okay? So what would you choose? I'll give you a couple of seconds. My opinion is to go for static site generation and incremental static regeneration without a long revalidate time. So that you basically statically render the page, the performances will be awesome, and you will revalidate the page after, I don't know, one day, two days, one week. It really depends. You can choose. So let's go with a single product page. Let's say that in our e-commerce, we have 250 products, we need awesome SEO for every single product, need awesome SEO, great performances, some dynamic data, for example, stock quantity, I don't know, for example, delivery time, depending on where you come from or where to ship the merch, etc. What would you choose? I would choose static site generation and client-side rendering. And that's because the product page doesn't really change that much. Otherwise, we could have chosen incremental static regeneration, but it doesn't really change that much. And the stock quantity can be controlled on the client side via API calls, for example. And the same can be done with external APIs for delivery.

One thing to mention, and I wanted to mention this previously when talking about the social network, but it's worth mentioning now, is that if we have a very large e-commerce or a blogging platform, for example, where we have one billion pages to be rendered, of course we can't render one billion pages at build time. It will take forever. So we could choose to go with incremental static regeneration with a fallback. There is a fallback value in the incremental static regeneration setting, so that we can say, I will build, at build time, the hundred more popular posts or articles in my e-commerce, whatever, and I will defer the rendering phase for all the other posts or articles at request time with incremental static regeneration. So I will basically generate 100 posts that are the ones that get searched the most and the other ones will be rendered at request time and we will have some nice caching headers thanks to incremental static regeneration and revalidation of course.