NextJS & Meta are pushing React Server Components.
CSR, SSR, SSG or RSC? What the ...
Server-side React is an optimization, not a foundation.
The landscape of modern front-end development has been shifting rapidly, especially with the rise of Server-Side Rendering (SSR) and React Server Components (RSC). With frameworks like Next.js pushing deeper server integration and Vite doubling down on the speed of Client-Side Rendering (CSR), developers are faced with a choice: Should they embrace SSR or stick to CSR?
Many engineering teams jump into SSR and RSC without understanding the trade-offs and follow a cargo culture. Server-side React is an optimization, not a foundation. Treating SSR as your full-stack solution might result in unnecessary complexity.
This article will explore when SSR makes sense and whether CSR is the better choice. It will also explain why staying agnostic should be a priority for forward-thinking developers and tech leads.
Let’s start with some Mythbusting.
Top 10 Myths About SSR
SSR always improves performance. → While SSR can reduce initial load times, it may increase server load and complexity.
CSR is bad for SEO. → Modern search engines can effectively index CSR applications, especially when proper SEO practices are followed.
SSR is necessary for dynamic content. → CSR can handle dynamic content efficiently with client-side JavaScript and APIs.
SSR simplifies development. → SSR adds complexity to the development process, including managing server-side logic and rendering.
CSR leads to poor user experience. → With modern optimization techniques, CSR applications can offer fast and responsive user experiences.
SSR is more secure than CSR. → Both SSR and CSR have unique security challenges that must be addressed appropriately.
CSR is outdated. → CSR remains a viable and effective rendering strategy, especially for applications prioritizing interactivity and offline capabilities.
SSR eliminates the need for client-side JavaScript. → Even with SSR, client-side JavaScript is often necessary for interactivity and dynamic features.
All parts of an application must use the same rendering strategy. → Based on specific requirements, a hybrid approach can be employed, using SSR for some parts and CSR for others.
Switching from CSR to SSR will automatically boost SEO. → SEO depends on various factors, and improper implementation of SSR can negate potential benefits.
How to start, then? Defining the Anchor Point.
An Anchor Point is a starting reference that helps guide decision-making without dictating a rigid rule. In the context of rendering strategies, it provides a default perspective—not an absolute mandate. This means CSR should generally be preferred unless specific needs justify hybrid or SSR approaches. The goal is to avoid unnecessary complexity and opinionated constraints by evaluating trade-offs carefully. Instead of blindly adopting SSR/RSC just because it’s trendy, use this anchor point to think critically about what actually fits your use case.
Understanding SSR, RSC, and CSR
Before diving into the nuances of when to use SSR, let’s define the key approaches:
Client-Side Rendering (CSR): This is the traditional approach where the browser downloads a minimal HTML file, JavaScript, and assets. The JavaScript code executes in the browser, rendering the application dynamically. This method shifts the rendering burden entirely to the client’s device, making it lightweight on the server but potentially slower on the first load, as users must wait for scripts to download and execute before seeing the content.
Server-side rendering (SSR): Instead of rendering components on the client’s browser, SSR generates the HTML content dynamically on the server for each request. The server sends a fully formed page, reducing the time it takes for a user to see content. This approach improves SEO and initial load times but can introduce higher server load and more complex caching challenges.
Static Site Generation (SSG): A method where pages are pre-rendered at build time and served as static HTML files. This enables the best performance for content that does not change frequently, such as marketing pages, blogs, and documentation. Unlike SSR, SSG removes the server-side computation per request, making it highly scalable.
React Server Components (RSC) is a new paradigm introduced with React 18+. It allows specific components to be rendered on the server and streamed to the client. Unlike SSR, which returns fully formed HTML, RSCs enable parts of the component tree to remain on the server while reducing JavaScript bundle sizes sent to the client. However, RSC requires a framework like Next.js to work effectively and can increase coupling between the backend and frontend logic.
SSR and RSC promise performance improvements, but they also introduce interwoven complexity. The real question is: Do you need them?
When Client-Side Rendering (CSR) is the Better Choice
CSR should be your default choice unless you have a strong reason to adopt SSR. Why?
CSR is framework-agnostic: You can switch between React, Svelte, or any frontend tool without losing flexibility. You're locked into its ecosystem when you adopt Next.js’s SSR/RSC-heavy approach.
CSR keeps your backend clean. SSR tightly couples frontend and backend concerns. With CSR, you have an explicit API boundary, which improves maintainability.
CSR is fast where it matters. Most real-world applications benefit more from a snappy, interactive UI than SSR’s initial render speed.
CSR is No Longer Slow
Historically, CSR was criticized for slow initial load times due to heavy JavaScript bundles. However, modern advancements have significantly mitigated these concerns. Here’s why CSR is now highly performant:
Tree-shaking and code Splitting: Modern bundlers like Vite and Webpack remove unused code and split JavaScript into smaller chunks, reducing the initial payload size.
Lazy Loading – Libraries and components can be loaded only when needed, optimizing rendering times.
Efficient Caching & Service Workers – Static assets are cached aggressively, reducing redundant network requests.
Optimized JavaScript Engines – Browsers like Chrome and Firefox continuously improve JavaScript execution performance.
Progressive Hydration & Islands Architecture – Frameworks like Astro and Qwik introduce partial hydration, enabling faster interactivity.
Optimized Resource Loading – Using HTTP/2, Brotli compression, and preloading techniques ensures that critical resources are loaded quickly.
With these optimizations, CSR-based applications can achieve near-perfect Lighthouse scores (100-100-100-100) by implementing best practices.
Important Note: WebApps, PWAs, and App Stores
PWAs (Progressive Web Apps) are a powerful approach to delivering offline-first applications, and CSR is mandatory in this space. Unlike SSR, which depends on a live connection to generate HTML dynamically, PWAs rely on service workers, caching strategies, and offline storage to function seamlessly without a network.
CSR is essential for PWAs because it allows the app to function independently of a server once it has been loaded.
Service workers enable offline experiences by caching assets and API responses, ensuring the application remains usable even without an internet connection.
PWAs can be installed like native apps and distributed through the Google Play Store via Trusted Web Activities (TWA).
Apple's restrictions on PWAs mean that full SSR-dependent PWAs will not pass App Store requirements since they must work offline without a live server.
Hybrid approaches can still work in web environments. For performance optimizations, you can use SSR/RSC while ensuring that CSR allows for complete offline capability.
CSR is the best approach if you plan to ship a web application to the Google Play or Microsoft Store. It ensures the app remains responsive and functional despite an unreliable network.
Choosing the Right Rendering Strategy: Balancing Complexity and Interactivity
This quadrant chart visualizes the trade-offs between application interactivity and complexity, helping guide decisions on rendering strategies. Applications in the bottom-left (e.g., landing pages, news platforms) benefit most from SSR+RSC for SEO and quick loads. Highly interactive but simple apps (e.g., media streaming) thrive with CSR due to reduced server reliance. The top-right quadrant, representing complex and interactive apps like admin panels and social media platforms, often requires a hybrid approach (CSR+SSR+RSC) to balance performance and maintainability. This framework provides a strategic starting point to assess when CSR, SSR, or a mix makes sense rather than defaulting to SSR-heavy architectures.
Performance Benchmarks: SSR vs. CSR
Understanding the performance implications of SSR and CSR is crucial for making informed architectural decisions.
Initial Load Times: SSR often provides faster initial page loads since the server delivers a fully rendered HTML page. This can be particularly beneficial for users on slower networks or devices.
Time to Interactive (TTI): While SSR speeds up the initial load, CSR can offer quicker interactivity after that, especially for dynamic applications.
Resource Utilization: CSR reduces server load by offloading rendering tasks to the client, whereas SSR increases server workload, which can impact scalability.
For a comprehensive analysis, refer to the Comparisons of Server-side Rendering and Client-side Rendering, which provides detailed performance metrics under various conditions.
By the way, since you have read this far in the article, you are likely an aspiring person 🍀. I am teaching you to become a better software engineer and a leader worth following.
You can find me on MentorCruise.com
Which Framework or Builder Shall I Use Then?
Choosing the right tool depends on your use case and approach to rendering:
Use Vite for CSR applications. It provides a modern, streamlined developer experience and better performance than older bundlers. If you are using Next.js with CSR only, that’s fine for now—there’s no urgent need to switch.
Next.js or Remix might be better choices for hybrid or SSR-focused applications. While Vite supports SSR, its out-of-the-box server-rendering capabilities are less streamlined than Next.js.
Do not use Next.js as your backend if you are building a complex application. While Next.js can act as a Backend for Frontend (BFF), it is not a full-fledged framework. A dedicated backend like NestJS, Express, Fastify, or a headless CMS is better for anything beyond simple API routes.
Testing Complexities in Next.js SSR with App Router and Middlewares
Implementing SSR in Next.js, especially with the App Router and middleware, can introduce testing challenges:
Middleware Testing: Meticulous integration tests are required to ensure middleware functions correctly across different routes. Middleware can affect request/response cycles, making unit testing insufficient.
Server and Client Integration: Testing components that rely on server-side data fetching and client-side interactivity necessitates a robust testing setup to simulate various environments.
State Management: Maintaining a consistent state between server and client renders can lead to complex testing scenarios, as developers must account for state hydration and potential mismatches.
Security Considerations in SSR and CSR
Security is paramount in web applications, and rendering strategies influence potential vulnerabilities:
SSR Security Concerns:
Data Exposure: Sensitive data rendered on the server must be carefully managed to prevent leakage in the HTML sent to clients.
Injection Attacks: Server-side code is susceptible to injection attacks if inputs are not properly sanitized.
CSR Security Concerns:
Cross-Site Scripting (XSS): Since rendering occurs on the client, malicious scripts can be injected if data is not properly sanitized.
API Security: CSR relies heavily on APIs for data fetching, necessitating robust authentication and authorization mechanisms.
Implementing security best practices, such as input validation, output encoding, and the use of security headers, is essential regardless of the chosen rendering strategy.
Developer Experience: CSR vs. SSR
The choice between CSR and SSR significantly impacts developer workflows:
Complexity: SSR introduces additional complexity, requiring developers to manage server infrastructure, handle routing on both client and server and ensure proper data hydration.
Development Speed: CSR, which deals primarily with static assets, allows for faster development cycles and simpler deployment processes.
Testing: CSR applications can be tested using standard front-end testing tools. In contrast, SSR applications require more comprehensive testing strategies covering server — and client-side code.
Conclusion: Stay Agnostic, Stay Flexible
SSR and RSC are tools, not mandates. Do not assume you need them by default. If your app benefits from SEO-driven rendering, consider SSR selectively. However, for most applications—admin panels, SaaS apps, PWAs, and interactive dashboards—CSR remains the best choice.
By remaining agnostic (choosing CSR and decoupling the front end from the back end), you avoid the pitfalls of deeply opinionated meta-frameworks while keeping your architecture flexible for the future.
Additional Links & References regarding this topic.
Side Topics
Disappearing Frameworks and Web Development Trends: For an in-depth analysis of emerging web development frameworks that aim to deliver minimal JavaScript to the client, refer to “The State of Disappearing Frameworks in 2023” by Juho Vepsäläinen et al.
Résumé-Driven Development Concerns: To understand the implications of adopting technologies based on trends rather than project needs, see “Resist the Hype! Practical Recommendations to Cope With Résumé-Driven Development” by Jonas Fritzsch et al.
React Framework and Its Evolution: The “React (software)” article on Wikipedia provides detailed information on React, its features, and updates.
Really cool article, is really nice. The only comment I could have is that It is very difficult for me to take Theo seriously, as he is one of the great promoters of not doing Unit Testing. To understand what I mean, just go to Youtube and type "theo unit test"