Choosing Between SSR and SSG in Nuxt for Content-Heavy Sites

The Content Freshness vs. Load Speed Dilemma

When building a content-heavy application in Nuxt, you eventually hit a wall: do you render the page every time a user asks for it, or do you build every single page once and serve them as static files? Choosing the wrong strategy leads to either a sluggish user experience (slow TTFB) or a nightmare build process that takes an hour every time you fix a typo.

The core decision rests on how often your data changes and how many pages you have. If you have 10,000 product pages that update once a week, rendering them on every request is a waste of server resources. If you have a live news feed, static generation will leave your users seeing outdated headlines.

Server-Side Rendering (SSR): The Dynamic Approach

In SSR mode, Nuxt renders the HTML on the server for every single request. This is the "Universal" mode. The server fetches the data, populates the Vue components, and sends a complete HTML string to the browser.

• Best for: Personalized dashboards, real-time marketplaces, or sites with massive catalogs where build times would be prohibitive.
• The Trade-off: Higher server load and a slightly slower Time to First Byte (TTFB) because the server must do work before sending the response.

Static Site Generation (SSG): The Performance Play

SSG pre-renders your entire application into static HTML files during the build process. These files are then deployed to a CDN (Content Delivery Network), meaning the server doesn't "think" when a request comes in; it simply hands over a file.

• Best for: Documentation, blogs, and marketing sites where content changes infrequently.
• The Trade-off: Build times scale linearly with the number of pages. If you have 5,000 pages, nuxt generate can become a bottleneck in your CI/CD pipeline.

Hybrid Rendering with Route Rules

Modern Nuxt versions allow you to stop treating this as a binary choice. Using Route Rules, you can mix strategies. You can keep your landing page static for speed, but keep your user profile pages dynamic for accuracy.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    // Static generation for the home page
    '/': { prerender: true },
    // SWR (Stale-While-Revalidate): Cache for 1 hour, then update in background
    '/blog/**': { swr: 3600 },
    // Fully dynamic SSR for user accounts
    '/account/**': { ssr: true }
  }
})

Avoiding the Hydration Mismatch

Regardless of the mode, Nuxt performs Hydration. This is the process where the client-side Vue application "wakes up" and takes over the static HTML delivered by the server to make it interactive.

A common failure occurs when the server renders one thing and the client renders another. For example, using new Date() or window.innerWidth directly in your setup script will cause a mismatch because the server has no window object and a different system clock than the user's browser.

To prevent this: Wrap browser-only logic in onMounted() or use the component.

Practical Verification

To verify which mode your application is actually using, follow these steps:

1. Check the Config: Look for the ssr flag in nuxt.config.ts. If it is false, you are using a Client-Side Only (SPA) approach.
2. Inspect the Network: Open Browser DevTools > Network tab. Refresh the page and click the first request. If the "Response" tab shows a full HTML document with your content already inside, SSR or SSG is working. If it shows an empty <div id="__nuxt">, it is a client-side render.
3. Verify Build Output: Run npm run generate. Check the .output/public directory. If you see index.html and folders for every route, you have successfully generated a static site.

Limitations and Risks

Metric	SSR	SSG
Build Time	Fast (no pre-rendering)	Slow (scales with pages)
TTFB	Moderate (server processing)	Instant (CDN edge)
Data Freshness	Real-time	Build-time (unless using SWR)

Rollback Strategy: If you switch from SSG to SSR and encounter server crashes due to memory limits, revert the routeRules or ssr flag in nuxt.config.ts and redeploy. Since this is a configuration change, it does not alter your database state, only how the frontend is delivered.