Client-Side Rendering (CSR)

Mar 03, 2020 • ☕️ 3 min read

JavaScript frameworks are getting very popular and so do client-side rendered single page applications. Many companies of all sizes are adopting this rendering strategy, let’s look at what make it so appealing and the tradeoffs you have to make when adopting it.

CSR in a Nutshell

Traditionally we prepare complete HTML pages in server before sending to browser for rendering. JavaScript frameworks came in with a completely different approach to web development when they open the possibility to render dynamic content right from the browser.

CSR allows developers to make their websites entirely rendered in the browser with JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server. Instead of having a different HTML page per route, a client-side rendered website creates each route dynamically directly in the browser.

Single-Page Application (SPA) is often tighten to CSR but client-side rendered application can be multi-page as well.

With CSR, most resources (HTML, CSS, JavaScript) are only loaded once throughout the lifespan of application. Only data is transmitted back and forth.

  • User visits website via browser
  • Browser fetches static assets (HTML, CSS, JavaScript, etc.) from server/cdn
  • Browser executes JavaScript to fetch dynamic data from API server
  • Browser processes data, manipulates DOM and renders HTML pages

Benefits of CSR

Interactive desktop-like user experience. Page transitions and user interactions seem very responsive, only update the parts of the UI that need updating, getting only the required data from the server reduces network utilization and latency, best for high-interactive websites like social networks, admin dashboards or marketplaces.

Awesome developer experience. You only have to worry about client code and one user at a time, loosely decoupled with server, and can take many advantages of many mature JavaScript frameworks out there like hot reloading build optimizations.

Consuming less server resources. Offload many tasks to the browser like processing data and generating HTML pages, can be deployed in any static server, and can serve website markup static assets from CDN.

Drawbacks of CSR

The primary downside to CSR is that the amount of JavaScript required tends to grow as an application grows. This becomes especially difficult with the addition of new JavaScript libraries, polyfills and third-party code, which compete for processing power and must often be processed before a page’s content can be rendered.

Offloading too much computing to the browser will slow it down in devices which have constraint resources like budget phones. And completely useless in environments having JavaScript disabled.

Slow time-to-content, especially on slow internet or slow devices. Client-rendered markup have to wait until all JavaScript has been downloaded and executed to be displayed. This generally results in slow first time to interact, and can be critical for applications where time-to-content is directly associated with conversion rate.

Not SEO friendly, search engines will struggle to wait multiple asynchronous content fetches util the pages are fully rendered, this point is important to any sites that depend heavily on SEO.

CSR with JavaScript

React is a system for developing interfaces. It is written in JavaScript and therefore can be run on the client side, but since it is not dependent on anything that can only occur in a web browser, it is also possible to render react pages on the server (using NodeJS)

Create React App is the best React framework to create a CSR app. It offers a modern build setup with no configuration. You don’t need to install or configure tools like webpack or Babel, they are pre-configured and hidden so that you can focus on the code.

Beside React you can also use following libraries and frameworks to build CSR apps: Angular, Ember.js, ExtJS, Knockout.js, Meteor.js, and Vue.js.


Before using CSR for your app, the first question you should ask is whether you actually need it. It mostly depends on how important time-to-content is for your app and SEO impact.

If you are building an internal dashboard where an extra few hundred milliseconds on initial load doesn’t matter that much, CSR would be a good choice. However, in cases where time-to-content and SEO are absolutely critical, you should consider other strategies like server-side rendering, static rendering or universal rendering.

Reading More

Cracking The Frontend Interview, Part 3: CSS

An overview look at core CSS topics that help you ace the frontend interview

JavaScript Module Loaders

Module loaders are libraries that can handle loading modules using the different formats for further processing or executing

Type Safety in JavaScript

Static type checkers and object validators are just incomplete solutions to the unsafe dynamic nature of JavaScript

Become a Fullstack JavaScript Developer, Part 6: The Monorepo

Many companies are adopting monorepo but the decision to use it or not is quite tricky