ISR vs SSG vs SSR — When to Use Each Rendering Strategy

In this tutorial, you will learn about ISR vs SSG vs SSR. We cover key concepts, practical examples, and best practices to help you master this topic.

ISR, SSG, and SSR each trade off between freshness and speed. ISR balances both by serving cached pages while regenerating content in the background.

What You'll Learn

By the end of this tutorial, you'll understand the key differences between ISR, SSG, and SSR, know the tradeoffs each makes, and be able to choose the right Strategy for any page type.

Why It Matters

Using the wrong rendering strategy makes pages slow, expensive, or stale. Understanding the ISR vs SSG vs SSR spectrum helps you optimize for both performance and content freshness where each matters most.

Real-World Use

A news site uses all three: evergreen articles use SSG (fastest, never changes), the homepage uses ISR (fast but updates every 60 seconds), and the live blog uses SSR (instant updates, no Caching).

Rendering Spectrum

graph TD
    A[Rendering Strategies] --> B[SSG]
    A --> C[ISR]
    A --> D[SSR]
    B --> E[Content: Static
Speed: Fastest
Freshness: Rebuild only]
    C --> F[Content: Periodic update
Speed: Fast
Freshness: Revalidate window]
    D --> G[Content: Real-time
Speed: Slower
Freshness: Always fresh]
    E --> H[Blogs, docs, marketing]
    F --> I[E-commerce, news, CMS]
    G --> J[Dashboards, user data, live]
    style B fill:#27ae60,color:#fff
    style C fill:#f39c12,color:#fff
    style D fill:#e74c3c,color:#fff

Performance Comparison

// SSG — Fully static, no server
const ssgMetrics = {
    ttfb: '50-100ms (CDN)',
    serverLoad: 'None',
    contentFreshness: 'At build time',
    buildFrequency: 'On content change',
    cost: 'Lowest (static hosting)',
    useWhen: 'Content changes infrequently'
};

// ISR — Static with background updates
const isrMetrics = {
    ttfb: '50-100ms (CDN, cached)',
    serverLoad: 'Low (revalidation only)',
    contentFreshness: 'Within revalidate window',
    buildFrequency: 'Per-page on demand',
    cost: 'Medium (server + CDN)',
    useWhen: 'Content updates periodically'
};

// SSR — Fully dynamic
const srrMetrics = {
    ttfb: '200-1000ms (server)',
    serverLoad: 'Per request',
    contentFreshness: 'Always real-time',
    buildFrequency: 'None (no build needed)',
    cost: 'Highest (server compute)',
    useWhen: 'User-specific or real-time data'
};

Implementation Comparison

// SSG: getStaticProps — Build time only
export async function getStaticProps_SSG() {
    const data = await fetchData();
    return {
        props: { data }
        // No revalidate — purely static
    };
}

// ISR: getStaticProps + revalidate
export async function getStaticProps_ISR() {
    const data = await fetchData();
    return {
        props: { data, time: Date.now() },
        revalidate: 60 // Refresh in background
    };
}

// SSR: getServerSideProps — Every request
export async function getServerSideProps_SSR() {
    const data = await fetchData();
    return {
        props: { data, time: Date.now() }
        // Runs on every request
    };
}

When to Use Each

const decisionMatrix = {
    'Blog post': {
        recommendation: 'SSG',
        reason: 'Content rarely changes after publish',
        revalidateValue: null
    },
    'E-commerce product page': {
        recommendation: 'ISR',
        reason: 'Prices and inventory change, but not constantly',
        revalidateValue: 60
    },
    'User dashboard': {
        recommendation: 'SSR',
        reason: 'Content is personalized per user',
        revalidateValue: null
    },
    'News homepage': {
        recommendation: 'ISR',
        reason: 'Updates frequently but can handle slight delay',
        revalidateValue: 30
    },
    'Documentation': {
        recommendation: 'SSG',
        reason: 'Changes only on new releases',
        revalidateValue: null
    },
    'Live sports scores': {
        recommendation: 'SSR',
        reason: 'Must show current data instantly',
        revalidateValue: null
    }
};

Common Mistakes

1. Using SSG for content that updates regularly. If your data changes every hour but you rebuild once a day, users see stale content for hours. Use ISR.
2. Using SSR for content that doesn't change per request. A blog post is the same for all users. SSG or ISR is faster and cheaper.
3. Setting ISR revalidate too low (1-5 seconds). This defeats the purpose of ISR. Visitors still get cached pages, but the server is constantly re-rendering. Use 30-300 seconds.
4. Not considering user-specific content. ISR and SSG produce the same HTML for everyone. If pages differ per user (dashboards, profiles), use SSR.
5. Using SSR without CDN caching. SSR without caching is slow. Add Cache-Control headers and a CDN layer to improve SSR performance.

Practice Questions

1. What tradeoff does ISR make between SSG and SSR?
2. When would you choose ISR over SSG for a content page?
3. When would you choose SSR over ISR for a product page?
4. What are the cost implications of each strategy?
5. Can you mix all three strategies in a single application?

Challenge: Create a comparison dashboard that shows the same data rendered with SSG, ISR, and SSR. Display the generation timestamp, load time, and content age for each version. Analyze the tradeoffs.

FAQ

Mini Project

Build a weather dashboard that uses all three strategies: a 7-day forecast page (SSG, pre-built daily), a current conditions page (ISR, revalidate every 5 minutes), and a radar map page (SSR, real-time data). Compare the TTFB of each.

What's Next

Now learn how to implement Next.js revalidate in detail, including time-based revalidation configuration and best practices.