In this final post of the series, we shall compare the pros of cons of Client-Side Rendering (CSR) and Server Side Rending (SSR).

Just a recap of the terms:

• CSR: When web applications use AJAX to write dynamic HTML on the browser.
• SSR: When web applications use template engines to write dynamic HTML on the server.

Evaluation Metrics

We shall compare both approaches across the following metrics;

• Search Engine Optimization
• Link Previews
• Hosting
• Scaling
• Offline Support
• User Experience
• Performance

Search Engine Optimization (SEO)

Search engines use web crawlers to search and index pages of the internet. However, web crawlers support very little if any javascript, therefore SEO is a major challenge for CSR apps. On the other hand, SSR apps are very compatible with web crawlers as the page content is all ready rendered when visited by them.

Link previews

Link previews are the image and metadata that appear when a link is shared on a website. This feature is very common on social media platforms.

However, just like web crawlers, this feature works by retrieving the static meta-data content of a page. As single-page apps can only have one shared meta-data tags for all views, the same link preview appears regardless of the URL path.

The entire pages of SSR apps can vary and thus produce unique and relevant link previews for each URL of the app.

Hosting

CSR apps are static sites. This means they are comprised of static HTML/CSS/JS files that require no application server. The following are static site hosting services:

• Github Pages
• Render Static Sites
• Netlify Edge
• Firebase Hosting
• Surge
• Vercel

All of which will host your static application for free and for the most part deploys your site on a CDN for high availability.

SSR apps, however, require an application server and thus need to be hosted by what I call 'dynamic site' hosting services (Cloud VM, VPS, App Hosting, Cloud Functions). Some services which host them for free (without credit cards) are as follows:

• Heroku (App hosting)
• Firebase Functions (Functions hosting)
• Netlify Functions (Functions Hosting)
• KintoHub (App hosting)
• Always Data (App Hosting)
• Vercel Functions (Functions hosting)

Scaling

Scalability is a crucial factor when considering CSR and SRR. Static apps can scale near indefinitely for free. This is because static site hosting service would ensure your app's availability. If you are using a hosted database service or API integration they would be responsible for scaling as well. Many APIs or databases are subject to free-tier usage limits and incur charges after they are exceeded.

On the other hand, when you have to deploy backend code you will need to consider your system design to ensure your app handles high load in production. You may need to consider load balancers and running multiple instances. Services like Heroku can help with this as long as you design your app server to be stateless.

Because SSR apps require your own app server, scaling is not as straight forward as CSR apps.

Offline Support

CSR SPAs are very compatible with offline-first experiences via the Progressive Web Application (PWA) model. While there exist methods for creating MPA PWA's it is not as straightforward as SPAs. Unless the application is isomorphic, offline functionality is incompatible with SSR because of their strict dependency on the application server.

User Experience

CSR apps typically do well on fast & modern devices and browsers. They are your best bet for an app-like feel and offline support (once built well and ran on modern devices). (Non-Isomorphic) SSR apps depend much less on the capabilities of the device and give a more traditional website experience as the user navigates from one page to another.

Performance

CSR SPAs are Javascript intensive therefore, features and performance depend heavily on the browser and the device. DOM manipulation can often be more computationally expensive than requesting a new page from a server. Due to this, SSR apps have a theoretical upper hand when it comes to performance on a wide variation of browsers and devices. That being said, isomorphic strategies and client-side frameworks are always improving to address this issue.

Overall Comparison

The figure below summarizes my findings in comparing SSR vs CSR. I further separate it by the SPA/MPA architectures. In an attempt to minimize controversy, I use a simple 3-star scale to indicate the difficulty for a rendering technique to achieve a particular metric. ⭐⭐⭐ (easy), ⭐⭐(normal), ⭐(not so easy)

Note:
SSR MPA: Fullstack stack web app (eg. a Django App)
SSR SPA: Isomorphic frontend app (eg. Next.js)
CSR MPA: Static sites without a router (eg. a Gatsby site (kinda...))
CSR SPA: Frontend web app (eg. React App)

There's some nuance left out of this table so it should be taken with a grain of salt. Different approaches provide different features over others so its not always a one-to-one comparison.

Conclusion

While the diversity of approaches in web development may be overwhelming at times, we get the advantage of catering to many varied use cases. When deciding on an approach, I think it's a good idea to first clearly define and prioritize your goals then select the approach which best helps you achieve them. Thanks for taking the time to check out this series and if I left anything out or got something wrong please drop a comment below! I'd be happy to amend and give credit.

Related Discussions

• DevTo: 🛠✨ Demystifying SSR, CSR, universal and static rendering with animations
• Medium: SSR vs CSR: The ever on-going debate
• Medium: The Benefits of Server Side Rendering Over Client Side Rendering
• Blog: SSR vs CSR vs Static Render
• Devto: SSR vs CSR
• YouTube: The Drawback of CSR
• YouTube: Tech Talk CSR vs SSR
• Twitter: How much faster is SSR?
• Google Blog: Rendering on the Web