Warum das Framework die Server-Größe bestimmt
SSR-Frameworks wie Next.js und Nuxt rendern jede Seite auf dem Server. Das kostet CPU pro Request. Statische Frameworks liefern fertige HTML-Dateien aus und brauchen fast nichts.
Der Runtime-Footprint unterscheidet sich zwischen Frameworks. Eine kleine Next.js-SSR-App belegt ca. 0,5-0,7 GB RAM im Idle. Nuxt SSR liegt bei ca. 0,3-0,5 GB. Das sind Richtwerte aus Community-Reports, keine Benchmarks. Deine echten Werte hängen von App-Komplexität und Middleware ab.
Für die meisten kleinen Projekte bestimmt die Datenbank und der Framework-Basis-Footprint die VPS-Größe. Der Traffic-Term dominiert erst ab ca. 100.000 monatlichen Besuchern.
Next.js auf einem VPS: Worauf achten
Next.js wurde um Vercel herum entworfen. Auf einem eigenen VPS gibt es drei typische Stolperfallen:
Bildoptimierung: next/image nutzt die native sharp-Library auf deiner CPU. Auf kleinen Instanzen teilen sich Bildoptimierung und Requests dieselben Kerne. In Docker-Builds fehlt sharp regelmäßig.
ISR-Cache: Standardmäßig speichert Next.js den ISR-Cache lokal. Bei mehreren Instanzen divergieren die Caches. Die Lösung ist ein custom cacheHandler mit Redis.
Cloudflare und ISR: ISRs stale-while-revalidate braucht ein CDN, das den Header unterstützt. Cloudflare tut das nicht. Das typische "VPS hinter Cloudflare"-Setup bekommt das ISR-Verhalten nicht.
Mehr Details in unserem Blog-Artikel zu Next.js vs Nuxt.
Nuxt als leichtere Alternative
Nuxts Server-Engine Nitro erzeugt einen portablen .output-Ordner. Ein Befehl startet den Server:
node .output/server/index.mjs
Keine Plattform-Annahmen, kein Edge-Netzwerk nötig. Die Caching-Policy lebt in routeRules an einer Stelle. Eine vergleichbare kleine SSR-App passt mit Nuxt oft eine VPS-Stufe unter dem äquivalenten Next.js-Setup.
