Frontend Rendering: SSG vs ISG vs SSR vs CSR - When to use which?
Tags: webdev, javascript, programming, html
Published: 2022-03-06 06:18:21

---
canonical_url: https://tapajyoti-bose.medium.com/frontend-rendering-ssg-vs-isg-vs-ssr-vs-csr-when-to-use-which-1bf9f39ff07c
---

**So many jargons 😱!** Let's not **overload** and **fry** our brains and check them out one by one.

## 1. Static Site Generation (SSG)

![Static Site Generation](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gcpw9ykljv00g825c2yx.png)

> A **static site generation** is the process of generating a full static **HTML** website based on raw data and a set of templates. Essentially, a **static site generation** automates the task of coding individual **HTML** pages and gets those pages ready to serve to users ahead of time.

In simple terms, **SSG** **pre-renders all the pages of your website** and **serves them as per the client's requests**.

### Pros

1. A **static site generator** provides the ability to generate a completely static **HTML-based** site that requires little to no **database** or **server-side processes**.
2. Static sites are the **fastest form of web pages** as they are pre-baked and ready to be served to users.
3. Since the website is **pre-baked**, the content is much more secure.
4. **Search Engine Optimization (SEO)** friendly.

### Cons

1. Content editing and publishing are difficult. Editors may require access to the `Git` repository rather than a simple web app interface.
2. Content updates require the site to be **rebuilt, tested,** and **finally deployed**.
3. Maintaining large websites becomes cumbersome, not to mention the huge build time.

### When to use SSG?

Even though **SSG** has a lot of benefits, you should use it only when you have a website where the **content rarely changes**, like a product showcase website.

If you have a blog, you may use **SSG**, if you are okay with redeploying the site every time you make any modification.

For a site with any form of dynamic content, **SSG** is a strict no-no.

## 2. Server-Side Rendering (SSR)

![Server-Side Rendering](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qyw35i426iaj9mreahuc.jpg)

> **Server-side rendering** (SSR), is the ability of an application to **generate the web page on the server** instead of only **rendering it in the browser**. Server-side sends a fully rendered page to the client; the client's **JavaScript** bundle takes over and allows the `SPA` framework to operate.

In **SSR**, since the page is rendered on the server and sent to the client, it opens up the possibility of using dynamic data and still having great **SEO**.

### Pros

1. Can be used to create pages with dynamic content.
2. Though not as fast as **SSG**, **SSR** has fast **perceived performance**, as the visible content appears as soon as the page is loaded.
3. **Search Engine Optimization (SEO)** friendly.

### Cons

1. **SSR** requires **high computational power** on the server as every request is processed on the server.
2. **SSR** sites are harder to keep secure because they have a **bigger surface to attack**.
3. `Caching` requires a lot of complex configurations.

### When to use SSR?

Since **SSR** has the potential to significantly drive up the server cost, it should be used sparingly, only when you have a **site with highly dynamic content** that changes very frequently and **heavily relies on SEO**. One such example might be a stock ticker website that gathers users from organic searches.

## 3. Incremental Static Regeneration (ISG)

> **Incremental Static Regeneration** (ISR) enables you to use static-generation on a per-page basis, without needing to rebuild the entire site. With **ISR**, you can **retain the benefits of static sites while scaling to millions of pages**.

**ISR** is incredibly powerful because it brings **the benefits of SSG and SSR together** and creates a more efficient and scalable solution.

### Pros

1. Just like **SSG**, **ISR** is extremely fast, due to pre-rendering the pages and caching them.
2. Content modification **does NOT require re-deployment** of the site.
3. **Search Engine Optimization (SEO)** friendly.

### Cons

1. There is one huge drawback to **ISR**, users might end up **viewing stale content** if they **visit the site after the content has been modified, but the new version of the site is not yet available**.

### When to use ISR?

Ideally, **ISR** should be used when you have a site where the content is dynamic but does NOT change frequently. A few examples of such sites would be **blogs** or **personal websites**.

My [personal website](https://tapajyoti-bose.vercel.app/) too is made using **ISR**, to ensure updating the website I need to only **update the data in the database**.

## 4. Client-Side Rendering (CSR)

![Client-Side Rendering](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h7mehr49x14q0jkmwujt.jpg)

> **Client-side rendering** (CSR) means rendering pages directly in the browser using **JavaScript**. All logic, **data fetching**, **templating**, and **routing** are handled on the client rather than the server.

In **CSR**, the server returns a **blank HTML** page and a **JavaScript** bundle that handles all logic.

### Pros

1. Can be used to create pages with dynamic content.
2. Does NOT drive up the server cost, unlike **SSG**.
3. After the initial load, loading other pages are very fast.

### Cons

1. Doesn't work well for **SEO**.
2. Slow **initial load** time & **time to become interactive**, causing **poor performance**.

### When to use CSR?

**CSR** is ideal for any site which does NOT rely heavily on **SEO**. It can be used to create **rich site interactions** and **web & even cross-platform applications** using tools like **Tauri** or **Electron**.

## Wrapping Up

The rendering method totally depends on the requirements and the **UX** plan of the project. The final call is yours to make.

You don't even have to stick to only one method for an entire website, different methods can be used for different pages, eg: **SSG** for about and home pages, **ISR** for faq pages, and **CSR** for the actual web application.

I hope this article helped you to understand the basic concepts of rendering practice.

**Happy Developing!**

Finding **personal finance** too intimidating? Checkout my **Instagram** to become a [**Dollar Ninja**](https://www.instagram.com/the.dollar.ninja/)

# Thanks for reading

Need a **Top Rated Front-End Development Freelancer** to chop away your development woes? Contact me on [Upwork](https://www.upwork.com/o/profiles/users/~01c12e516ee1d35044/)

Want to see what I am working on? Check out my [Personal Website](https://tapajyoti-bose.vercel.app) and [GitHub](https://github.com/ruppysuppy)

Want to connect? Reach out to me on [LinkedIn](https://www.linkedin.com/in/tapajyoti-bose/)

I am a freelancer who will start off as a **Digital Nomad** in mid-2022. Want to catch the journey? Follow me on [Instagram](https://www.instagram.com/tapajyotib/)

Follow my blogs for **Weekly new Tidbits** on [Dev](https://dev.to/ruppysuppy)

**FAQ**

These are a few commonly asked questions I get. So, I hope this **FAQ** section solves your issues.

1. **I am a beginner, how should I learn Front-End Web Dev?**
   Look into the following articles:

    1. [Front End Development Roadmap](https://dev.to/ruppysuppy/front-end-developer-roadmap-zero-to-hero-4pkf)
    2. [Front End Project Ideas](https://dev.to/ruppysuppy/5-projects-to-master-front-end-development-57p)