Phase 4: Full-Stack Integration

SSR vs. SSG vs. ISR: trade-offs & use cases

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re going to a restaurant, not for food, but to get a webpage delivered to your screen. How fast you get that page, and how fresh the information on it is, depends a lot on how the restaurant (or computer server) prepares it for you. There are a few different ways, like ordering a custom meal, grabbing something pre-made, or getting a pre-made meal that's regularly refreshed.

First, there's SSR (which stands for Server-Side Rendering). This is like ordering a meal totally from scratch. When you ask for a page, the computer server gathers all the latest ingredients (information), cooks the whole page just for you, and then serves it up. It takes a little longer because it’s made fresh every single time, but it’s perfect if you need super-current information, like your personal high score on a game, or if the page needs to show something different for every single person who looks at it.

Then we have SSG (which stands for Static Site Generation). This is like a really smart deli that makes a huge batch of its most popular sandwiches and salads ahead of time. When you walk in and ask for one, it's already perfectly made, wrapped up, and waiting for you. You just grab it and go! It’s super, super fast because the computer isn’t cooking anything new; it’s just handing you something that’s already finished. This works great for pages that don't change often, like a story on a blog or the "about us" page.

Finally, there's ISR (Incremental Static Regeneration). This is like that same smart deli, but instead of making a giant batch and never checking it again, they have a clever system. They still make all the popular sandwiches ahead of time (like SSG), so they’re super fast to grab. But every few hours, or when something specific changes, a chef quickly refreshes just that one sandwich or just that one type of salad without remaking everything else. So you still get your meal really fast, but it’s much fresher. When you're thinking about how a website should work, you get to choose which "cooking method" is best for each part. This means you can make sure a page about today's weather is always fresh and made-to-order, while a page explaining the rules of a game is super fast because it's already waiting for you.

As a full-stack developer, understanding how your application serves content is critical for performance, SEO, and user experience. SSR (Server-Side Rendering), SSG (Static Site Generation), and ISR (Incremental Static Regeneration) are three powerful pre-rendering strategies, each with distinct trade-offs. SSR processes each page request on the server, fetching data and rendering the HTML before sending it to the client. This ensures the content is always fresh and personalized, ideal for highly dynamic or authenticated pages, but it incurs a per-request server cost and potentially slower Time To First Byte (TTFB) due to the on-demand rendering.

SSG, in contrast, builds all pages into static HTML, CSS, and JavaScript files at build time. These pre-built files can then be served incredibly fast from a CDN, offering superior performance, SEO, and reduced server load. This approach is perfect for content that doesn't change often, like marketing sites, blogs, or documentation. The main trade-off is data freshness; any content updates require a full rebuild and redeployment of the site. Choosing between SSR and SSG boils down to the dynamism of your content versus the need for ultimate speed and scalability via CDNs.

ISR offers a clever hybrid solution, combining the best aspects of SSG and SSR. It allows you to generate pages at build time (like SSG) but also revalidate and regenerate them in the background at specified intervals or on demand, without requiring a full site rebuild. This provides the speed benefits of SSG while ensuring content remains reasonably fresh (eventually consistent). ISR is ideal for pages with frequently updated, but not real-time critical, content such as news articles or product listings where slight data staleness is acceptable. Your decision hinges on balancing data freshness, site performance, and the complexity of your content management workflow.

Key Takeaways

  • SSR prioritizes real-time data and personalization, but with higher server load and TTFB.
  • SSG maximizes performance, SEO, and CDN utilization for static or rarely changing content.
  • ISR balances SSG's speed with eventual data freshness, avoiding full rebuilds for updates.
  • Choose your strategy based on content dynamism, user experience goals (TTFB), and deployment needs.

Code Example

typescript
Preview

How this code works

This code efficiently creates individual post pages for a blog, combining the benefits of pre-rendering for speed with dynamic updates for freshness. During the build process, getStaticPaths first determines all known post URLs by fetching slugs from an API. It then tells Next.js which pages to pre-render, ensuring they're ready instantly. For each pre-rendered page, getStaticProps fetches the actual post content using its params.slug and passes it to the PostPage component. If a post isn't found, it returns notFound: true.

The revalidate: 60 option in getStaticProps is key for Incremental Static Regeneration (ISR). It ensures that Next.js will rebuild a page in the background (no more than once every 60 seconds) if a user requests it, keeping content fresh without a full site rebuild. A subtle but powerful choice is fallback: 'blocking'. If a user requests a post that wasn't known at build time (e.g., a newly published one), Next.js won't show an error. Instead, it will wait (blocking) for getStaticProps to fetch the new post data, generate the page, then serve it and cache it for future requests, effectively adding new pages dynamically after the initial build.

Resources

Related Articles

Hand-picked reads to go deeper on ssr & ssg with next.js / astro.

Back to Full-Stack Developer Roadmap