Client-Side Rendering vs Server-Side Rendering vs Static Site Generation

Subscribe to my newsletter and never miss my upcoming articles

Hello everyone! Today, I want to discuss the different ways a website can be rendered. Every time you visit some website like google.com, facebook.com or amazon.com, your browser has to render that page onto your device so you can interact with it. There are the 3 ways that a website can be rendered onto the browser: client-side rendering, server-side rendering and static site generation. So in this article, I'll be discussing each of their pros and cons, and when it's best to use them.

Client-side Rendering (CSR)

The concept of CSR is simple. Basically, the client, which is our browser, renders the page dynamically using JavaScript. Each route and page content is created and rendered by the browser.

The server only takes care of receiving the page requests and sending back the bare-bone HTML with only <html>, <style>, <meta> and JavaScript. Then, the browser would execute the downloaded JavaScript to render the page content on the browser. An example is Create-React-App, a common framework that uses client-side rendering.

A new React project directory typically looks like:

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  src/
    App.css
    App.js
    App.test.js
    index.css
    index.js
    logo.svg

As you can see, there's only index.html. This is because new "pages" (components) are created by JavaScript instead of having a html for each page. For example, an About page in React would be About.js not About.html.

When to use it?

Client-side rendering is wonderful for websites that facilitate a lot of user interactions because pages are rendered fast after the initial load. It ensures an excellent user experience because the site doesn't have to reload every time the user clicks on a new page. This makes CSR great for Single Page Applications (SPAs) and web apps. The site will just render specific components that the user requested to view.

When NOT to use it?

Unfortunately because the page content is only loaded on the browser, it's more difficult for search engines to crawl and index the site for SEO since it is technically a single page website when it loads. Most search engines, except Google, are still unable to properly crawl and index client-side rendered websites. If your website aims to rank high in terms of SEO, it is better to use server-side rendering.

Server-side Rendering (SSR)

With SSR, the initial request for the site will load the HTML pages, CSS, JavaScript all with their contents fully ready to be rendered. All pages in SSR are static, each page have their own html and so they are not rendered by JavaScript like in CSR. For example, an About page will have an about.html page to render it. A popular example is Next.js, which is a React framework that allows SSR.

When to use it?

As you may have noticed, because pages are pre-loaded from the server, they are almost immediately viewable upon the request. Pages loads faster which makes SSR perfect for static sites. Also, SSR is SEO-friendly which means search engines and crawl SSR sites better than their CSR counterparts.

When NOT to use it?

Of course, SSR does have some instances when it is unsuitable. In particular, sites with a lot of requests should not use SSR because it can slow down page rendering as the server has to send fully rendered HTML pages each time a request is made.

This can also reduce the quality of user experience because the full page has to reload every time a new page or link is clicked. With that said, sites with plenty of user interactions are not very suitable for SSR.

Static Site Generation (SSG)

In recent years, websites became more like apps, with so much additional content, user interactivity and increased responsiveness. Users are now expecting faster load times and excellent user experience (no full page reloading) while companies are competing for good SEO rankings. This means that if you want a website that can initially load static pages fast, is SEO-friendly like SSR sites and can support a lot of user interactivity like CSR sites, a Static Site Generator might be a good solution.

In simple terms, a Static Site Generator is a software solution that results from combining both the methods of CSR and SSR. Some prominent examples of SSGs are Gatsby.js, Hugo and Jekyll.

SSGs work by creating HTML pages using templates to be ready to view at anytime a client requested for it. Unlike SSR, it creates these pages ahead of time, not on demand, which speeds up page loading time.

When to use it?

SSGs truly shine in websites that does not have a lot of frequent content changes like a social media site. A personal website or a blog is perfect for SSGs. It is also very secure, since it serves static pages, there is not database or server prone to attacks. Static generated sites can be deployed in any platform like Netlify, Github and Firebase.

When NOT to use it?

It is quite difficult to use SSGs for websites that has to make frequent content updates because it will have to rebuild the static pages every time there is a change to be made to the site. Also, build time could increase as the application or site becomes too large. So it is not suitable for website or applications that have too many static pages.

Conclusion

All in all, deciding whether to use CSR, SSR or SSG to develop a website depends on the needs and goals for the site. Each has their pros and cons.

Screenshot_3.png

As a developer, it is important to be able to assess which one can fit the purpose of the website. So I hope this has been a helpful read. Thank you so much for taking the time to read. Please like and share any thoughts in the comments below. Cheers!


Images from:

Bolaji Ayodeji's photo

Learnt a lot, thanks for sharing!

Lazar Nikolov's photo

Your post is amazing! Thank you for sharing it. I've just posted about ways to render your website. As web developers I think it's crucial to know this.

Keep up the great work Victoria!

Victoria Lo's photo

Thank you, I will do my best! Thanks for the support! It means a lot :)

Jacob Lamb's photo

This helped a lot thank you!

Subha Chanda's photo

Thanks for sharing! 😀

Motunrayo Koyejo's photo

Really Insightful! Thanks for sharing Victoria

Victoria Lo's photo

You're welcome Motunrayo :)

Luiz Filipe da Silva's photo

Very helpful explanation. Thanks for sharing!

Victoria Lo's photo

Always happy to share! Glad you enjoyed the read :)

NELSON MICHAEL's photo

Awesome explanation, it gave me a full understanding

Victoria Lo's photo

Yayy! Glad it's helpful!

Tapas Adhikary's photo

Nice comparisons, Victoria Lo! Loved it.

Another place I felt "When NOT to use SSG" is when the maintainers of the app are not developers(or non-technical) backgrounds.

Now this is true for all the classes. But with SSG there is a notion that it can be used by (and with) an environment where hard core technical abilities are not required. That's where it is probably famous for blogs, personal site etc. Just wanted to add that 🙂.

Victoria Lo's photo

Awesome! Thanks for sharing your input! 😍

Ujah Emmanuel's photo

Interesting read. Thanks @victoria

Victoria Lo's photo

No problem Ujah! :)

Shamaayil Ahmed's photo

Really helpful..

Rutik Wankhade's photo

Very insightful. 🙌

Jacob Lamb's photo

What about Sapper?

Victoria Lo's photo

According to their docs (sapper.svelte.dev/docs), it is SSR.