Nuxt Hybrid Rendering: Balancing SSG and SSR for Cost Optimization

Execution of Server-Middleware in Hybrid Rendering

In a Nuxt 3 hybrid configuration, server-middleware execution depends entirely on whether the route is served as a static asset or processed by the Nitro engine at runtime.

Static Routes (prerender)

When a route is marked for prerender, Nuxt executes the server-side logic—including Nitro plugins and server-middleware—only during the build process. The resulting HTML is saved as a static file. At runtime, the serverless provider serves this static file directly from the edge or storage. Consequently, server-middleware does not execute when a user requests a pre-rendered page, as the request never reaches the Nitro runtime.

Dynamic Routes (ssr)

Routes defined with ssr: true (or those not pre-rendered) trigger the full Nitro runtime on every request. In this scenario, all registered server-middleware and plugins execute normally for each request.

Cold-Start Latency Implications

Transitioning from a pre-rendered page to a dynamic SSR route in a serverless environment introduces a potential performance cliff known as the cold start.

• Static Page Access: The user experiences near-instant load times because the request is handled by the CDN/Static host without invoking a compute function.
• Dynamic Page Access: If the serverless function has scaled to zero, the first request to an SSR route must initialize the Nitro runtime, load plugins, and establish database connections. This creates a noticeable latency spike compared to the static experience.

Implementation Steps for Cost Optimization

To balance cost and performance, configure your nuxt.config.ts as follows:

export default defineNuxtConfig({
  routeRules: {
    // Static: Zero runtime cost, no server-middleware at request time
    '/': { prerender: true },
    '/about': { prerender: true },
    // Dynamic: Full runtime cost, executes server-middleware
    '/dashboard/**': { ssr: true },
    // Hybrid: Cached but updated in background
    '/blog/**': { swr: 3600 }
  }
})

Verification Process

1. Build Audit: After running npm run build, check the .output/public directory. If a route appears as an index.html file, it is static and will bypass runtime middleware.
2. Header Check: Use browser DevTools to inspect the response headers of your dynamic routes. Look for provider-specific headers (e.g., x-vercel-cache or x-netlify-cache) to confirm if the page is being served from cache or triggering a fresh SSR execution.

Missing Diagnostic Detail: Which serverless provider are you using? (Behavior regarding edge-caching and function wake-up times varies significantly between Vercel, Netlify, and AWS Lambda).