Matching Static Dynamic Patterns Nuxt 3

Master Nuxt 3's hybrid rendering to combine static and dynamic routes for optimal performance. Learn route rules, cache strategies, and implementation patterns.

Understanding Nuxt 3 Rendering Modes

Modern web applications often require a mix of rendering strategies. Some pages benefit from pre-rendering for maximum performance, while others need server-side rendering to deliver personalized or frequently changing content. Nuxt 3's hybrid rendering capabilities allow you to match different rendering patterns to specific routes, giving you granular control over how each part of your application is rendered.

This guide explores how to effectively match static and dynamic patterns in Nuxt 3, leveraging the framework's powerful route rules system to optimize performance, reduce server load, and deliver exceptional user experiences. Whether you're building a marketing website, e-commerce platform, or SaaS dashboard, understanding these patterns is essential for creating high-performance web applications.

Universal rendering, also known as server-side rendering (SSR), generates HTML on the server for each request. The server processes the page, fetches data, and sends fully rendered HTML to the browser. After the initial load, Vue takes over for client-side hydration.

Best for: Dashboards, user-specific content, real-time information displays.

Trade-off: Higher server resource usage since each request triggers rendering work.

Configuring Route Rules in Nuxt 3

Nuxt 3's route rules system provides declarative configuration for controlling rendering behavior on a per-route basis. These rules are defined in the nuxt.config.ts file under the routeRules key, offering a powerful yet simple syntax for specifying rendering strategies.

Basic Syntax

The routeRules object maps URL patterns to rendering configurations. You can use string patterns for exact matches, glob patterns for flexible matching, and even group routes with similar requirements.

export default defineNuxtConfig({
 routeRules: {
 // Static pre-rendered routes
 '/': { prerender: true },
 '/about': { prerender: true },

 // Server-side rendered routes
 '/dashboard/**': { ssr: true },

 // Client-side rendered routes
 '/admin/**': { ssr: false },

 // Stale-while-revalidate with cache
 '/blog/**': { swr: 3600 },

 // Incremental Static Regeneration
 '/products/**': { isr: 7200 }
 }
})

Route Rule Options

Each route rule supports several options:

  • prerender: Boolean or number. Pre-renders routes at build time.
  • ssr: Boolean. Controls server-side rendering.
  • swr: Number (seconds). Stale-while-revalidate caching.
  • isr: Number (seconds). Incremental Static Regeneration.
Route Rule Options Explained

Prerender

Generates static HTML at build time. Use for content that rarely changes and needs maximum performance.

SSR

Server-side rendering for each request. Essential for SEO-critical pages requiring fresh data.

SWR

Serves cached content immediately while regenerating in background. Balances performance with freshness.

ISR

Incremental Static Regeneration generates pages on-demand and caches at edge for optimal delivery.

Matching Static Routes

Static routes represent content that doesn't change frequently and benefits from pre-rendering. Identifying which routes qualify for static generation requires analyzing content update patterns and performance requirements.

Identifying Static Content

Content suitable for static pre-rendering exhibits predictable characteristics:

  • Infrequent updates: Changes happen on defined schedules rather than continuously
  • High traffic: Justifies the build-time investment since static pages serve instantly
  • SEO requirements: Pre-rendered HTML is easily crawled and indexed by search engines

Static Route Candidates

Typical static route candidates include:

  • Homepage and landing pages
  • About and company information pages
  • Product and service descriptions
  • Documentation and help center content
  • Archived blog posts or articles

Configuring Static Route Patterns

When configuring static routes, pattern matching helps group multiple routes efficiently:

routeRules: {
 // Exact route matches
 '/': { prerender: true },
 '/about': { prerender: true },

 // Path prefix matching
 '/docs/**': { prerender: true },

 // Complex glob patterns
 '/{blog,guides,tutorials}/**': { prerender: true }
}

The pattern matching system handles both simple prefix matches and complex expressions, allowing you to configure entire sections with single rules rather than listing every individual route.

For SEO optimization, static pre-rendering provides the fastest possible page loads and ensures search engines can easily index your content.

Matching Dynamic Routes

Dynamic routes handle content that changes frequently, requires personalization, or depends on real-time data. These routes benefit from server-side rendering or client-side rendering strategies depending on their specific requirements.

Identifying Dynamic Content

Dynamic content characteristics include:

  • Frequent updates: Information changes continuously or near-continuously
  • Personalization: User-specific data that cannot be pre-generated
  • Real-time elements: Live data from external APIs or user interactions
  • Authentication dependence: Content visibility or behavior varies based on user state

Dynamic Route Candidates

Typical dynamic route candidates include:

  • User dashboards and account pages
  • Shopping carts and checkout flows
  • Search results pages
  • Live data displays and dashboards
  • Personalized recommendations

Server-Side Rendering for Dynamic Routes

Server-side rendering provides fresh data on every request while maintaining SEO-friendly HTML output:

routeRules: {
 // User-specific content requiring fresh data
 '/dashboard/**': { ssr: true },
 '/account/**': { ssr: true },

 // Search results with current data
 '/search/**': { ssr: true }
}

When these routes receive requests, Nuxt generates fresh HTML on the server, incorporating current data from your sources. Users always see up-to-date information while benefiting from SSR's SEO advantages.

Client-Side Rendering for Dynamic Routes

Some dynamic routes don't require server-side rendering and can rely entirely on client-side JavaScript:

routeRules: {
 // Internal tools without SEO requirements
 '/admin/**': { ssr: false },

 // Interactive applications
 '/editor/**': { ssr: false }
}

Routes configured with ssr: false receive minimal server processing. The server delivers the Nuxt application shell, and client-side JavaScript handles data fetching and interactivity. This pattern works well for authenticated admin areas and highly interactive applications that may integrate with AI automation workflows.

Implementing Cache Strategies

Cache strategies bridge static and dynamic approaches, providing the performance benefits of static content while maintaining freshness through intelligent regeneration.

Stale-While-Revalidate (SWR)

The stale-while-revalidate strategy serves cached content immediately while regenerating the page in the background for future requests. Users always receive fast responses, even if content is slightly stale:

routeRules: {
 // Blog posts with 1-hour cache
 '/blog/**': { swr: 3600 },

 // Documentation with 24-hour cache
 '/docs/**': { swr: 86400 },

 // Product listings with 30-minute cache
 '/products/**': { swr: 1800 }
}

The SWR approach excels for content that changes occasionally but not continuously. Blog posts, documentation, and product catalogs benefit from this pattern since slightly stale content rarely causes problems while the performance improvement significantly enhances user experience.

Incremental Static Regeneration (ISR)

ISR provides similar benefits to SWR with slightly different semantics. It generates static pages on-demand and caches them at the edge, combining static performance with dynamic capabilities:

routeRules: {
 // E-commerce product pages
 '/product/**': { isr: 3600 },

 // Category pages
 '/category/**': { isr: 7200 }
}

ISR proves particularly valuable for e-commerce applications where product pages need excellent performance but product data changes regularly. Regeneration happens on-demand after cache expiration, ensuring content stays current without requiring full site rebuilds.

Choosing Between SWR and ISR

FactorSWRISR
Popularity variationBetter for variable trafficBetter for consistent high traffic
Regeneration efficiencyMultiple regenerations possibleSingle regeneration per period
Platform supportUniversalPlatform-specific
Use caseContent with moderate update frequencyHigh-traffic e-commerce, large catalogs

Practical Pattern Examples

Real-world applications often combine multiple strategies to optimize different sections. Examining common patterns helps inform your own architectural decisions.

Marketing Website Pattern

Marketing websites typically combine pre-rendered landing pages with cached content sections and dynamic forms:

routeRules: {
 // Static marketing pages
 '/': { prerender: true },
 '/features': { prerender: true },
 '/pricing': { prerender: true },

 // Cached blog content
 '/blog/**': { swr: 3600 },
 '/case-studies/**': { swr: 86400 },

 // Dynamic forms and search
 '/contact': { ssr: true },
 '/search': { ssr: true }
}

This configuration ensures marketing pages load instantly from static hosting, blog content refreshes hourly while remaining fast, and interactive sections like contact forms and search receive fresh rendering for proper functionality.

E-Commerce Application Pattern

E-commerce platforms balance product performance with inventory accuracy through strategic caching:

routeRules: {
 // Static category and collection pages
 '/shop/**': { swr: 1800 },

 // Product pages with inventory checks
 '/product/**': { isr: 900 },

 // User-specific routes
 '/cart': { ssr: false },
 '/checkout/**': { ssr: false },
 '/account/**': { ssr: false }
}

Product pages use ISR with short cache duration to balance performance with inventory accuracy. User-specific routes avoid server rendering entirely since authentication and personalization happen client-side. Category pages leverage SWR for reasonable freshness without constant regeneration.

SaaS Dashboard Pattern

Software-as-a-service applications prioritize user-specific content and real-time data over static caching:

routeRules: {
 // Marketing pages
 '/': { prerender: true },
 '/features': { prerender: true },
 '/pricing': { prerender: true },
 '/docs/**': { swr: 86400 },

 // Authenticated dashboard
 '/app/**': { ssr: false },

 // Static assets from CDN
 '/_nuxt/**': { headers: { 'cache-control': 'max-age=31536000' } }
}

The pattern separates public marketing content from authenticated application areas. Dashboard routes use client-side rendering since they require user authentication and contain personalized data. Documentation benefits from daily caching for freshness without rebuild overhead.

Common Pitfalls and Best Practices

Several common mistakes can undermine hybrid rendering effectiveness. Understanding these pitfalls helps you avoid them in your implementations.

Common Pitfalls

  1. Over-Caching Dynamic Content: Applying long cache durations to genuinely dynamic content frustrates users who expect current information. Product inventory, user notifications, and real-time data shouldn't use long cache durations even if performance metrics look favorable.

  2. Ignoring Authentication Requirements: Routes requiring authentication shouldn't rely solely on caching strategies that might serve cached content to unauthorized users. Ensure your authentication logic executes before cache retrieval for sensitive routes.

  3. Inconsistent Cache Configurations: Inconsistent caching across similar routes creates confusing user experiences and maintenance challenges. Establish clear patterns for route types and apply them consistently throughout your application.

Best Practices

  1. Document Your Strategy: Maintain clear documentation of your route rendering strategy. When multiple developers work on an application, understanding why each route uses its configured strategy prevents accidental misconfigurations and helps new team members make informed decisions.

  2. Start Simple, Evolve Gradually: Begin with straightforward rendering strategies and introduce complexity as requirements demand. Most applications don't need elaborate hybrid configurations initially. Start with server-side rendering for dynamic content and pre-rendering for static pages, then add caching strategies as performance requirements become clearer.

  3. Test Before Deploying: Route rule changes can significantly impact application behavior. Test configurations in staging environments that mirror production behavior before deploying changes. Pay particular attention to authentication flows, form submissions, and real-time features that might behave differently under various rendering strategies.

  4. Monitor and Iterate: Track cache hit rates, server response times, and Time to First Byte (TTFB) to verify strategies are effective. Low cache hit rates might indicate durations that are too short, while long response times might indicate inefficient data fetching or rendering logic that needs optimization.

For comprehensive web development services that leverage these optimization strategies, our team can help you implement hybrid rendering patterns tailored to your specific business requirements.

Frequently Asked Questions

What is the difference between SWR and ISR in Nuxt 3?

SWR (Stale-While-Revalidate) serves cached content immediately while regenerating in the background. ISR (Incremental Static Regeneration) generates static pages on-demand and caches them at the edge. SWR is simpler and more universal, while ISR offers better efficiency for high-traffic routes on supported platforms like Vercel and Netlify.

Can I mix rendering modes in a single Nuxt 3 application?

Yes, Nuxt 3's hybrid rendering allows different rendering strategies for different routes. You can have pre-rendered marketing pages, server-side rendered dashboards, and client-side rendered admin areas all in the same application. This flexibility is one of Nuxt 3's most powerful features.

How do I invalidate cache when content changes?

For SWR and ISR routes, cache invalidates automatically when the duration expires. For urgent updates, implement webhooks that trigger regeneration or use platform-specific cache invalidation APIs. Pre-rendered routes require rebuilding to update content, so consider CI/CD pipelines that rebuild when content changes.

What happens to SEO when using client-side rendering?

Client-side rendered routes (ssr: false) don't provide pre-rendered HTML, which can challenge search engine crawling. Search engines have improved at crawling JavaScript applications, but pre-rendered HTML remains more reliable. Use SSR or pre-rendering for SEO-critical pages, and reserve CSR for authenticated or non-indexed areas like admin panels.

How do I choose between prerender and swr?

Use prerender for content that never changes after deployment, such as documentation versions, archived pages, or landing pages. Use SWR for content that changes occasionally but not continuously, like blog posts, product pages, or category listings where slight staleness is acceptable in exchange for automatic refresh.

Ready to Optimize Your Nuxt 3 Application?

Our team specializes in building high-performance web applications with Nuxt 3. We can help you implement hybrid rendering strategies tailored to your specific requirements, from marketing websites to complex SaaS dashboards.

Sources

  1. Nuxt 3 Official Documentation - Rendering Modes - Comprehensive coverage of all rendering modes including hybrid rendering, route rules, and cache strategies.

  2. Nuxt 3 Official Documentation - Route Rules Configuration - API documentation for routeRules configuration in nuxt.config.ts.

  3. Vue School - Hybrid Rendering in Nuxt 3 - Tutorial on implementing hybrid rendering patterns with route caching strategies.

  4. This Dot Labs - Rendering Modes in Nuxt 3 - Practical implementation examples for universal rendering, client-side rendering, and hybrid rendering configurations.