We will see in this article why you should use SSG over SSR.
Well, don't take this for a generalization
The server doesn't have to do anything except deliver the HTML to the client. Because of this, for users with a slow connection, it's a much faster experience to load a static site than it is to load a server-side rendered (SSR) site because the content has already been processed.
Static sites are also fast, even if the origin is slow. This is because there's no processing required on the origin for static sites—it just has to fetch and deliver the file.
Static sites improve time to first byte (TTFB). TTFB is an important metric that shows how fast your site begins loading in users' browsers—the lower this number, the better. This metric is influenced by many factors including latency, caching, and processing on subsequent requests. Because there's no server-side processing required when using SSGs, they give you instant TTFB and therefore better web core vitals scores from Google Lighthouse.
One of the biggest advantages of SSG is the ability to do build time error-catching. If you've ever used a CSS preprocessor, you'll be familiar with this concept: if you make a mistake in your code and try to compile it, you'll get an error. This is because these preprocessors are running on the client side and are not actually compiling anything.
The advantages of static site generators (SSGs) over server-side rendering (SSR) are numerous, but there is one that stands out to me. It's about resilience. While a server-rendered site is dependent on the API, a static site generator doesn't care. If your API goes down, your page will still display the data that was fetched at build time.
For example, if you have an API like NASA's Astronomy Picture of the Day API, and it goes down for some reason on Christmas or New Years Day or the Super Bowl or whatever day it is that you're having lots of traffic, your site will still work because it has all the data it needs in its own files and directories. The only thing that won't work is rehydration—your page won't be able to fetch new pictures after the initial render. But at least your users will still see something!
First of all, with SSG simpler caching logic is possible. On my site, I cache the generated HTML on a CDN and only regenerate it when one of my markdown files changes. This allows me to have a very fast page load time even on mobile devices despite hosting the site on a small server with no CDN in front of it.
With SSG you can boost performance using CDN caching without a lot of extra configuration. If you have a static site with 50 pages, you can put them all on a CDN and serve them from there instead of your own server, which helps your page load time tremendously—but if you update one of those pages, you need to invalidate that cached version on your CDN. If every page has its own cache-control header, this is easy
SSG is a simpler architecture, with fewer moving parts. It’s also significantly less expensive to run, since you don’t have to pay for the redundant upkeep of multiple servers.
SSGs are also cloud agnostic. You can host them on any cloud provider you like and they will continue to work as advertised.
The security posture of having one less server to worry about is another big benefit. If an SSG is compromised, it only has access to its own data, not anything else on your network or in your environment.
Infinite scale is another major advantage. As long as you have enough capacity on your web server to handle the initial traffic spike, you can add more web servers without worrying about where to put them or how much bandwidth they will consume.
There is the lot of advantages why you should use SSG over SSR. And we see only few, there is a lot more.
But when we start developing a web-application, it's become clear that there is no universal solution. We need to make the decision depending on our project, and should always weigh all aspects carefully. Sometimes SSR will be more advantages than SSG !