DEV Community: Alex Marusych

How to create redirects in Nuxt 3

Alex Marusych — Tue, 15 Jul 2025 14:16:08 +0000

This is the lesson from my video course. If you prefer posts you can read this article :)

How to create redirects in Nuxt 3

Alex Marusych — Mon, 14 Jul 2025 13:21:26 +0000

If you are reading this article, it likely means you're already familiar with Nuxt.js. And if that's the case, then you must also be familiar with Vue.js. After all, it's impossible to learn Nuxt without first learning Vue, right?

In Vue.js, an average redirect is often handled with middleware. You typically create a separate JavaScript file containing some logic, attach it to a route as middleware, and ensure that this logic runs whenever someone navigates to that specific page.

For example, someone trying to visit an outdated URL might be redirected to the correct or updated version of the page.

export default function (to, from, next) {
  next('/new-url')
}

Nuxt 3 also supports middleware, and there's a whole section in the documentation about it. In a typical Nuxt 3 project, you'll find a middleware folder in the root. Inside this folder, you can create your custom middleware files. To define one, you use a built-in function defineNuxtRouteMiddleware that expects two parameters: "to" for the target route and "from" for the origin route.

Unlike Vue, Nuxt middleware doesn’t require a “next” function. Instead, it provides two helper functions: “navigateTo” to navigate to a new route and “abortNavigation” to abort navigation altogether. That same Vue.js middleware we saw earlier can now look like this in a Nuxt 3 project.

///middleware/redirect-to-new-url.js

export default defineNuxtRouteMiddleware((to, from) => {
  return navigateTo('/new-url')
})

Another improvement in Nuxt 3 is the ability to specify whether a redirect is temporary or permanent. This can be especially useful for SEO, as permanent redirects help search engines update their indexed links accordingly.

///middleware/redirect-to-new-url.js

export default defineNuxtRouteMiddleware((to, from) => {
  return navigateTo('/new-url', { redirectCode: 301 })
})

You can choose whether a middleware runs globally (for all routes) or only for a specific page. To apply it globally, simply include the word “global” in the file name (redirect-to-new-url.global.js). If you only want it to run for a specific route, you can declare it within that page’s metadata.

<!-- pages/old-url.vue-->

<script setup lang="ts">
  definePageMeta({
    middleware: 'redirect-to-new-url', //or ['redirect-to-new-url']
  });
</script>

This approach works well for in-app redirects based on conditions — such as checking if a user is authenticated or whether a page is enabled.

But what if you want to make a true, permanent redirect from an old URL to a new one? In this case, that old URL doesn’t really belong to your current Nuxt app. You don’t expect any internal navigation to lead there. Instead, these visits usually come from external sources — an old blog post, a social media share, or simply a well-indexed search engine result.

While you could still use Nuxt middleware for this, it requires your app to boot up the full Vue environment before executing the redirect. This isn’t ideal, especially if performance and SEO are important to you.

Luckily, Nuxt 3 provides a better way through its route rules feature. With route rules, you can configure permanent or temporary redirects at the server level — before Vue even loads.

//nuxt.config.js

export default defineNuxtConfig({
  routeRules: {
    '/old-url': {
      redirect: {
        statusCode: 301,
        to: '/new-url'
      }
    },
    '/another-old-url': {
      redirect: '/another-new-url', //this one works too
    }
  }
})

This means when someone clicks on an outdated link, the browser sends a request to the server, and Nitro immediately responds with a redirect — without loading the Vue app. This makes the whole process faster, more efficient, and ideal for static redirects that don’t require any dynamic logic.

However, if your redirect does depend on some logic — like user-agent detection or IP-based conditions — you’ll need to use server middleware. Yes, in Nuxt 3, there are two types of middleware: those that run inside the Vue app and those that run in Nitro. Server (Nitro) middleware is defined inside a special folder “/server/middleware” and is executed on every request to the server.

//server/middleware/redirect-from-old-to-new-url.js

import { getRequestURL, sendRedirect } from 'h3';

export default defineEventHandler((event) => {
  const url = getRequestURL(event);

  if (url.pathname === '/old-url') {
    return sendRedirect(event, 'https://domain.com/new-url', 301);
  }
});

Unfortunately, it can’t be tied to a specific URL, so you’ll need to manually check whether the request matches your target path and handle it accordingly.

There’s one more option: server routes. With server routes, you define logic that matches a specific URL path (“server/routes/old-url.js”). If someone requests that URL, your custom route handler is executed. This lets you manage redirects without the need for conditional checks, making it ideal for cases with multiple static redirects.

//server/routes/old-url.js

import { sendRedirect } from 'h3';

export default defineEventHandler((event) => {
  return sendRedirect(event, 'https://domain.com/new-url', 301);
});

Nuxt 3 gives you different ways to handle redirects — inside the app, at the server level, or before the app even loads. Use in-app middleware for conditional redirects, route rules for simple and fast ones, and server routes when you need more control. Pick the method that fits your case best.

If you want to learn how to build fast, SEO-friendly web apps with Nuxt 3 — step by step — 👉 Check out my course here.

How to create a sitemap in Nuxt 3

Alex Marusych — Mon, 07 Jul 2025 07:43:37 +0000

Understanding sitemaps for SEO Optimization

Alex Marusych — Mon, 07 Jul 2025 07:40:59 +0000

A comprehensive guide to Dynamic Imports and Lazy Hydration in Nuxt 3

Alex Marusych — Mon, 07 Jul 2025 07:35:22 +0000

In the Nuxt 3 documentation, there’s a well-known article about the components directory in your app. It includes a section on Dynamic Imports, which has been there for a long time. Recently, the Nuxt team added another section called Delayed (or Lazy) Hydration. Interestingly, both features use the same approach — you add the Lazy prefix to a component name — but they serve different purposes.

That’s where confusion often begins. Many newer developers tend to mix these two up, so this article is here to explain the difference clearly and show how to use both features properly.

To demonstrate this, I created a small Nuxt app that uses both dynamic imports and lazy hydration. The repository is public, so you can clone it and try everything out yourself.

The app is simple: it includes a header, a long scrollable section with a button, a footer, and a modal window.

<!-- app.vue -->

<template>
  <main>
    <header>Header</header>
    <section>
      <h1>The too long section</h1>
      <button @click="toggleModalWindow">
        Open the modal window
      </button>
    </section>
    <LazyAppFooter
      hydrate-on-visible
      @hydrated="onFooterHydrate"
    />
    <LazyAppModalWindow
      v-if="isModalWindowOpened"
      @close="toggleModalWindow"
    />
  </main>
</template>

<script setup>
  const isModalWindowOpened = ref(false);

  const onFooterHydrate = () => console.log('Footer has been hydrated');
  const toggleModalWindow = () => isModalWindowOpened.value = !isModalWindowOpened.value;
</script>

<style lang="css">
  body {
    background-color: black;
    box-sizing: border-box;
    color: white;
    font-size: 24px;
    text-align: center;
  }

  header {
    position: sticky;
    top: 0;
    padding: 20px;
    background-color: black
  }

  section {
    height: 2000px;
    background-color: rgba(255, 255, 255, 0.5);
    padding: 100px 20px;
  }

  button {
    border: none;
    outline: none;
    height: 44px;
    background-color: chocolate;
    color: white;
    border-radius: 4px;
    font-size: 14px;
    cursor: pointer;
  }
</style>

Let’s start with Dynamic Imports since this feature has existed in Nuxt for quite some time and is already familiar to many developers.

Most Nuxt apps have components that are not immediately visible when the page loads. These could be modal windows, tooltips, dropdowns, or mobile menus. They typically appear only after the user interacts with something. The important part is that the user might never trigger these components at all. For example, someone browsing your site on a desktop won’t see the mobile menu. Separately, they might never open a review popup or fill in a form at all.

However, if you don’t optimize your app, these hidden components may still be rendered on the server and their JavaScript will be downloaded on the client, even though they are not needed. Wrapping them in a client-only tag prevents server rendering but doesn’t stop the browser from downloading the JavaScript.

Dynamic imports are a solution to this. By adding the Lazy prefix to a component and wrapping it in a v-if condition, you ensure that Nuxt doesn’t include the component in the server-rendered HTML, and the browser doesn’t download its JavaScript unless it actually gets rendered.

In my demo app, I use a modal window that only appears after clicking a button.

<!-- AppModalWindow.vue -->

<template>
  <div
    class="modal-window-container"
    @click="close"
  >
    <div class="modal-window">
      <h2>Modal window</h2>
      <p>
        This component is not even included in the initial HTML. When Vue is generating HTML on the server it just skips this component. Only if you click on the button to open the window, the browser downloads the whole component as a JS file.
      </p>
    </div>
  </div>
</template>

<script setup>
const emit = defineEmits(['close']);

const close = () => emit('close');

console.log('This debug will run only if you click on the button. You won\'t find it on the server side (in terminal)');
</script>

<style lang="css">
.modal-window-container {
  position: fixed;
  top: 0;
  left: 0;
  width: 100vw;
  height: 100dvh;
  background-color: rgba(0, 0, 0, 0.5);
  display: flex;
  justify-content: center;
  align-items: center;
}

.modal-window {
  padding: 20px;
  background-color: white;
  border-radius: 12px;
  width: calc(100% - 30px);
  max-width: 600px;
  box-sizing: border-box;
  min-height: 400px;
  color: black;
}
</style>

The modal component is wrapped in v-if="isModalWindowOpened", and I renamed it to LazyAppModalWindow.

<LazyAppModalWindow
  v-if="isModalWindowOpened"
  @close="toggleModalWindow"
/>

This way, Vue skips it during SSR and doesn't include its JavaScript in the initial bundle. Once the condition is true, the browser downloads the JavaScript, and Vue mounts the component from scratch. It’s not hydrated, since it wasn’t rendered on the server.

So, if you have components that don’t contain valuable SEO information and are simply the result of user interaction, you can make them lazy-loaded. This will make your server-side HTML lighter, reduce the size of JavaScript chunks, and exclude these components from the initial hydration.

Now let’s move on to Lazy Hydration, which is a newer and often misunderstood feature.

There are many situations where you want a component to be part of the server-rendered HTML because it contains content valuable for SEO, but its JavaScript behavior is not necessary immediately. For example, think about a long marketing page where the footer is all the way at the bottom. The content is important, but its interactive features aren’t critical during the first seconds after page load.

Lazy hydration lets the component be in the HTML but delays loading and running its JavaScript. Just like with dynamic imports, you still add the Lazy prefix to the component name. But instead of controlling rendering with v-if, you use one of Nuxt’s hydration strategies — like hydrate-on-visible, hydrate-on-idle, hydrate-on-interaction and others.

In my app, the page is too long, and the footer is not in the viewport right at the beginning. So, if the footer has some client-side JavaScript logic, it’s definitely useless when the user doesn’t see it yet. That’s why I decided the footer’s JavaScript should be downloaded only when the component enters the screen — this is actually the most common case discussed.

<LazyAppFooter
  hydrate-on-visible
  @hydrated="onFooterHydrate"
/>

This means the footer is rendered during SSR and appears in the HTML from the start, but its JavaScript won’t be downloaded or executed until the user scrolls down and the footer enters the viewport.

To show exactly what happens, I placed three debug logs in the footer component. One runs when executes, another runs inside the onMounted lifecycle hook, and the third is triggered by the hydrated event.

<!-- AppFooter.vue -->

<template>
  <footer>
    Footer. This component is included in the initial HTML. When Vue.js is running on the server it runs this component and renders in the HTML. But the corresponding JavaScript is loaded only when the specific hydration statement is achieved. In our case it's when component is visible.
  </footer>
</template>

<script setup>
onMounted(() => console.log('Footer has been mounted on the client side'));

console.log('This debug runs twice: the first one on the server side (check in the terminal), and then on the client side when component is in the viewport');
</script>

<style lang="css">
footer {
  padding: 20px;
  background-color: black
}
</style>

So, what’s going on in this case? When Vue runs on the server side, it renders the footer. Hence our first debug inside script setup always runs on the server. Since onMounted is only available on the client, Vue skips it during SSR — but that code still exists in the client-side JS file.

After the initial page load, the browser starts downloading all necessary JavaScript files. However, if the footer isn’t in the viewport, the browser skips downloading the footer’s JS. Only when the user scrolls down and the footer starts to appear does the browser finally download the corresponding JS file — and that’s when the hydration process for the footer begins.

The first debug runs again, this time on the client. Then onMounted is triggered, and finally the hydrated callback runs. At that point, you’ll see the message “Footer has been hydrated” in the browser console.

Lazy hydration is useful when the component should be part of the SSR HTML for SEO purposes, but its interactivity can wait until it becomes visible, idle time is reached, or the user interacts with it. This way, you reduce the amount of JavaScript the browser needs to handle upfront, without losing the SEO benefits of server rendering.

One important note is that lazy hydration is available starting from Nuxt version 3.16.0. So make sure you’re using a compatible version if you plan to apply this technique.

To summarize everything in one sentence: use dynamic imports when your component doesn’t need to be rendered on the server and is only used after interaction, and use lazy hydration when your component should be rendered on the server for SEO, but its client-side JavaScript can be delayed.

That’s it. Hope this article helped you understand how and when to use both dynamic imports and lazy hydration properly in Nuxt 3.

If you want to learn how to build fast, SEO-friendly web apps with Nuxt 3 — step by step — 👉 Check out my course here.

From Static to Smart: Making a Dynamic Sitemap with Nuxt 3

Alex Marusych — Mon, 30 Jun 2025 10:00:34 +0000

You don't always need a sitemap, but it can really help. If your site is new, large, or has many pages that aren't well linked, a sitemap makes sure nothing is missed. Sitemaps can also tell search engines how often content changes and what to focus on first. But keep in mind: a sitemap doesn't guarantee indexing. It just increases your chances.

The simplest way to add a sitemap to your Nuxt 3 project is to place a ready-made sitemap.xml file into the public folder. This works fine if your site only has a few pages like the home page, "About Us," and "Contacts." In this case, you don't expect changes in the sitemap, and it stays valid over time.

But what if you're building an e-commerce site? Any page can change at any moment. You may have hundreds of product pages, and their number changes all the time. If you use a static file, you'll need to update it manually every time a product is added, updated, or removed. That's time-consuming and easy to forget.

Luckily, Nuxt 3 makes it easy to create a dynamic sitemap that always stays up to date. You can generate it on the fly using server routes.

Let me show you a real example. I have an online bookstore. All books are stored in a Supabase database. The app has three main pages: the home page, individual book pages, and the order page. The order page isn't relevant for search engines, so I won't include it. Hence, the sitemap should contain only the home page and each book's detail page.

Before we dive into the code, here's what the final version of the sitemap will look like.

<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>

It will include a link to the home page, followed by a list of all current books, each with its own URL and last updated date.

To build this, the first step is to create the corresponding server route. The name of the route file should match the URL being requested. So in this case, I name the file sitemap.xml.js. That way, when someone requests /sitemap.xml, Nuxt will automatically use this route to handle the request.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {

});

Next, I return a basic response from the route.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>
`;

  return content;
});

At first, it's just plain text. That's why I need to set the response header to let search engines know this is an XML file.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>
`;

  setResponseHeader(event, 'Content-Type', 'application/xml');

  return content;
});

Now it looks better. All that's left is to replace the hardcoded data with real values. I will load all existing books from the database, replace the hardcoded domain with the actual one from the config, and create a link to each of their pages.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const config = useRuntimeConfig(event);
  const books = await getProducts(event);

  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>${config.public.appBaseUrl}</loc>
  </url>

  ${books.map(book => `
  <url>
    <loc>${config.public.appBaseUrl}/book/${book.slug}</loc>
    <lastmod>${getLastmodValue(book.updated_at)}</lastmod>
  </url>
  `)}
</urlset>
`

setResponseHeader(event, 'Content-Type', 'application/xml');
return content;
});

There are a few helper functions I used. getLastmodValue is a simple function to format a date string.

function getLastmodValue(dateString) {
  return new Date(dateString).toISOString().split('T')[0];
};

getBooks is a function that fetches all books, but only with the necessary properties: slug and updated_at. I use the slug to build the URL for the book's page, and I use the updated_at value to show when the content was last changed. That's important because search engines use this to understand how fresh the page is.

import { createClient } from '@supabase/supabase-js';

async function getBooks(event) {
  const supabaseUrl = process.env.SUPABASE_URL;
  const supabaseKey = process.env.SUPABASE_KEY;
  const client = createClient(supabaseUrl, supabaseKey);

  const { data, error } = await client
    .from('products')
    .select('slug, updated_at');

  if (error) {
    throw createError({
      statusCode: 500,
      message: error.message || 'Something went wrong',
    });
  };

  return data;
}

Of course, this function is just an example and only covers my case. But the main idea stays the same-you need to fetch all the data you need for the sitemap, or return an error.

That's it. I now have a fully dynamic sitemap that updates automatically and helps search engines index my site better. And you have a real example you can use in your own projects. Just adjust it to match your content structure and database.

From Static to Smart: Making a Dynamic Sitemap with Nuxt 3

Alex Marusych — Mon, 30 Jun 2025 10:00:34 +0000

Luckily, Nuxt 3 makes it easy to create a dynamic sitemap that always stays up to date. You can generate it on the fly using server routes.

Before we dive into the code, here's what the final version of the sitemap will look like.

<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>

It will include a link to the home page, followed by a list of all current books, each with its own URL and last updated date.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {

});

Next, I return a basic response from the route.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>
`;

  return content;
});

At first, it's just plain text. That's why I need to set the response header to let search engines know this is an XML file.

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://best-to-read.com</loc>
  </url>
  <url>
    <loc>https://best-to-read.com/book/the-courage-to-be-disliked-how-to-free-yourself-change-your-life-and-achieve-real-happiness</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/the-lean-startup</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
  ,
  <url>
    <loc>https://best-to-read.com/book/art-public-speaking-dale-carnegie</loc>
    <lastmod>2024-10-06</lastmod>
  </url>
</urlset>
`;

  setResponseHeader(event, 'Content-Type', 'application/xml');

  return content;
});

//server/routes/sitemap.xml.js

export default defineEventHandler(async (event) => {
  const config = useRuntimeConfig(event);
  const books = await getProducts(event);

  const content = `<?xml version="1.0" ?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>${config.public.appBaseUrl}</loc>
  </url>

  ${books.map(book => `
  <url>
    <loc>${config.public.appBaseUrl}/book/${book.slug}</loc>
    <lastmod>${getLastmodValue(book.updated_at)}</lastmod>
  </url>
  `)}
</urlset>
`

setResponseHeader(event, 'Content-Type', 'application/xml');
return content;
});

There are a few helper functions I used. getLastmodValue is a simple function to format a date string.

function getLastmodValue(dateString) {
  return new Date(dateString).toISOString().split('T')[0];
};

import { createClient } from '@supabase/supabase-js';

async function getBooks(event) {
  const supabaseUrl = process.env.SUPABASE_URL;
  const supabaseKey = process.env.SUPABASE_KEY;
  const client = createClient(supabaseUrl, supabaseKey);

  const { data, error } = await client
    .from('products')
    .select('slug, updated_at');

  if (error) {
    throw createError({
      statusCode: 500,
      message: error.message || 'Something went wrong',
    });
  };

  return data;
}

Of course, this function is just an example and only covers my case. But the main idea stays the same-you need to fetch all the data you need for the sitemap, or return an error.

The Dark Side of useFetch and useAsyncData in Nuxt 3

Alex Marusych — Tue, 24 Jun 2025 18:31:06 +0000

When you build an app with Nuxt, Vue actually runs twice: once on the server and then again on the client. Because of that, if you fetch some data, it would normally happen two times too — once during server-side rendering, and then again when the page loads in the browser. To avoid this, Nuxt gives us useFetch and useAsyncData. Thanks to these built-in composables, you don’t have to worry about making duplicate requests. Everything feels smooth — you fetch data once, and it just works.

But have you ever thought about how this magic happens? In simple words, after the server fetches the data, Nuxt sneaks it into the HTML it sends to the client. It hides the response inside a script tag in the page’s body.

Then, when Vue starts running on the client side, it grabs the data from there instead of making a second request. Pretty clever, right?

Let's say you're building a simple Nuxt application that fetches a book and displays it.

<template>
  <div class="container">
    <div>
      <h2>Response</h2>
      <div class="response">
        <pre>{{ data }}</pre>
      </div>
    </div>
  </div>
</template>

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

When Vue runs on the server, useFetch requests the book and stores the response inside that hidden JSON. Later, when Vue runs on the client, useFetch just reads the saved data. No second request needed. Everyone's happy.

Well… almost everyone. There's one small catch. Since the data gets stuffed inside the HTML page, it makes the file heavier. If you need all the data - that's fine. But what if you don't? Imagine you only display three fields from the book: "name", "author" and "price".

<template>
  <div class="container">
    <div>
      <h2>Response</h2>
      <div class="response">
        <pre>{{ data }}</pre>
      </div>
    </div>
    <div>
      <h2>Card</h2>
      <div class="card">
        <h3>{{ data.name }}</h3>
        <div class="author-price-block">
          <span>{{ data.author }}</span>
          <span>{{ data.price }} USD</span>
        </div>
      </div>
    </div>
  </div>
</template>

The server still fetched a huge object with tons of other information you don't even use. All of it still gets dumped into your HTML payload, making the page heavier for no good reason.

That's where a little extra care can make a big difference. Nuxt actually lets you control what ends up in the payload.

If your API returns an object, you can tell useFetch or useAsyncData to "pick" only the fields you need.

<template>
  <div class="container">
    <div>
      <h2>Response</h2>
      <div class="response">
        <pre>{{ data }}</pre>
      </div>
    </div>
    <div>
      <h2>Card</h2>
      <div class="card">
        <h3>{{ data.name }}</h3>
        <div class="author-price-block">
          <span>{{ data.author }}</span>
          <span>{{ data.price }} USD</span>
        </div>
      </div>
    </div>
  </div>
</template>

<script setup>
const { data, error } = await useFetch('/api/book', {
  pick: ['name', 'author', 'price']
})
</script>

So even though the API still sends everything, only the important parts get saved into the HTML.

If you're dealing with a list - like an array of books - you can go even further and "transform" the whole response.

<template>
  <div class="container">
    <div>
      <h2>Response</h2>
      <div class="response">
        <pre>{{ data }}</pre>
      </div>
    </div>
    <div>
      <h2>Cards</h2>
      <div>
        <div
          v-for="item in data"
          :key="item.id"
          class="card"
        >
          <h3>{{ item.name }}</h3>
          <div class="author-price-block">
            <span>{{ item.author }}</span>
            <span>{{ item.price }} USD</span>
          </div>
        </div>
      </div>
    </div>
  </div>
</template>

<script setup>
const { data, error } = await useFetch('/api/books', {
  transform: (data) => data.map(item => ({
    id: item.id,
    name: item.name,
    author: item.author,
    price: item.price
  }))
})
</script>

This way you can completely control the size of the payload, no matter how much data the API sends.

So here's the thing: even though useFetch and useAsyncData protect you from double-fetching, they can still quietly hurt your performance if you're not careful with the payload. It's always a good habit to check what actually ends up inside the page.

Data Fetching in Nuxt 3 in Simple Words

Alex Marusych — Sat, 14 Jun 2025 09:12:04 +0000

If you’ve ever used Nuxt 3, you know there are a few ways to fetch data. But when should you use each one? The Nuxt documentation provides a detailed article about this. But if you’re still confused, here’s a simple way to understand it.

In Nuxt 3, you have three main options: the $fetch helper, and two composables: useFetch and useAsyncData. To simplify your life, just remember this: useFetch and useAsyncData are wrappers around $fetch and mean almost the same thing.

So most of the time, you just need to choose between $fetch or useFetch / useAsyncData.

Another simple rule is that this choice only matters on the frontend. If you fetch data in the backend (inside the server folder), you can only use $fetch.

Now, imagine you want to fetch data in a .vue file. What should you use? In general, you can use $fetch everywhere. It will work, and you won't see any errors in the console. But there's one case where using $fetch is not a good idea.

One of the main advantages of Nuxt 3 (compared to plain Vue) is that it uses server-side rendering (SSR) by default. This means the browser gets an HTML page already filled with content. The process of rendering is actually quite complex, but to put it simply: the Vue app runs twice - first on the server, and then again on the client (the browser).

If you use $fetch inside a Vue component, the app fetches the same data twice - once on the server and once on the client.

To fix this, Nuxt 3 provides useFetch and useAsyncData. Their main advantage is that they fetch the data only once - on the server.

Here is a simple rule to remember. If the data is needed for the server-rendered HTML (or if you see that the data is fetched twice), use useFetch or useAsyncData. For everything else, use $fetch.

For example, if you need to fetch data after a user clicks a button or scrolls the page - use $fetch. If you are fetching inside a lifecycle hook like onMounted - use $fetch. If you are working inside a client-side only component - again, use $fetch.

That's it. Simple and clear. Hope this makes it easier for you to choose the right way to fetch data in Nuxt 3!
This information is enough to fetch data properly in almost all cases.

But if you want to go a bit deeper, you can also learn about the difference between useFetch and useAsyncData. In short: useAsyncData is more flexible if you need to transform the data before using it, while useFetch is usually enough when you just want to fetch and display it.

Vue.js or Nuxt.js? Choose the Right Tool for Your Project

Alex Marusych — Tue, 03 Jun 2025 18:27:12 +0000

In this short article I'll show you the simple way to decide what you should use for your project - Vue.js or Nuxt.js.

To choose the right framework, we need to look at what makes Nuxt.js better than Vue.js in some cases. For me, there are three main advantages.

1. Built-in Structure and Auto Imports

Nuxt.js gives you a ready-to-use folder structure. It automatically imports components, layouts, composables, pages, and plugins. You don't need to spend time thinking about where to put files or how to name them. Everything is organized for you.

2. Built-in API Support

Nuxt.js lets you create a simple API right inside your project. You can connect a database, get data from it, add new data, update it, or delete it. It's very useful for small apps where you don't want to create a separate backend.

3. SEO-Friendly by Default

This is my favorite part. Nuxt makes your Vue.js app SEO-friendly. That means search engines like Google can read your site and show it in search results.

So, when I start a new project, I first ask: Should this site appear in search results? If yes, then Nuxt.js is the right choice. It works well for e-commerce websites, blogs, online course platforms, landing pages, and company websites.

But what if your app is only for logged-in users? Or maybe it's a private tool for a company - like a salary calculator - and search engines don't need to find it?

In this case, SEO is not important. So I check the second point: Do I need a simple API inside the app? If yes - again, Nuxt.js is a good option. It's great when you need basic database actions: create, read, update, and delete. But if the API is more complex or needs to handle important data carefully, I prefer to build it separately - for example, with Node.js and Express.js. In that case, Nuxt's API feature is not useful for me.

So what's left? Just the auto imports and folder structure. But let's be honest - you can get that in Vue.js too. You can use third-party libraries for auto imports. You can copy the folder structure from Nuxt. And if you really want to, you can even add routing logic similar to Nuxt's pages folder.

Also, keep in mind - Nuxt.js apps need a more complex server and more resources. Hosting them can be more expensive than simple Vue.js apps. So if the only reason you choose Nuxt is the folder structure, it may not be worth it.

So, what should you choose?

If your project needs to appear in search engines, or you want to build a small app with a built-in API - Nuxt.js is the right choice.

But if SEO doesn't matter and you don't need Nuxt's API features, then Vue.js is simpler, cheaper to host, and gives you more freedom. You can even set up a similar structure and auto imports using tools and plugins - so using Nuxt just for its folder setup might not be worth it.