SSR VS CSR in Next.js - All u need to know

This comprehensive guide unpacks everything you need to understand about Server-Side Rendering (SSR) and Client-Side Rendering (CSR) in Next.js - from theoretical foundations to practical implementation patterns.

Understanding the Rendering Spectrum

Next.js provides multiple rendering patterns, but the two fundamental approaches are Server-Side Rendering (SSR) and Client-Side Rendering (CSR). To make informed architectural decisions, you must first understand what each approach entails.

What is Server-Side Rendering (SSR)?

SSR in Next.js generates the full HTML for a page on the server for each request. When a user visits a page:

1. The server receives the request
2. Next.js executes React components on the server
3. HTML is generated with all content already in place
4. This HTML is sent to the browser along with JavaScript code
5. The browser displays the HTML immediately
6. React “hydrates” the page, attaching event handlers to the existing HTML

SSR has been available since Next.js was first released, but has evolved significantly with the introduction of the App Router in Next.js 13+.

What is Client-Side Rendering (CSR)?

CSR in Next.js generates minimal HTML on the server and relies on JavaScript executing in the browser to render the page:

1. The server sends a minimal HTML shell with necessary JavaScript
2. Browser downloads and executes the JavaScript
3. JavaScript code runs React to build the UI from scratch
4. Content appears once React finishes rendering

In Next.js, CSR is typically implemented via the useEffect hook for data fetching or by using Client Components in the App Router.

Core Technical Differences

Let’s examine the key differences between these approaches by focusing on several critical dimensions:

Initial Load Experience

SSR:

• First Contentful Paint (FCP) is typically faster
• Content is visible immediately in the initial HTML
• Eliminates content layout shifts
• Provides a complete experience even before JavaScript loads

CSR:

• Shows loading states initially
• Content appears only after JavaScript executes
• Often creates a “waterfall” loading pattern
• May display layout shifts as content loads

SEO Implications

SSR:

• Search engines receive complete HTML content
• Meta tags, structured data, and content are immediately available to crawlers
• Social media platforms can extract preview information reliably
• Optimal for content-focused sites where search ranking matters

CSR:

• Search engines might not execute JavaScript (though Google has improved)
• Content isn’t immediately available to crawlers
• Can negatively impact SEO if not implemented carefully
• Requires additional work to make content accessible to crawlers

Performance Considerations

SSR:

• Higher server resource usage
• Potentially slower Time to First Byte (TTFB)
• Faster First Contentful Paint (FCP)
• Often better Core Web Vitals scores
• Reduced client-side JavaScript execution

CSR:

• Lower server load
• Faster TTFB but slower FCP
• More client-side JavaScript execution
• Potential for janky user experience during rendering
• Can be optimized with code splitting

UX and Interactivity

SSR:

• Initial content visible before JavaScript loads
• Time to Interactive (TTI) depends on hydration completion
• May have a “hydration gap” where content is visible but not interactive
• Can lead to “uncanny valley” effect where the page looks ready but isn’t

CSR:

• Nothing shows until JavaScript executes
• Once rendered, instantly interactive
• No “hydration gap”
• May feel slower initially but more consistent once loaded

Implementation in Next.js

Now that we understand the conceptual differences, let’s explore how to implement each approach in Next.js, focusing on both the Pages Router and the newer App Router.

SSR Implementation

Using Pages Router:

// pages/products.tsx
import { GetServerSideProps } from "next";

export const getServerSideProps: GetServerSideProps = async context => {
  // Fetch data on every request
  const res = await fetch("https://api.example.com/products");
  const products = await res.json();

  return {
    props: {
      products,
      timestamp: new Date().toISOString(),
    },
  };
};

const ProductsPage = ({ products, timestamp }) => {
  return (
    <div>
      <h1>Products</h1>
      <p>Generated at: {timestamp}</p>
      <ul>
        {products.map(product => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
};

export default ProductsPage;

Using App Router:

// app/products/page.tsx
async function getProducts() {
  const res = await fetch("https://api.example.com/products", {
    cache: "no-store",
  });
  return res.json();
}

export default async function ProductsPage() {
  const products = await getProducts();

  return (
    <div>
      <h1>Products</h1>
      <p>Generated at: {new Date().toISOString()}</p>
      <ul>
        {products.map(product => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
}

CSR Implementation

Using Pages Router:

// pages/client-products.tsx
import { useState, useEffect } from "react";

const ClientProductsPage = () => {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchProducts = async () => {
      try {
        const res = await fetch("https://api.example.com/products");
        const data = await res.json();
        setProducts(data);
      } catch (error) {
        console.error("Failed to fetch products:", error);
      } finally {
        setLoading(false);
      }
    };

    fetchProducts();
  }, []);

  return (
    <div>
      <h1>Products (Client-rendered)</h1>
      {loading ? (
        <p>Loading products...</p>
      ) : (
        <ul>
          {products.map(product => (
            <li key={product.id}>{product.name}</li>
          ))}
        </ul>
      )}
    </div>
  );
};

export default ClientProductsPage;

Using App Router:

// app/client-products/page.tsx
import ProductList from "./ProductList";

export default function ClientProductsPage() {
  return (
    <div>
      <h1>Products (Client-rendered)</h1>
      <ProductList />
    </div>
  );
}

// app/client-products/ProductList.tsx
("use client");

import { useState, useEffect } from "react";

export default function ProductList() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchProducts = async () => {
      try {
        const res = await fetch("/api/products");
        const data = await res.json();
        setProducts(data);
      } catch (error) {
        console.error("Failed to fetch products:", error);
      } finally {
        setLoading(false);
      }
    };

    fetchProducts();
  }, []);

  return (
    <>
      {loading ? (
        <p>Loading products...</p>
      ) : (
        <ul>
          {products.map(product => (
            <li key={product.id}>{product.name}</li>
          ))}
        </ul>
      )}
    </>
  );
}

Hybrid Approaches

In the real world, the best solutions often combine both rendering approaches. Next.js excels at providing flexible options that let you optimize each page or component individually.

Selective Hydration

With React 18 and Next.js App Router, you can leverage selective hydration to prioritize critical interactive elements:

// app/dashboard/page.tsx
import { Suspense } from "react";
import StaticContent from "./StaticContent";
import InteractiveWidget from "./InteractiveWidget";
import LazyLoadedSection from "./LazyLoadedSection";

export default function Dashboard() {
  return (
    <div className="dashboard">
      {/* Server rendered static content */}
      <StaticContent />

      {/* Prioritized interactive element */}
      <Suspense fallback={<div>Loading widget...</div>}>
        <InteractiveWidget />
      </Suspense>

      {/* Deferred loading of less critical content */}
      <Suspense fallback={<div>Loading additional content...</div>}>
        <LazyLoadedSection />
      </Suspense>
    </div>
  );
}

Progressive Hydration Pattern

For complex UIs, consider progressive hydration where parts of the page become interactive in stages:

// components/ProgressivelyHydratedPage.tsx
"use client";

import { useState, useEffect } from "react";
import { useInView } from "react-intersection-observer";
import StaticContent from "./StaticContent";
import InteractiveHeader from "./InteractiveHeader";
import HeavyInteractiveSection from "./HeavyInteractiveSection";

export default function ProgressivelyHydratedPage() {
  // Header hydrates immediately
  const [headerHydrated, setHeaderHydrated] = useState(false);

  // Heavy section hydrates when scrolled into view
  const { ref, inView } = useInView({
    triggerOnce: true,
    threshold: 0.1,
  });

  // Immediate hydration for critical UI
  useEffect(() => {
    setHeaderHydrated(true);
  }, []);

  return (
    <div className="progressive-page">
      <InteractiveHeader hydrated={headerHydrated} />

      <StaticContent />

      <div ref={ref}>
        {inView ? (
          <HeavyInteractiveSection />
        ) : (
          <div className="placeholder">Loading interactive content...</div>
        )}
      </div>
    </div>
  );
}

Real-world Decision Framework

1. Content-focused sites (blogs, marketing pages, documentation)

   • Primary approach: SSR or Static Generation
   • Benefits: SEO, performance, content accessibility
   • Example: Our company blog saw a 72% improvement in organic traffic after switching from CSR to SSR

2. Highly interactive applications (dashboards, tools, editors)

   • Primary approach: CSR with SSR shell
   • Benefits: Better interactivity, reduced server load for active users
   • Example: Our analytics dashboard uses SSR for the initial shell but CSR for interactive charts

3. E-commerce and conversion-focused sites

   • Primary approach: SSR with selective CSR for interactive elements
   • Benefits: Fast initial load for SEO, interactive elements for conversion
   • Example: Product listing pages use SSR, while the shopping cart is CSR

4. Authentication-required applications

   • Primary approach: CSR with API routes for data
   • Benefits: Better security model, reduced server complexity
   • Example: Our admin portals use CSR with JWTs for authentication

Performance Benchmarks

I’ve run extensive performance tests on identical applications built with both rendering approaches. Here are typical metrics from a mid-complexity application:

These numbers will vary based on application complexity, but the pattern is clear: SSR provides faster visual content but CSR can achieve faster interactivity with lower server resources.

Common Pitfalls and Solutions

SSR Pitfalls

1. Hydration Mismatch Errors

   • Problem: Server and client rendering produce different output
   • Solution: Ensure consistent rendering conditions between server and client

   // Use useEffect for client-only code
   const [isMounted, setIsMounted] = useState(false);
   useEffect(() => setIsMounted(true), []);
   
   return (
     <div>{isMounted ? <ClientOnlyComponent /> : <FallbackPreview />}</div>
   );

2. Slow API Dependencies

   • Problem: Server rendering blocked by slow external APIs
   • Solution: Use parallel data fetching, timeouts, and fallbacks

   // Parallel data fetching with Promise.all
   export const getServerSideProps = async () => {
     try {
       const results = await Promise.all([
         fetch("https://api1.example.com").then(r => r.json()),
         fetch("https://api2.example.com").then(r => r.json()),
       ]);
   
       return { props: { data1: results[0], data2: results[1] } };
     } catch (error) {
       // Provide fallback data if APIs fail
       return {
         props: {
           data1: defaultData1,
           data2: defaultData2,
           error: true,
         },
       };
     }
   };

3. High Server Load

   • Problem: Excessive server resources for high-traffic sites
   • Solution: Implement caching strategies, CDN integration, and edge rendering

   // In Next.js App Router
   async function getData() {
     const res = await fetch("https://api.example.com/data", {
       next: { revalidate: 60 }, // Cache for 60 seconds
     });
     return res.json();
   }

CSR Pitfalls

1. SEO Issues

   • Problem: Content not visible to search engines
   • Solution: Implement SSR for critical landing pages, use dynamic rendering for bots

   // Detect search engine bots and serve pre-rendered content
   export const getServerSideProps = async ({ req }) => {
     const userAgent = req.headers["user-agent"] || "";
     const isBot = /bot|googlebot|crawler|spider|robot|crawling/i.test(
       userAgent
     );
   
     return {
       props: {
         // Pre-render for bots, client-render for users
         renderStrategy: isBot ? "prerender" : "client",
       },
     };
   };

2. Poor Loading Experience

   • Problem: Blank page while JavaScript loads
   • Solution: Implement skeleton screens, progressive loading, and optimistic UI

   // Skeleton loading example
   function ProductPageSkeleton() {
     return (
       <div className="product-skeleton">
         <div className="skeleton-image"></div>
         <div className="skeleton-title"></div>
         <div className="skeleton-price"></div>
         <div className="skeleton-description"></div>
       </div>
     );
   }

3. Large Bundle Sizes

   • Problem: Slow initial load due to large JavaScript bundles
   • Solution: Implement code splitting, lazy loading, and tree shaking

   // Dynamic import for code splitting
   import dynamic from "next/dynamic";
   
   const HeavyComponent = dynamic(
     () => import("../components/HeavyComponent"),
     {
       loading: () => <p>Loading...</p>,
       ssr: false, // Skip SSR for this component
     }
   );

Strategic Recommendations

Based on extensive experience with Next.js in production, here are my strategic recommendations:

1. Start with SSR by default for most public-facing pages
2. Implement CSR for highly interactive sections within those pages
3. Use static generation wherever possible for best performance
4. Leverage incremental static regeneration for dynamic content that doesn’t change on every request
5. Implement proper loading states for all CSR components
6. Use React Suspense and streaming in the App Router for progressive loading
7. Measure and optimize Core Web Vitals for both approaches

Future Trends in Next.js Rendering

The future of rendering in Next.js is evolving rapidly:

1. React Server Components are transforming the rendering paradigm
2. Streaming rendering allows for more granular content delivery
3. Edge rendering brings computation closer to users
4. Partial hydration reduces client-side JavaScript footprint
5. Islands architecture combines benefits of both approaches

As of 2025, the latest Next.js versions are making these distinctions increasingly fluid, with more granular control over rendering strategies at the component level rather than the page level.

Conclusion

The choice between SSR and CSR in Next.js isn’t binary – it’s a spectrum of options that can be mixed and matched based on your specific requirements. The best applications leverage both approaches strategically:

• SSR for critical landing pages, SEO content, and initial shells
• CSR for highly interactive sections, personalized content, and frequent updates
• Static Generation for truly static content
• Incremental Static Regeneration for semi-dynamic content

By understanding the tradeoffs and implementation patterns outlined in this article, you can build Next.js applications that are fast, SEO-friendly, and provide excellent user experiences.

Remember, the best rendering strategy is the one that serves your users’ needs while meeting your business requirements – there is no one-size-fits-all solution.

Happy rendering! Code with passion, create with purpose!