Learn Nuxt - Caching & Performance

#Introduction

Caching is the cheapest way to make an application fast. Episode 14 covers caching and performance strategies in Nuxt: from data caching on the server, leveraging the browser cache, static generation and ISR, to delivering assets efficiently.

The key is understanding that not all data must be fresh every second. A product list that changes once a day can be cached for a long time, while stock levels must always be up to date. Nuxt gives you per-page control to balance speed and data accuracy.

#Caching Data with Nitro

#Nitro Storage for Cache

Nitro provides distributed storage well suited for data caching. Store expensive computation results so they aren't repeated:

Cache hasil panggilan eksternal

export default defineEventHandler(async (event) => {
  const kunci = "cache:daftar-produk"
  const storage = useStorage("cache")
 
  const tersimpan = await storage.getItem(kunci)
  if (tersimpan) return tersimpan
 
  const data = await $fetch("https://api.eksternal.dev/v1/produk")
  await storage.setItem(kunci, data, { ttl: 300 })
 
  return data
})

storage.setItem(kunci, data, { ttl: 300 }) stores the call result for 300 seconds. Subsequent requests are served directly from cache without touching the external API — cheaper and faster.

#Correct Cache Keys

Cache keys must be unique per data variation. If the cache follows the user, include the user id in the key. If it follows the locale, include the locale. A wrong key causes data to leak between users — a serious bug in real applications.

#Browser Cache

#Leveraging the Browser Cache

The browser cache re-serves static assets like images, CSS, and JavaScript without asking the server. Set cache headers for static assets:

Cache aset statis

export default defineEventHandler(async (event) => {
  setHeader(event, "Cache-Control", "public, max-age=3600")
  return { ok: true }
})

setHeader(event, "Cache-Control", "public, max-age=3600") tells the browser to store the response for one hour. Hashed assets like build files can be cached much longer because their filenames change when content changes.

#Redis as a Storage Backend

In production, useStorage("cache") can be pointed at Redis or a similar service so the cache is shared across server instances. Backend storage configuration is explained in the Nitro documentation — start with memory storage during development.

#Static Generation, ISR, and Edge Deploy

#Strategy Differences

Three popular strategies you already know from episode 2:

• Static generation: pages are rendered once at build time. Fastest, suitable for rarely changing content.
• ISR: static pages with periodic revalidation. Content stays fast but can be updated.
• Edge deploy: pages are rendered at a location close to the user.

All of them are configured through routeRules:

Strategi cache per halaman

export default defineNuxtConfig({
  routeRules: {
    "/produk": { swr: 600 },
    "/tentang": { prerender: true },
    "/dashboard/**": { ssr: false },
  },
})

/produk uses swr of 600 seconds (cache with revalidation), /tentang is prerendered to static, and the dashboard area stays SSR or SPA. One config governs the entire page strategy.

#Building Static Output

To produce a fully static version of the site, use:

npm run generate

npm run generate processes all prerenderable pages into static HTML files in the output folder — ready to be served from any CDN.

#Optimizing Page Load and Asset Delivery

#Loading Faster

A few steps with immediate impact on load time:

• Preconnect to important asset domains so connections open earlier.
• Preload critical fonts and images.
• Lazy load heavy components so they don't join the initial bundle.

Resource hints

export default defineNuxtConfig({
  app: {
    head: {
      link: [
        { rel: "preconnect", href: "https://images.example.com" },
      ],
    },
  },
})

The preconnect resource hint signals the browser to prepare a connection before it's actually needed. Episode 15 will discuss payload optimization in more detail.

#Monitoring Build Performance

#Build Time and Output Size

Slow builds slow down the entire development cycle. Watch two main metrics:

time npm run build

time npm run build measures build duration. The second metric is output and bundle size — episode 15 will use nuxi analyze to see the bundle composition visually.

#Caching Builds in CI

In CI/CD, cache builds between pipelines so installation and compilation are faster. Episode 19 will cover CI/CD configuration including dependency caching.

#Conclusion

Episode 14 gives you full control over speed: data caching with Nitro storage and TTL, leveraging the browser cache, static generation and ISR strategies per page via route rules, resource hints to speed up loading, and the habit of monitoring build duration.

Key takeaways:

• Nitro storage with ttl is the easiest way to cache server data.
• Cache keys must be unique per data variation to prevent leaks.
• The browser cache reduces repeated requests for static assets.
• routeRules controls prerender, swr, and ssr strategies per page.
• Preconnect and preload speed up delivery of critical assets.
• Monitor build duration and cache dependencies in CI.

In the next episode, episode 15, we will discuss performance optimization — profiling with Vue DevTools and browser tools, optimizing component rendering and bundle size, prefetching links and resource hints, and reducing the JavaScript payload. Your store's performance numbers will be measured and improved.