
The most important thing about Next is that it allows you to pre-render your pages instead of sending an HTML file and a JavaScript file that renders the application, with Next, you have the option to send the fully rendered page which results in the HTML containing meaningful information including texts and meta tags. And when your application contains multiple pages, Next handles them separately. This is the reason why it solves most of the aforementioned problems. 

The first one is pre-rendering all pages during the build step and then sending them to the client. This is called static-site generation or SSG for short and it’s honestly a good solution if your application uses data that doesn’t change very often. But if it does, it is practically unusable. It’s called static for a reason.

So, what do you do when you have a dynamic application? You have several options. One of them is to simply rebuild the pages more often. If you have a blog, you might choose to trigger a new build every hour and that might be enough. This can be optimized by only triggering the build when a user visits your app and by only rebuilding the visited page. This system is called Incremental Static Regeneration or ISR because, in a way, your app regenerates.

However, there are a few drawbacks. The build is triggered when a user visits a page after a certain amount of time. But that user receives the old version of the app, with possibly stale data. And if the data is important, this is unacceptable. The other drawback is that you might end up with many pages which rebuild quite often, especially if you set the rebuild timer, also called cooldown, to only a few seconds.

In this case, you might as well use the third and final strategy Next.js has to offer. It's called server-side rendering, or SSR, and you are probably already familiar with it. When you use server-side rendering, Next renders your app and sends the HTML on each request. The biggest advantage of SSR is that users always have the latest data.
But this comes at a cost. It takes time to process the request and a lot of traffic can make the server quite busy. 

Performance Difference in SSG, ISR, and SSR: 

It should be quite clear that SSG (static-site generation) and ISR (incremental static regeneration) are going to be very fast because data fetching only happens once during the build. This allows the statically generated pages to be cached by CDNs to boost performance even more. With SSR (server-side rendering), data is fetched on each request. This results in a slight delay and if you want to always send the latest data, caching becomes quite complicated. But it is still faster than traditional client-side rendering. Finally, it is important to understand when the loaded page becomes interactive.

The process of making the page interactive is called hydration and it happens after the received HTML is painted. When you use pre-rendering, the painting happens very quickly and that’s what really separates it from client-side rendering. 

Imagine a page where you want to list your blog posts. If you want this page to be statically generated, you use a special method called 

, which gets called during the build process. All you have to do is fetch the posts, return them in props and then use them within the page. To turn this into incremental static regeneration, you simply add a 

property with a time, for example, 60 seconds. This will tell Next to rebuild the page at most every 60 seconds. And if you need to use server-side rendering, you move the fetching code to a special method called 

, which gets called during each page request.

So which approach is the best? That heavily depends on your use case. You should use static-site generation whenever you can, but often, it simply isn’t enough.

If you are fine with a few users receiving stale data, incremental static generation is the way. And whenever you need each user to have the latest data, use server-side rendering. But what if your application consists of pages with different needs? This is where Next truly shines. You can choose which form of pre-rendering you want for each page. In fact, it happens automatically based on the methods you use and by that, I mean the getStaticProps and getServerSideProps

methods. This allows you to create hybrid performant applications where each page uses only what it needs. However, the benefits don’t end there.

If we go back to the blog example, you might wonder how we can generate a static page for each blog post. Next has a method called 

that solves that very problem. In this method, you generate your paths and return them just like that. Another benefit is the Image component Next.js provides. It includes several built-in performance optimizations including lazy loading, serving different images for different devices, and many more. All of these are enabled by default. 

Now, let’s talk about deployment. The easiest way to deploy a Next.js application is to use the 

platform. It was created by the creators of Next itself and is designed specifically for it. When deploying your app using Vercel, it performs several optimizations including caching your assets, performing compression, and so on.

But running Next on your own isn’t difficult either because Next has been built at the top of Node.js, it can run on any Node server, so you can quite easily self-host your application by simply setting up a Node server. Next also has its own Docker image, so you can for example deploy it on Amazon Elastic Container Service or Amazon ECS for short.

So, should you use Next.js? The truth is that no matter what you are building, Next probably has you covered. Even if you aren’t interested in pre-rendering at all, you can choose to use good old client-side rendering.




The most important thing about Next is that it allows you to pre-render your pages instead of sending an HTML file and a JavaScript file that renders the application, with Next, you have the option to send the fully rendered page which results in the HTML containing meaningful information including texts and meta tags.

Understanding and Comparing SSR, ISR, and SSG in Nextjs 

Nextjs is a very amazing react framework, build and maintained by a company named Vercel. It is mainly used for Making SEO friendly websites, and it is used by companies like Netflix, Github, Uber and Starbucks.

When React is already so popular, Then why do all these companies use NextJS?

A typical React application is rendered on client site, which means HTML, CSS and JavaScript is downloaded by the browser. After that, JavaScript takes over and renders the whole page because of which browser gets one bundle of things like Painting the content, downloading an asset along with that posting a blog or populating images. All these tasks are done by JavaScript.

Although this approach sounds good, but this approach has some downsides, one biggest downside is This is not a SEO friendly approach, because bots, like Google, cannot index these types of websites. Along with that, if we talk about social media bots like Facebook, Google Twitter - You guys must have seen sometimes, when you share the link of any social media post on WhatsApp or other application, then a preview image is generated and a preview text is also generated, which means ahead of time without visiting the page, these social media bots read the content of your page. Now all the content in React is populated through JavaScript, So JavaScript cannot be executed Because of which social media bots cannot generate these types of previews.

So, by using React application in this way, the search rankings drop greatly. The reason for this is it takes a lot of time for the first contextual paint to appear and according to core web vitals this is not a good thing. It does not give a good user experience. Nextjs solves this big problem by introducing page building strategies.

NextJS works on a simple principle That, whatever data your browser will receive, it will already have content, which means the main content will not be fetched by JavaScript. For a blog, the main content is the preview image and the post content, so this content will either come already generated from the server, or else it is already build and converted to cache through a CDN. Not just this NextJS has a lot of built-in features Like file-based routing in file-based routing. You can simply make files in your source code and after making these files, your URL structures will come according to these files.

There are many built-in utilities in NextJS. Now let’s talk about the most important feature of NextJS, which is page building strategies In Page Building Strategies. The first strategy is Static Site Generation. In SSG, NextJS converts your whole site into a static site beforehand. For example, you have written a blog which consists of one thousand posts, then your dynamic blog of one thousand posts will be converted into a static website, so that its delivery is fast and social media, bots and search engine bots can read your site properly.

For doing this, all pages can implement a method named 

 which will return some props, which will be passed to that page again. By doing this, whenever you will export the next time and try to build your whole website, then your whole NextJS website, which some way or the other uses React components only. It will be converted into a static site which you can convert into cache through a CDN, which means your content. Delivery will be very fast.

So often, if your data changes very quickly, then you can use another page building strategy whose name is Server Side Rendering. In Server Side Rendering every page can implement a method named 

 and after implementing this, the resulting props, For example, in your getServerSideProps( ). You can request a fetch and you can get that data from fetchAPI or you can pass the same component as props. By doing this, whenever a user will visit your page, they will get the static page. After all, their work is done on the server, so the user will think your site is giving all the static HTML, but in reality, your site is doing some work on the server to fetch your content from the database. So, the users and the social media bots and the search engine bots will get the thing which they need, which makes them happy, and which makes your ranking good along with that, your user will also get satisfaction, because your core web vitals will be amazing.

Your first contextual paint time will be short and because your content is changing very fast, you can see all those changes implementing on the fly. If we talk about Static Site generation, until you build your site again, you won't be able to see the updated content, but by using this strategy you will always see the updated content. If you want your content to keep refreshing also, and along with that, you also want to build a static site, then you can use a page building strategy in between these two, in which you can pass a key named revalidate in getstaticprops. By doing this, whenever your server will receive a request, then your website will rebuild again after a certain period of time.

I hope I have explained it to guys what NextJS is and how does it make the powers of React more better.

Nextjs is a very amazing react framework, build and maintained by a company named Vercel. It is mainly used for Making SEO friendly websites, and it is used by companies like Netflix, Github, Uber and Starbucks. 

Understanding and Comparing SSR, ISR, and SSG in Nextjs

How Nextjs is better than React- Comprehensive Analysis