Blogs

If you’ve ever worked with Server Side Rendered applications, you’ve quickly realized hydration errors can be a pain. What’s even more painful is finding where the errors come from and how to resolve them. Well, look no further! The new nuxt/hints module can be just the right tool for you to use!

Nuxt Hints gives real-time feedback on your app’s performance, accessibility, and security and it does it directly inside your browser via the devtools. While you could still manually audit your site (e.g. running external tooling, code reviews, etc.), with nuxt/hints you get actionable insights as you build. You spot slow-loading third-party scripts, hydration mismatches, or suboptimal layouts for web vitals.

Before diving deeper into it, let’s make some things clear:

Nuxt Hints integrates directly into the Nuxt DevTools, so the insights are not based on production information (but they can still be very useful). Moreover, this module probably becomes more useful for bigger and more complex projects.

What to expect from nuxt/hints

Once you installed the module (and added it to your nuxt config file), just run your application normally and open DevTools. Click on the Hints icon and the hints panel will appear, summarizing detected issues:

• Real-time Web Vitals metrics (LCP, INP, CLS) + element-level attribution & advice for improvement.

• Hydration mismatch detection: side-by-side diff between server-rendered HTML and client-hydrated HTML to help debug mismatches. What’s really valuable here is that you can click on the component that’s causing the issue and jump directly to the source code to check out the implementation!

• Third-party script auditing: lists external scripts, shows their performance/impact, and gives security/performance warning or suggestions.

Lastly, Nuxt Hints is still in its early days. As it matures beyond alpha, this module has the potential to become an integral part of DevTool or it could go a totally different way.

For any modern Nuxt project, Hints is a “nice to have” guardrail. It helps you catch common issues early, avoid regressions, and keep quality high without leaving your editor.

Nuxt is configured with sensible but extendable defaults. The nuxt.config.ts file supports an opt-in features namespace to enable or disable specific runtime behaviors, alongside a future namespace to adopt upcoming framework defaults and experimental multi-app support. It is located at the root of a Nuxt project and can be used to add custom scripts, register modules or change rendering modes.

In this article, we’re going to check some “extra” options that go further and could help unlock new possibilities.

Features

The features block controls optional runtime behaviors in your application:

devLogs

• Streams SSR server logs to the browser during development.

• Default: true in dev

• Can be set to 'silent' to suppress logs

export default defineNuxtConfig({
  features: {
    devLogs: true // | 'silent'
  }
})

inlineStyles

• Inlines component CSS into rendered HTML (Vite only).

• Default: (id) => id.includes('.vue')

• Can be set to false or a callback for per-component control

export default defineNuxtConfig({
  features: {
    inlineStyles: false // | (id) => boolean
  }
})

noScripts

• Disables injection of Nuxt client scripts and JS resource hints.

• Options:

• true or 'production' – disable in production

• 'all' – disable in both dev & prod

• false – leave enabled

export default defineNuxtConfig({
  features: {
    noScripts: true, // or 'production' | 'all' | false
  },
})

Future

Enable upcoming defaults and experimental core changes under future:

compatibilityVersion

• Opt into defaults of a future major release (e.g., v5)

export default defineNuxtConfig({
  future: {
    compatibilityVersion: 5
  }
})

multiApp

• Early access to experimental multi-app support within a single Nuxt instance

export default defineNuxtConfig({
  future: {
    multiApp: true
  }
})

Experimental Features

asyncContext

• Enables native async context to be accessible for nested composables in Nuxt and Nitro, reducing "Nuxt instance is unavailable" errors

export default defineNuxtConfig({
  experimental: {
    asyncContext: true,
  },
})

buildCache

• Caches Nuxt build artifacts based on a hash of the configuration and source files for faster rebuilds

export default defineNuxtConfig({
  experimental: {
    buildCache: true,
  },
})

cookieStore

• Enables CookieStore support to listen for cookie updates and refresh useCookie ref values:

export default defineNuxtConfig({
  experimental: {
    cookieStore: true,
  },
})

purgeCachedData

• Nuxt will automatically purge cached data from useAsyncData and nuxtApp.static.data to prevent memory leaks. But you can decide to clean up Nuxt static and asyncData caches on route navigation.

export default defineNuxtConfig({
  experimental: {
    purgeCachedData: false, // enabled by default
  },
})

As developers, we know how important it is to reduce the amount of JavaScript we ship to the browser. And since Nuxt has been around, it has showed how powerful SSR can be for building performant applications.

Nuxt offers experimental features like Server Components to take our game to the next level but before using them, it’s important to take a look back at how hydration works and how Nuxt handles Server Side Rendering.

When you build a typical Nuxt application with SSR enabled, here's what happens:

On the Server:

• Vue renders your components to static HTML

• The server generates the complete DOM structure

• This HTML is sent to the browser immediately

On the Client (Hydration):

• The browser receives static HTML and displays it instantly

• JavaScript bundles download in the background

• Vue "hydrates" the static HTML by creating the virtual DOM, matching it to existing DOM nodes, and attaching event listeners

• The page becomes fully interactive

This hydration process is necessary but comes with overhead. Every component needs to be downloaded as JavaScript, executed on the client, and "woken up" to become interactive. The JavaScript for your entire application must be downloaded and parsed even if most of it renders static content.

How Sever Components can help

Server components (also called component islands in Nuxt) fundamentally change this equation. They allow you to mark specific components to only render on the server and never hydrate on the client. They have some key benefits:

• Reduced JavaScript Bundle Size: Server components and their dependencies are completely excluded from the client bundle. If you have a component that uses a heavy markdown parser or syntax highlighter, that entire library stays on the server.

• Zero Hydration Overhead: Since server components don't hydrate, there's no virtual DOM creation, no event listener attachment, and no reconciliation work on the client. The component is truly static HTML.

• Secure Server-Only Logic: You can safely include database queries, API keys, or other sensitive operations directly in server components without worrying about exposing them to the client.

• Works with Static Sites: Despite the name, server components work perfectly with static site generation (SSG). Nuxt prerenders them at build time, so you can use them even on static hosting platforms like GitHub Pages or Netlify.

When and where to use them

Server components shine in specific scenarios where you have expensive rendering logic but don't need client-side interactivity. For example:

• Syntax Highlighting and Code Blocks: Libraries like Shiki can add significant weight to your bundle. A syntax highlighter component is perfect as a server component since the highlighted code is just static HTML.

• Markdown Rendering: Parsing and rendering markdown with MDC syntax or other parsers can be done entirely on the server. The rendered HTML is sent to the client without shipping the parser.

• Static Footers and Headers: Navigation bars, footers, or any layout component that displays static content are excellent candidates. They add zero JavaScript but still render correctly.

• Content from APIs: If you're fetching data from a CMS or database to display read-only content, server components eliminate the need to ship that fetching logic to the client.

Implementing Server Components

In Nuxt 4, server components are still experimental but increasingly stable. Here's how to use them:

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    componentIslands: true
  }
}

Simply add the .server.vue suffix to your component file:

components/
  HighlightedCode.server.vue
  SiteFooter.server.vue
  MarkdownRenderer.server.vue

Use it like any component:

<template>
  <div>
    <HighlightedCode :code="myCode" language="typescript" />
    <SiteFooter />
  </div>
</template>

That's it! No special syntax in your template. The component renders on the server, and Nuxt sends only the HTML to the client.

A final note

While reducing JavaScript bundle size is the most tangible benefit, server components offer something deeper: architectural clarity. They force you to think about data flow, component boundaries, and where state truly lives. This discipline makes your applications more maintainable. When you see a .server.vue component, you immediately know it has no client-side dependencies, no reactivity, no event handlers. It's self-documenting architecture.

The convergence of server and client rendering represents the maturation of the JavaScript ecosystem. We're moving past the "SSR vs CSR" debates toward hybrid approaches that acknowledge both have their place.

Serverless functions are tiny pieces of code that run on demand in the cloud. You don’t provision servers or infrastructure, or write scaling rules. Cloud providers handle the underlying infrastructure, automatically scaling resources based on demand. 

They’re perfect for lightweight APIs, form handlers, webhooks, simple auth endpoints, and glue code.


How Nuxt does it (Nitro + H3)

Nuxt has built-in support for serverless functions via Nitro (its server engine). Nitro compiles your server code to many targets (Node, Vercel, Netlify, Cloudflare Workers, etc.) and runs on top of H3, a tiny, fast HTTP framework.

You write your server-side logic inside the server/api/ folder. Each file becomes an API endpoint automatically.

// server/api/hello.ts
export default defineEventHandler(() => {
  return { message: 'Hello from serverless' }
})

This function will respond to GET /api/hello with a JSON object. That’s it. Visit` /api/hello` in your browser or useFetch() from your frontend, and you get:

{ "message": "Hello from serverless" }

Calling Your APIs from the Frontend

You can use useFetch(), useAsyncData(), or $fetch() to call these functions in your Vue components or pages.

<script setup>
const { data } = await useFetch('/api/hello')
</script>

<template>
  <p>{{ data.message }}</p>
</template>

Deployment

Nuxt works with Vercel, Netlify, Cloudflare, etc. Just push your code and your functions will auto-deploy as serverless endpoints.

• Vercel → Serverless Functions

• Netlify → Netlify Functions

• Cloudflare → Workers

You don’t need to configure anything manually — just push your code.


Quick Tips to Not Shoot Yourself in the Foot

• Don’t trust inputs, always validate.

• Use environment variables for anything secret.

• Keep functions small and focused.

• Handle errors properly.

• Don’t block the event loop with long-running tasks (offload to queues if needed).

Common Use Cases

• Form submissions

• Email sending

• API proxies

• Auth endpoints

• Data fetching or caching

• Webhooks

With Nuxt and Nitro, serverless functions are just regular files that do backend magic. No setup, no stress. Whether you need a contact form endpoint, a webhook handler, or a simple API proxy, you can build it in minutes.

No server management required.

Nuxt's useFetch and useAsyncData composables are already powerful, but they got some seriously handy options that can level up how you handle data in your app.

Here are a few advanced options that make a real difference in performance, UX, and network efficiency:

1. dedupe: Avoid Duplicate Requests

Nuxt by default cancels any request with the same key before starting a new one. This means if you have multiple components that fetch the same data, you’ll see unnecessary requests and a lot of canceled ones. With the option dedupe: 'defer’ if an identical request is already pending, Nuxt won’t refetch and waits for the current one to finish. 

const { data } = await useFetch('/api/products', {
  dedupe: 'defer'         // default value: cancel
});

2. retry and retryDelay: Resilience for Unstable Endpoints

Not all users have stable connection or fast Wi-Fi. For flaky APIs, edge functions, or when you want to add basic fault tolerance without custom logic, you can use Nuxt’s retry mechanism.

const { data } = await useAsyncData('user', () => $fetch('/api/user'), {
  retry: 3,            // number of retries after first request fails
  retryDelay: 1000     // milliseconds delay between retries
});

3. delay: Stagger Fetches for Smoother UX

This option adds a delay before making the request. You can use it to debounce fetches triggered by user input (though better handled via watch + debounce). It’s’ useful when you want to avoid flashing loading states for super quick page transitions.

const { data } = await useFetch('/api/settings', {
  delay: 300.          // milliseconds before starting fetch
});

Pro tip:

Always provide a key if you're using immediate: false, lazy, or working with reactive URLs to ensure deduplication and caching behave predictably.

These options let you finely tune your app's data layer for performance, UX, and network behavior. Mastering them in useFetch and useAsyncData helps you write cleaner, more efficient, and more resilient Nuxt apps.

As published on "the official State of Vue.js report of 2025" earlier this year, I did a case study to showcase how Funda (real estate platform in the NL) makes use of Vue and Nuxt.

Little intro about Funda?
Funda is the Netherlands' leading real estate listing platform, serving millions of users daily. With hundreds of thousands of property listings and approximately 5 million daily searches, the platform demands exceptional performance, scalability, and search capabilities. Given the possible combination of search parameters and filters to cater to the users’ needs, this isn’t a trivial task. In addition, search engine optimization (SEO) is critical for ensuring visibility in property searches and maintaining a competitive edge for brokers.


How did we use Vue and Nuxt? And why?
Our web application combines modern technologies throughout its stack. For the frontend, we rely on Nuxt 3 with TypeScript and use Tailwind CSS as our CSS framework of choice, which also helps us write consistent styles according to our design system. The backend relies on the .NET framework, incorporating Elasticsearch to handle search functionality. The entire solution is hosted on the Microsoft Azure cloud platform.

Beyond that, essential performance defaults, such as automatic code-splitting by route or predefined cache headers for assets, helped us get a good baseline. The built-in filesystem-based routing structure is also a big plus, as it makes navigation between listings and pages much simpler than solely using Vue Router (which is possible in Nuxt, too, if needed).

One key feature that makes domain-driven design possible is Nuxt's layer system. This allows us to split our codebase into multiple layers representing a domain. Each layer can have its own BFF and export its components. This makes it easy to separate concerns and keep the codebase clean and maintainable. Further, the layer system makes it easy to auto-import composables, components, and utilities, which is a big plus. Eventually, we benefit from further enhancements the Nuxt team ships consistently, from performance to developer experience improvements.