SSG, ISR, SSR, and CSR: What the Heck!

I would like to point out some terminology before we begin:

1. SSG: Static Site Generator

2. SSR: Server Side Rendering

3. ISR: Incremental Server Rendering

4. CSR: Client Side Rendering

Table representation

Visual representation

source 1 :https://vercel.com/blog/nextjs-server-side-rendering-vs-static-generation

source 2: https://nextjs.org/docs/basic-features/pages

source 3: https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/

source4：https://github.com/vercel/next.js/discussions/21834

The story begins here.

In recent times, I have encountered a problem with next’s Vercel service. I operate a blog type website, with over 10K entries/blogs, that continues to grow on a daily basis.

In terms of SEO and the benefits of speed, I think that generating a static site for my blog using SSG would be a good idea. But, the problem is that, if I continue to add new blogs to the database, the static site won’t update accordingly.

As a result, I decided to use ISR, since, as you can see from this diagram, ISR is something in between.

Therefore, I first pulled all blogs from the database and built them all at once into static pages, then for newly added pages, I used the revalidate parameter, so that the server would continue to generate the pages over time.

However, the problem occurred when the pages reached 10K, because once it deploys to vercel, it takes forever and once the build time exceeds 45 mintues, vercel will stop working and error out, a further inspection into the matter suggests the following:

“The maximum number of files that can be uploaded when creating a Deployment is 10,000 for source files and 16,000 for build output files”

Thus, it is a bad idea to generate all static pages from database; it makes more sense to generate a few, for example only 100 popular blogs, we will call getStaticPaths() at build time so it won’t take forever, and it will dynamically cache and regenerate pages on the fly, with revalidate parameter to set to a small number, for instance, 10 seconds.

Using this trade-off method, we are able to benefit from both SSG and SSR at the same time, making it neither entirely SSG nor entirely SSR.

Now, the build time takes about 3 mins and problem solved!

Here is another example:

https://github.com/jherr/pokemon-next-three-ways