System Design — CSR vs SSR vs SSG

What is Rendering ?

Rendering a webpage is the process of turning HTML, CSS, and JavaScript code into an interactive page that website visitors expect to see when clicking on a link.

How does rendering impact the Website?

“If bots can’t crawl it, they can’t index it, and that means your site won’t appear in search results.”

The first page of search engine results can capture as much as 92% of web traffic. SEO rankings take into account not only the quality and relevance of content, but factors like speed, security, mobile friendliness, and most importantly, crawlability.

Device type, user location, Internet connection, and network conditions all play a role in user-experienced speed, resulting in metrics that can vary significantly from user to user. The speed can be broken into subcategories, which determine what type of content users can view and the time it takes to render this content:

  • TTFB: Time to First Byte — seen as the time between clicking a link and the first bit of content coming in.
  • FP: First Paint — the first time any pixel gets becomes visible to the user.
  • FCP: First Contentful Paint — the time when requested content (article body, etc) becomes visible.
  • TTI: Time To Interactive — the time at which a page becomes interactive (events wired up, etc).

Although client-side rendering has a fast TTFB, FCP and TTI can take a long time, a problem that is compounded for sites with a lot of dynamic content or API calls, and users with a poor Internet connection.

  1. High- we want fresh data — the most updated one — every single render.
    Sites that benefit- Products page that contains price, The comment section on Twitter, Social media for the latest content. — CSR, SSR
  2. Medium —We should get fresh data, but it’s okay if some still see the stale one.Sites that BenefitBlog post with CMS → you can tolerate it when someone gets the stale page with minor typos, Profile page → it is rarely updated and it is not that critical — ISR
  3. Low to none — We don’t really care, just fetch and show it.
    Sites that BenefitAbout page, A page with fixed data that won’t change — SSG

When we want our content to be easily found on google and bringing in that good organic visitors. “If bots can’t crawl it, they can’t index it, and that means your site won’t appear in search results”.

  1. SEO Friendly — This category is expected when we are pre-rendering the content on the website, the general difference is when we are doing pre-render, we can see the content on the page source.- SSR, SSG, ISG
    Sites that Benefit- Shopping Website, Quora type website- you start basically on google search to get the answers, so the site with good SEO will appear on top, Social media
  2. Not SEO Friendly — we don’t get any content on the page source when the page renders initially. — CSR — as we do not get any content until after the page renders. Sites that Benefit — Registration Page, Authentication Gated Apps

Performance here means to the load time before First Contentful Paint, not to be generalised to the whole application performance.

  1. Instant- Instantly loads because the fetching does not happen when we request. — SSG, ISR
  2. Loads before/after render — There will be a slight loading on before or after renders. — CSR, SSR

CSR- The performance (initial load) depends on the size of the application and how much JS is shipped to the browser .
SSR- There may be latency (depending on the server’s location) because the request has to go to the server and back to the browser.
SSG- This helps improve performance because rendering happens once and the result is stored closer to users in CDN caches(solving latency issues).
ISR: Rendering happens at time intervals and is cached, so it’s still performant but using ISR ensures data doesn’t become stale.

Build time is the amount of time it takes to build and deploy the website.

  1. Fast — When we are using CSR and SSR, we only build 1 page because the data won’t be fetched at build time. It will be fetched when we will load the site.
  2. Slow — When we are using SSG and ISR, we are fetching it on build time and creating a page out of the response. So if we have 1000 products, it will take quite some time.

Different Rendering modes:-


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, on demand, as the user needs it.

Client-side rendering, or CSR, is the most common way of rendering React, Angular, Ember.js, Vue…. apps. This is the usual kind of data fetching using useEffect, it will fetch the data from the API for every single page request on the client-side.

a) The client requests a page through a URL.
b) The server responds to the client with a blank page, with references to JavaScript files.
c) These are downloaded and run by the browser, and used to build the page.
d) Data is fetched and filled in from an API based on the needs of the JavaScript.

Pros :-

  1. The Data integrity is high(shows fresh data) as it fetches on every render.
  2. It’s fast. It’s easy for the server to vend a blank page, and this method only generates the required HTML to be displayed which can be handled with loading indications. Due to lazy loading, client-side rendering can be much faster than server-side rendering.


  • The amount of JavaScript required tends to grow as an application grows resulting into higher loading time. Also , slow network or bigger JS bundles can affect the loading time.
  • As it gets a blank page from the server, it needs to load he JS application and build the page on the browser leading to more waiting time.
  • Less secure due to XSS- Cross Site Scripting
  • Bad for SEO- Since your meta data is being loaded by the JavaScript on the first pass loading, search engines will not see that data when their web-crawlers hit your page
    EX- CSR does not generate accurate link previews — a real problem for sites that rely on social media sharing to drive traffic. When links are shared on social media, a preview should appear with a picture and title to draw users into the site. These previews are generated by crawlers from social media sites that scan HTML for meta tags describing how the preview should look. However, with client-side rendering, a blank HTML file will be sent from the server, resulting in a generic preview that is the same for every page on the site or no preview at all, making the link less enticing to viewers.

How can we improve the performance:-

  1. Critical scripts and data can be delivered sooner using HTTP/2 Server Push or <link rel=preload>, which gets the parser working for you sooner.
  2. Patterns like PRPL are worth evaluating in order to ensure initial and subsequent navigations feel instant.
  3. keeping a tight JavaScript budget and delivering value in as few RTTs as possible.
  4. Use aggressive code-splitting, and be sure to lazy-load JavaScript — “serve only what you need, when you need it”.
  5. Applying Application Shell caching technique. Combined with service workers, this can dramatically improve perceived performance on repeat visits.

When to use:-

  • Use when building a admin dashboard — If your application is only available to authenticated users.
  • for the Single Page App.

Server rendering generates the full HTML for a page on the server in response to navigation. This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response.

Server rendering generally produces a fast First Paint (FP) and First Contentful Paint (FCP). Running page logic and rendering on the server makes it possible to avoid sending lots of JavaScript to the client, which helps achieve a fast Time to Interactive (TTI). React: renderToString()


  1. Data integrity is high.
  2. Loading Time —Once the browser receives the HTML , users are unlikely to be left waiting for CPU-bound JavaScript to process before they can use your site. Ideal for slower connections.
  3. Better FCP and FP for users with poor connectivity.
  4. SEO Friendly — Because all the meta data has already been rendered into HTML when the page is requested, web-crawlers will see all the data from the application, which is ideal for SEO visibility..


  1. Generating pages on the server takes time, and Dynamic HTML can’t be cached by static CDNs, resulting in longer trips to and from the server which can often result in a slower Time to First Byte (TTFB).
  2. Loading a new page in the same site is also slower as it has to retrieve the HTML for each new page.
  3. Navigating across a site is slow.
  4. Latency. Since the server is doing the rendering work, if there are many users accessing the application at the same time, they could experience latency in the loading of the application.
  5. Incompatible with some UI Libraries:- window object doesn't work in Node.

It happens at build time.

Static rendering means producing a separate HTML file for each URL ahead of time. With HTML responses being generated in advance, static renders can be deployed to multiple CDNs to take advantage of edge-caching.

a) The client makes a request to the server.
b) The server receives the request, and has already built the needed HTML pages for the static data.
c) the server responds with completed, pre-built pages based on the URL requested.

You have to rebuild your site if you want it to be updated with new content.
  • If you’re unsure whether a given solution is static rendering or pre-rendering, try this test: disable JavaScript and load the created web pages. For statically rendered pages, most of the functionality will still exist without JavaScript enabled. For pre-rendered pages, there may still be some basic functionality like links, but most of the page will be inert.
  • Slow your network down using Chrome DevTools, and observe how much JavaScript has been downloaded before a page becomes interactive. Pre-rendering generally requires more JavaScript to get interactive.


  1. Fast FCP and TTI — assuming client side Js is limited.
  2. As the HTMl is produced ahead of time for each URL, it manages to achieve a fast TTFB.
  3. As they are generated in advance, the HTML responses can be deployed to CDNs to take advantage of caching.


  1. Individual HTML files must be generated for every possible URL. This can be challenging or even infeasible when you can’t predict what those URLs will be ahead of time, or for sites with a large number of unique pages.
  2. Data is only fetched once at build time, so you can’t refetch and refresh data on the fly.
  3. Build times can be quite long if your site is large and complicated.
  4. Incompatible with some UI Libraries:- window object doesn't work in Node.

When to use:-

  • Client-side rendering is great for logged-in experiences and single-page applications. If you need to authenticate a user on every interaction, CSR is the way to go. Creating proof of concepts where performance isn’t crucial is another use case.Ex- Admin Panel , Bank Accounts, Settings Page (customised for each user).
  • Server-side rendering is ideal for creating pages for slow connections, and keeping SEO visibility strong and when there is user interaction, when the content changes very often. Example- Large e-commerce or Social media platforms.
  • Static-site generation would be perfect if I needed the benefits of server-side rendering but also only depended on a dataset that didn’t often change, as the page would need to be rebuilt to reflect new dependent data.

For React-based developers: NextJs support SSR — SSG, and GastbyJs , react-static for SSG.




Software Engineer III

Love podcasts or audiobooks? Learn on the go with our new app.

HTML5 Canvas Elements

How to setup basic web push notification functionality using a Flask backend

Introduction to Node JS

Google Search native pack’s map is now interactive

How to implement a Linked List in JavaScript

implement linked list in javascript banner nickang

Angular 2 (Introduction to a web development platform)

Routing 101 in ExpressJS

Hack: Issue Creation URL for JIRA

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Eishta Mittal

Eishta Mittal

Software Engineer III

More from Medium

Getting started with Mongoose, a beginner’s perspective

Swell 1.10.2

What is Broken authentication and How to Prevent it in React Application

Guide to create a trackpad app using JS.

Finger on phone with trackpad UI, wifi symbol, Desktop with cursor moving