SSR And Prerendering · Additional notes

2 min read
Senior4 min read
Rapid overview

Additional notes

When to Use SSR/Pre-rendering

Potentially Useful For:

  • Content-heavy sites requiring SEO (blogs, news, documentation)
  • Marketing landing pages
  • E-commerce product pages
  • Sites with mostly static content

Often Not Worth It For:

  • Internal dashboards and admin panels
  • Applications behind authentication
  • Highly dynamic real-time applications
  • Small teams without dedicated infrastructure resources
  • Applications where SEO is not critical

Detailed Comparison

SSR vs Client-Side Rendering

AspectSSRClient-Side Rendering
First PaintFaster (HTML ready)Slower (wait for JS)
Time to InteractiveSlower (hydration needed)When JS loads
Server CostHigher (compute per request)Minimal (static hosting)
ComplexityHigherLower
CachingDifficultEasy (everything static)
PersonalizationComplexNatural
Development SpeedSlowerFaster
DebuggingHarder (server + client)Easier (client only)

SSR vs Static Site Generation (SSG)

AspectSSRSSG
Build TimeNormalLonger (pre-generates pages)
Content FreshnessReal-timeStale until rebuild
ScalabilityLimited by serversUnlimited (CDN)
CostPer-requestPer-build
Dynamic ContentSupportedLimited

Alternatives to Consider

1. Client-Side Rendering with Proper SEO Tags

<!-- Even SPAs can have good SEO with proper meta tags -->
<!DOCTYPE html>
<html lang="en">
<head>
  <title>Product Name - Store</title>
  <meta name="description" content="Product description here">
  <meta property="og:title" content="Product Name">
  <meta property="og:image" content="/product-image.jpg">
  <link rel="canonical" href="https://store.com/products/123">
</head>
<body>
  <div id="root"></div>
  <script src="/app.js"></script>
</body>
</html>

2. Incremental Static Regeneration (ISR)

// Next.js ISR - best of both worlds
export async function getStaticProps() {
  const products = await getProducts();

  return {
    props: { products },
    revalidate: 60 // Regenerate at most every 60 seconds
  };
}

// Page is static, but updates periodically

Benefits:

  • Static performance
  • Eventually fresh content
  • No per-request server cost

3. Edge-Side Rendering

// Cloudflare Workers / Vercel Edge
export const config = {
  runtime: 'edge' // Runs at CDN edge, not origin
};

export default async function handler(request) {
  // Lightweight rendering at edge
  // Lower latency than origin SSR
}

4. Hybrid Approach

// Static shell with dynamic islands
function ProductPage({ staticProduct }) {
  return (
    <div>
      {/* Static content - rendered at build time */}
      <ProductInfo product={staticProduct} />

      {/* Dynamic island - client-side only */}
      <ClientOnly>
        <LiveInventory productId={staticProduct.id} />
        <PersonalizedRecommendations />
      </ClientOnly>
    </div>
  );
}

Google's Actual Crawling Capabilities

Modern search engines can crawl JavaScript:

// Google's rendering capabilities (2024+):
// - Full JavaScript execution
// - Waits for dynamic content
// - Understands SPAs
// - Follows client-side routing

// However, there may be delays:
// 1. Initial crawl: HTML only
// 2. Render queue: JavaScript execution (can take days)
// 3. Re-index: Updated content reflected

What actually matters for SEO:

  • Proper meta tags and structured data
  • Fast load times (Core Web Vitals)
  • Mobile responsiveness
  • Good content and link structure
  • Proper sitemap and robots.txt

Questions to Ask Before Implementing SSR

  1. Is SEO actually critical for this application?
  • Internal tools: No
  • Marketing sites: Yes
  • Authenticated apps: Usually no
  1. Do you have the infrastructure expertise?
  • Server management
  • Scaling strategies
  • Monitoring and debugging
  1. What's the cost-benefit analysis?
  • Development time added
  • Infrastructure costs
  • Maintenance burden
  • vs. SEO benefit
  1. Have you tried alternatives first?
  • Static meta tags
  • Sitemap submission
  • Structured data
  • Core Web Vitals optimization

See also