SSR vs SSG: Choosing the Right Rendering for Dynamic Dashboards vs Static Blogs

Direct answer

Use SSR for user‑specific dashboards and SSG for blogs or marketing pages. In Nuxt 3, when both /blog and /blog/* exist, the static /blog route is expected to take precedence over the catch‑all. Cache headers on SSR responses are not applied automatically; you must configure them explicitly through routeRules or server middleware.

Confirmed behavior vs. items to verify

Well‑established: Nuxt 3 supports hybrid rendering via routeRules, allowing per‑route control of SSR, prerendering, and headers. SSG emits static HTML at build time, while SSR renders on each request. The X-Nuxt-Server-Rendered response header is a reliable signal for distinguishing server‑rendered from prerendered output.

Likely but version‑dependent: The file‑based router resolves concrete path segments before wildcard segments, so /blog wins over /blog/*. Routing internals can shift between minor releases, so confirm this in your exact Nuxt 3 version before relying on it in production.

Recommended configuration for this case

export default defineNuxtConfig({
  routeRules: {
    // Dashboard: fresh, per‑request data
    '/dashboard': { ssr: true },
    '/dashboard/**': { ssr: true },
    // Blog: pre‑rendered, CDN‑friendly
    '/blog': { prerender: true },
    '/blog/**': { prerender: true },
    // Explicit cache control for SSR endpoints
    '/api/**': { headers: { 'Cache-Control': 'no-store' } }
  }
})

If the dashboard data is identical for every user, swr or ISR‑style revalidation could reduce server load. If it is personalized, stick with ssr: true and suppress shared‑cache storage.

Route precedence and navigation impact

Because /blog is more specific, requests to /blog should resolve to pages/blog.vue rather than pages/blog/[...slug].vue. A catch‑all can still shadow deeper nested static routes if those files are placed inside the same dynamic directory. Keep static pages as siblings, not children, of the catch‑all folder, or test resolution after every structural change.

Cache‑header strategy

Verification steps

1. Run nuxi dev (or build and preview) and request /blog; confirm it renders the static page, not the catch‑all.
2. Inspect response headers in DevTools or via a local HTTP client for X-Nuxt-Server-Rendered and your custom Cache-Control values.
3. Deploy to a staging environment and repeat the header inspection, because hosting providers may inject or override cache directives.

One missing detail that changes the recommendation

Are you deploying to a long‑running Node server, an edge runtime, or a fully static host? Edge and static targets may restrict routeRules behavior or header manipulation, which affects whether SSR is viable for the dashboard or whether you need a separate API layer.