Next.js is a React framework for developing single page Javascript applications. There are quite a lot of benefits when it comes to choosing this framework, one of the highlights being how incredibly performant Next.js is. This is due to its Server Side Rendering (SSR).
Understanding pre-rendering in Next.js
React uses client-side rendering by default, and the user is required to have JavaScript enabled on their browser.
With Next.js, HTML is generated for each page in advance, instead of having it all done by client-side JavaScript. I must admit I initially found this odd not seeing any HTML files in my codebase!
This results in better performance and a more indexable and crawlable website, essential for Search Engine Optimisation (SEO). It pre-renders the application into static HTML, allowing the user to see the UI without having to run JavaScript.
It also only loads the Javascript and CSS files that are needed for that specific page, which is called automatic code splitting. This gives the users a much faster experience with a nearly instant page load. Because there is less for the user’s browser to download, it increases performance.
As soon as a page is loaded by the browser, the JavaScript will run on the client-side to give it full interactivity. This process is called hydration.
Two forms of pre-rendering
In fact, Next.js gives us two methods of pre-rendering:
Static Generation and Server-side Rendering. The difference lies in when the HTML is generated for a page.
With Static Generation the HTML is generated at build time. As it's been pre-rendered, the HTML is then reused on each request.
We also have the option of Server-side Rendering is the pre-rendering method that generates the HTML on each request.
This choice can be done on a per-page basis, meaning you can create a hydrid Next.js project by choosing which pages will use Static Generation and which ones will use Server-side rendering.
Although we have that option, Static Generation is the recommended method by Vercel since your page can be built once and served by CDN, resulting in a much faster experience. This would be the best option for when you have static content, as you won't have to wait for the server to render the page on every request.
Top comments (2)
It entirely depends on your use case. If you have a complex app interacting with an API, static generation likely isn’t the right choice, because your rendering depends on API data, which kinda defeats the purpose of static generation. In this type of use case, you’d almost certainly wanna choose server side rendering.
That being said, if you have a simpler site with mostly static content, you’d definitely be better off with static generation.
Definitely, I’ve clarified that in the article. Thanks for pointing that out! It’s indeed the recommended by Vercel in their documentation to serve static content.