Nuxt: Das Full-Stack-Framework für Vue

Nuxt ist das Open-Source-Full-Stack-Framework für Vue: Routing, SSR, statische Generierung und Nitro-Server. So funktioniert es, das ist Nuxt 4.

Was ist Nuxt?

Nuxt ist das Open-Source-Full-Stack-Framework auf Basis von Vue.js. Vue ist die UI-Bibliothek; Nuxt ergänzt, was eine Produktions-App drumherum braucht: dateibasiertes Routing, Server-Side Rendering, statische Generierung, Server-API-Endpunkte, Build-Werkzeuge und Deployment. Für Vue übernimmt es die Rolle, die Next.js für React und SvelteKit für Svelte spielt.

Nuxt 4 ist die aktuelle stabile Hauptversion und erschien am 15. Juli 2025. Es basiert auf Vue 3, Vite und der Server-Engine Nitro und legt den Anwendungscode standardmäßig im Verzeichnis app/ ab. Nitro kann einen Node.js-Server oder Builds für mehrere Hosting-Plattformen erzeugen, gewählt über ein Preset.

So funktioniert Nuxt

Eine Anfrage trifft auf einen Nitro-Server. Für eine Seite rendert Nuxt die Vue-Komponente auf dem Server zu HTML (Server-Side Rendering), liefert sie aus, und der Browser macht daraus per Hydration eine interaktive App. Dasselbe Projekt kann Routen auch beim Build vorab rendern (statische Generierung) oder als reine Single-Page-App im Browser laufen, und das lässt sich pro Route mischen.

Projektstruktur

my-app/
├── app/
│   ├── pages/            # file-based routing
│   │   ├── index.vue     # /
│   │   └── blog/[slug].vue  # /blog/:slug
│   ├── components/       # auto-imported
│   ├── composables/      # auto-imported
│   ├── layouts/default.vue
│   └── app.vue
├── server/
│   └── api/posts.get.ts  # GET /api/posts
├── public/
└── nuxt.config.ts

Routing und Datenabruf

Jede .vue-Datei in pages/ wird zu einer Route; [slug] erzeugt einen dynamischen Parameter. Daten laden man mit Composables, die auf Server und Client funktionieren:

<script setup lang="ts">
const route = useRoute();
const { data: post } = await useFetch(`/api/posts/${route.params.slug}`);
</script>
ComposableEinsatz
useFetchURL während des Renderns abrufen, SSR und Caching inklusive
useAsyncDataBeliebige asynchrone Funktion mit demselben Caching
$fetchEinfacher HTTP-Aufruf ohne Render-Integration, für Aktionen und Events
useStateSSR-sicherer gemeinsamer Zustand

Server-API-Routen

Dateien unter server/api/ werden zu Endpunkten, die HTTP-Methode steckt im Dateinamen (posts.get.ts, posts.post.ts, [id].delete.ts). Für ein typisches Backend ist kein separater Express-Server nötig.

// server/api/posts/[slug].get.ts
export default defineEventHandler(async (event) => {
  const slug = getRouterParam(event, 'slug');
  const post = await db.post.findUnique({ where: { slug } });
  if (!post) throw createError({ statusCode: 404, message: 'Not found' });
  return post;
});

Rendering-Modi

Nuxt rendert standardmäßig auf dem Server (Universal Rendering). Mit ssr: false rendert es nur im Browser, oder man legt es pro Route mit routeRules fest. Für eine komplett statische Seite genügt nuxt generate.

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },          // built once, served static
    '/dashboard/**': { ssr: false },   // client-side only
    '/blog/**': { isr: 60 }            // ISR: CDN-cached where the host supports it
  }
});

Nuxt vs. Next.js vs. SvelteKit

NuxtNext.jsSvelteKit
BasisVue 3ReactSvelte
Server-EngineNitroNext.js-RuntimeAdapter
Auto-ImportsJa, standardmäßigNeinNein
Dateibasiertes RoutingJaJaJa

Alle drei decken dasselbe ab, entscheidend ist daher meist die UI-Bibliothek, die das Team schon kennt.

Häufige Fehler

  • $fetch beim Rendern. Der Server lädt, der Client lädt noch einmal, die Seite flackert oder lädt doppelt. Für Daten beim Rendern useFetch oder useAsyncData verwenden.
  • Browser-APIs auf dem Server. window und localStorage gibt es beim SSR nicht; absichern oder in onMounted ausführen.
  • Hydration-Mismatches. Zufallswerte, Datumsangaben oder sprachabhängige Ausgaben, die auf Server und Client abweichen, erzeugen Warnungen und Mehrarbeit.
  • SSR ohne Cache auf stark besuchten Seiten. Rendern bei jeder Anfrage kostet CPU. Mit routeRules (swr, isr) cachen oder Unveränderliches vorab rendern.

Lasttest einer Nuxt-App

SSR verlagert das Rendern auf Ihren Server, Traffic kostet dort also CPU und nicht nur Bandbreite. Testen Sie gerenderte Seiten und /api-Routen getrennt, mit einer Rampe, die echtem Traffic entspricht, und achten Sie auf Perzentile statt Durchschnitt. Load Testing mit LoadFocus führt JMeter- und k6-Skripte aus über 25 Cloud-Regionen aus; zur Client-Seite siehe Load Testing von Single-Page-Applications.

Häufige Fragen zu Nuxt

Nuxt 4 oder Nuxt 3?

Neue Projekte starten auf Nuxt 4, stabil seit dem 15. Juli 2025. Bestehende Nuxt-3-Apps lassen sich schrittweise umstellen; die größten Änderungen sind das app/-Verzeichnis und das Verhalten beim Datenabruf, beides behandelt der offizielle Upgrade-Guide.

Nuxt oder reines Vue?

Reines Vue passt zu einer Single-Page-App, die Sie komplett selbst kontrollieren. Nuxt lohnt sich bei Server-Rendering, statischer Generierung, SEO-kritischen Seiten oder fertigen Konventionen.

Läuft Nuxt auf Cloudflare Workers?

Ja. Nitro bringt Cloudflare-Presets mit (cloudflare_module für Workers, cloudflare_pages für Pages), gesetzt über nitro.preset oder die Variable NITRO_PRESET beim Build.

Kann ich mit Nuxt eine statische Seite bauen?

Ja. nuxt generate rendert die Routen vorab zu statischen Dateien.

Was ist der Unterschied zwischen useFetch und $fetch?

useFetch ist ins Rendering integriert: Es lädt einmal auf dem Server, übergibt das Ergebnis an den Client und cached es. $fetch ist ein einfacher Aufruf ohne diese Behandlung.

Unterstützt Nuxt TypeScript?

Ja, mit generierten Typen für Routen und Server-APIs.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.