Static Site Generation

So, here’s a question—if we need to build a dynamic page and SEO isn’t really important (admin pages, private profile pages, etc.), why don’t we just send a static page to the client and load all the data once the page has been transferred to the browser?

So far, we’ve seen two different ways of rendering our web apps: on the client side and server side. Next.js gives us a third option called static site generation (SSG).

With SSG, we will be able to pre-render some specific pages (or even the whole website if necessary) at build time; that means that when we’re building our web app, there might be some pages that won’t change their content very often, so it makes sense for us to serve them as static assets. Next.js will render these pages during the build phase and will always serve that specific HTML that, just like SSR, will become interactive thanks to the React hydration process.

Advantages of SSG

SSG brings a lot of advantages when compared to both CSR and SSR:

• Easy to scale: Static pages are just HTML files that can be served and cached easily by any content delivery networkA content delivery network is a geographically distributed network of proxy servers and their data centers. The goal is to provide high availability and performance by distributing the service spatially relative to end users. (from now on, CDN). But even if we want to serve them using our own web server, it will result in a very low workload given that no hard computations are needed for serving a static asset.

• Outstanding performances: As said before, the HTML is pre-rendered at build time, so both the client and server can bypass the runtime rendering phase for each request. The web server will send the static file, and the browser will just display it, as easy as that. No data fetching is required on the server side; everything we need is already pre-rendered inside the static HTML markup, and that reduces the potential latency for each request.

• More secure requests: We don’t need to send any sensitive data to the web server for rendering the page, and that makes life a bit harder for malicious users. No access to APIs, databases, or other private information is required because every piece of information needed is already part of the pre-rendered page.

The limitations of SSG

SSG is probably one of the best solutions for building performant and highly scalable front-end applications. The biggest concern about this rendering technique is that once the page has been built, the content will remain the same until the next deployment.