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>| Composable | Einsatz |
|---|---|
useFetch | URL während des Renderns abrufen, SSR und Caching inklusive |
useAsyncData | Beliebige asynchrone Funktion mit demselben Caching |
$fetch | Einfacher HTTP-Aufruf ohne Render-Integration, für Aktionen und Events |
useState | SSR-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
| Nuxt | Next.js | SvelteKit | |
|---|---|---|---|
| Basis | Vue 3 | React | Svelte |
| Server-Engine | Nitro | Next.js-Runtime | Adapter |
| Auto-Imports | Ja, standardmäßig | Nein | Nein |
| Dateibasiertes Routing | Ja | Ja | Ja |
Alle drei decken dasselbe ab, entscheidend ist daher meist die UI-Bibliothek, die das Team schon kennt.
Häufige Fehler
$fetchbeim Rendern. Der Server lädt, der Client lädt noch einmal, die Seite flackert oder lädt doppelt. Für Daten beim RendernuseFetchoderuseAsyncDataverwenden.- Browser-APIs auf dem Server.
windowundlocalStoragegibt es beim SSR nicht; absichern oder inonMountedausfü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.
Verwandte Begriffe
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um, derselben Plattform, die alles antreibt, was du gerade gelesen hast.