Why do we love Isomorphic/Universal rendering?

CSR and SSR multiple reasons to choose one over the other

9 min readSep 28, 2019

This doc will give you an overview of the pros and cons of using CSR and Isomorphic rendering solutions. This will cover all the detailed study/ experiments conducted using different tools on varied parameters to gauge the performance benefits of one over the other. We have also discussed the typical scenarios/example applications for both the approaches to give you a clear direction on right usage of both the approaches.

How it works!

CSR: Default setup of CSR application is a “root” element(HTML element) with some scripts tags. This root element inflates into meaningful content once the scripts execute.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Application</title>
    <link href="./css/app.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="root">
      <!-- place for page content -->
    </div>    <script src="./scripts/app.js" type="application/javascript">
    </script>    <script src="./scripts/vendor.js" type="application/javascript">
    </script>
  </body>
</html>

Isomorphic: In Isomorphic, you generate the meaningful content of your page on the server and send it down as static HTML while Javascript loads. Once the JavaScript is ready, the CSR application will take over the page.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Application </title>
    <link href="./css/app.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="root">
      <div>
        <nav class="nav">
          <a href="/init">Home</a>
          <a href="/init/search">Search Data</a>
          <a href="/init/about">About</a>
          <a href="/init/randomUser">Random User</a>
        </nav>
        <h1>Welcome to My Application</h1>
      </div>
    </div>    <script>
      window["redux_state"]={"filter":"","user":{name:"Sujaan"}};
    </script>
    <script src="./scripts/app.js" type="application/javascript"></script>
    <script src="./scripts/vendor.js" type="application/javascript"></script>
  </body>
</html>

Reasons to prefer Isomorphic/SSR over CSR

Here are the few reasons to prefer Isomorphic over CSR:

Improve perceived page performance for better UX
Consistent SEO performance.
Avoid blank page flickering.

In the following section, I will explain the above points with live data points from my CSR and Isomorphic applications.

1. Improve perceived page performance for better UX.

In Isomorphic application, a user gets the first response as a data-filled HTML page. So, instead of getting the empty container for content(which is the case with CSR), the user will get to see the text headers, paragraphs, anchor tags, buttons, input fields, dropdown, etc. (In case of CSR, all these get inflated once Javascript loads and executes)

This early rendering will give a sense of improved performance which is better UX.

Experiment 1:
To test the above statement, we used Lighthouse and data were collected for both CSR and Isomorphic application.

Let take a brief overview of the lighthouse way of performance comparison first. Lighthouse says that the performance of a website is measured by:

First contentful paint: This measures the time from navigation to the time when the browser renders the first bit of content from the DOM
First meaningful paint: This audit identifies the time at which the user feels that the primary content of the page is visible.
Speed index: Speed Index is a page load performance metric that shows you how quickly the contents of a page are visibly populated.
First CPU idle: The First CPU Idle metric measures when a page is minimally interactive

CSR:-

Isomorphic:-

There is a striking difference between the CSR and Isomorphic according to the lighthouse tool. First contentful paint, speed index, first meaningful paint all seems have improved with Isomorphic.

Experiment 2:
Further exploring the performance parameter “Meaningful Paint” we used ‘Chrome Developer Tool’ to calculate the actual performance gain.
CSR:-

Isomorphic:-

This shows 90% performance gain in the ‘Meaningful Paint’ rendering.

CSR meaningful view: 2000 ms
Isomorphic meaning view: 200 ms

2. SEO performance is consistent

Search crawlers are now able to parse and execute javascript. Google bot, in particular, is a PhantomJS script that runs as Chrome 41.

If Google can run JavaScript and thereby render client-side views, why is server-side rendering necessary for SEO?

Chrome 41 is the older version and will require a lot of polyfills e.g. Promises will not be supported, etc.
Google is not the only search engine. Most search bots aren’t capable of parsing Javascript.

This is why SSR/Isomorphic makes sense since you won’t be sending down the unnecessary polyfills to all your users just so that Google bot can render your page.

3. Avoid blank page flickering.

The blank page flicker that happens with CSR doesn’t happen with Isomorphic/SSR, because we are getting HTML content in the first response. (Though in CSR mostly this problem gets solved by showing a loader which gets passed in the initial response)

To compare more parameters, we also fetched the data from the chrome performance tool which gives the timeline for rendered page content.

CSR:

Isomorphic:

In the above page rendering timelines, you will see content take place of the blank white screen of the browser much earlier than the CSR application.
So, end-user will not see blank page or loader, instead, they will find useful content to engage with, which is better UX.

Reasons NOT to prefer Isomorphic/SSR over CSR

Isomorphic/SSR comes with a few caveats:

Time to first byte(TTFB) is slower though perceived page load time is faster.
Lower server throughput because it will take longer to process and render a page. (SSR)
Constant time to page interaction (TTI)

1. Time to first byte (TTFB) is slower

A slow time to first byte (TTFB) is recognized by a high waiting time. It is recommended that you have this under 200ms.

For this comparison, we have created a page which will fetch the data from the API to show the content.

CSR || Isomorphic

In the case of client-side data fetching and rendering (CSR), time to the first byte is on the lower side than Isomorphic application. The SSR pages have view specific content on them, for which server do processing. This also increases the size of the page to be downloaded thus, increasing TTFB.

(Relative to CSR) Additional TTFB with Isomorphic = Server page processing time + time taken to download additional bits of increased page size

2. Lower server throughput:

In Isomorphic, the server fetches the data, processes it and generates the initial page to respond. The longer it takes, lower will be the server throughput which eventually has an impact on the end-end latency.

CSR:

In CSR application, you generate the assets on build time and upload them to CDN. The server will have the responsibility of generating the HTML page with assets embedded to it.

Isomorphic:

In Isomorphic/SSR with React, the server throughput impact is large. renderToString is synchronous CPU bound-call, which holds the event loop, which means the server will not be able to process any other request till the function call completes.

For this data point, we hosted the Isomorphic sample application and monitored the server throughput with a simple home page, containing the few HTML elements like anchor tags and text content.

Following is the server load which we put while testing it
The number of concurrent connection = 3000
Duration = 15 minutes
The number of pipelined requests = 1

There are two tables:

Table for the request latency, and
Table for the request volume.

Request latency table lists the request times at the 2.5% percentile, the fast outliers; at 50%, the median; at 97.5%, the slow outliers; at 99%, the very slowest outliers. Here, lower means faster.

160 ms is the fastest response,
1 second 557 ms is the average and
10 seconds 32 ms is the slowest.

Request volume (2nd table) table lists the number of requests sent and the number of bytes downloaded. These values are sampled once per second. Higher values mean more requests were processed.

2.03 MB with 743 request per seconds is the worst case
4.88 MB with 1776.49 request per second is the average
8.19 MB with 2997 request per seconds is the best case

3. Constant time to page interaction

While the HTML page is being generated on the server and user will see the content earlier than the CSR application, but they can’t interact with it until javascript is done downloading and executing. Completion in Javascript execution will add events to the page, which are responsible to make page interactive like button click, navigation, input, etc. So, if the customer is really fast and clicking a button or page navigation, the browser won’t execute that action until Javascript execution is complete.

Summary

This table will give you a quick overview of the comparative study we did across different parameters. My recommendation is to have a clear understanding of your application use cases, target customers before deciding on your rendering methodology.

FAQs

Q1. I am creating a new Web Application. Among Isomorphic and CSR, which is the preferred choice?
It depends on your application use cases and target customers. If your application requires better-perceived page load performance, better SEO then you might consider Isomorphic.

For devices (both mobile and desktop) with low computing power, Isomorphic rendering will help in rendering the page from server-side therefore increasing the perceived load time of the page. However, if your users are on a low network like 2G or 3G its better to opt-in for CSR as your rendering happens at the client-side and the bandwidth consumption for initial page load is minimal. Opera-mini and UC browsers are compressing browsers render the HTML in a completely different manner compared to Chrome which could lead to different user experience for your customers. To keep the UX uniform across browsers, Isomorphic could be an ideal choice.

Q2. Isomorphic is an ideal solution for my application. But server throughput is worrying me. Any recommendation to overcome this?
Server throughput with Isomorphic can be improved to a certain extent. Following are a few configurations which you can use in Isomorphic.

Enable node stream in Isomorphic which uses “renderToNodeStream” instead of “renderToString”
Caching streamed HTML
UI Component caching

Q3. UI performance is not my priority, but SEO is (across search engines). Are there any alternates to Isomorphic?
You can use UI Sniffing (requester info fetch mechanism) to detect the search bot requests and respond with content filled HTML pages (SSR). Here is a video straight from Google to demonstrate this approach.

Q4. Can you suggest a typical scenario where a developer should prefer CSR?
Consider an Admin portal application which does production server backups, restore and monitoring. You would typically focus more on the user data to be available at the earliest than a performant UI/UX. SEO takes a back seat as the data is confidential and most of your end users are on high computing devices.

User will register and login to the portal
User will see the dashboard with graphs of health, backup and restores
95% of users will be technical admins
most traffic will come from the high-end devices mostly laptops and desktops. Negligible from mobile web.
Most of the target users will use chrome, firefox, and IE

Q5. Can you suggest a typical scenario where a developer should prefer Isomorphic?
Consider a web application that you have built for aggregating conferences in your city. This application would typically list all the meet-ups and conferences in your area which you will publish for the tech community in your city. For such end-use application, you might require a great performance UX, faster page load time, better SEO and the application should work seamlessly on a relatively wide variety of low-end devices.

List page to show all the conferences
Detail page of each conference will have all the topic and location-related details
Page content will vary based upon customer current location and current date
Logged in users will see pre-defined interests related options
80% of traffic will come from devices with low computing power (both mobile and desktop)
Most of the target users will use Chrome, opera mini, and UC browsers.

Finally

You must have found this useful, “Press clap”.