How different types of Next.js rendering works
Next.js routes can use Server Side Rendering (SSR), Static Site Generation (SSG) or incremental SSG and are not required to all be the same. Each method has pros and cons, we're here to discuss them!
What is Next.js?
Next.js is a framework for building server-rendered React applications. It is an open source project, built and maintained by the team at Vercel, the JAMStack hosting platform. Next.js is our framework of choice at Jellypepper due to its simplicity, flexibility and speed.
When building pages in Next.js, there are a few page rendering and pre-rendering methods available to you. Let's break down the different page rendering types to understand how they work.
Rendering vs. Pre-Rendering
The rendering method refers to the way in which pages are built. When a user visits your site, they will see either a server-rendered page or one that is pre-rendered (i.e. static). Pre-rendered pages are built during the next build step, whereas rendered pages are built and served on request.
For SEO purposes, it is preferable to use both of these types together. This way, search engine crawlers will see the pre-rendered version of your pages and be able to index them.
Server Side Rendering (SSR)
Server Side rendering is the traditional method of serving webpages. SSR pages, which are built when requested by a user, come with many benefits including SEO optimisation, faster initial load times, and less server-side code for your site's build process.
However, because SSR pages require time to be generated before being served (usually at the request of a user), this method may not work for all use cases.
SSR pages are built when requested by a user, meaning that if no one visits your site or you don't have any traffic then SSR won't be used for anything other than building the initial index.js file with ReactDOMServer.renderToString().
Static Site Generation (SSG)
SSG is great if you want something quick and simple: once the website has been built during your build step, it can just serve static files that are hosted on a CDN. This method is great for sites with low traffic, but can't handle high-traffic pages or dynamic content changes without being rebuilt from scratch.
SSG pages are built when the build step occurs during development. This is a good option for sites that will be updated regularly because it requires less time upfront and, as an added bonus, you don't have to concern yourself with setting up routing on your server-side code since this happens automatically!
However, SSG has some drawbacks such as slower load times for initial page views and not getting to take advantage of all the features that come with SSR.
Incremental Static Regeneration (ISR)
Incremental rendering works similarly to the traditional Static Site Generation process by serving static files on a CDN; however, it differs in that when your server receives a first request from a user, it fetches and updates the data to generate an updated static version of your page.
This means that subsequent requests will receive this new static file which is faster than fetching another rendered HTML string for every visitor who visits the site.
Which one do I use?
Fortunately Next.js is super smart when it comes to picking the optimal rendering process for your application. This means that it will automatically detect which one to use and render on server side or serve static files depending on what you have set in next.config.js and package.json, as well as how you've built each particular page.
Next.js offers a lot of flexibility when it comes to how and what the process should be, which means that SSG can be as fast or slow as your application generates data.
Deploying to Vercel
If your site has been configured for SSG, you'll need to redeploy every time you make an update to your content. This means that if you make a change to your app's code and want to see the changes live on production, all you need to do is redeploy with Git!
If you're using a headless CMS like Prismic, you can take advantage of build hooks. Build hooks allow you to run arbitrary code before the build starts and after it's finished. This means that if you've connected Prismic to Vercel via a webhook, you can simply publish new content and it will trigger a new deploy in Vercel.