Bisher lief unser Projekt ausschließlich über npm run dev – Vites Entwicklungs-Server mit Hot-Reload, aber NICHT für echte Nutzer gedacht. Dieses Kapitel zeigt den letzten Schritt: einen optimierten Produktions-Build erstellen und verstehen, was dabei passiert.

npm run build ausführen

npm run build

Das erzeugt einen dist/-Ordner mit statischen HTML-, CSS- und JavaScript-Dateien – KEIN Node.js-Server nötig, um sie auszuliefern (unser eigener Reviews-server/ aus "React für Einsteiger" Kapitel 25/26 ist eine separate, EIGENSTÄNDIGE Node-Anwendung und bleibt davon unberührt, muss GETRENNT deployt werden).

Was esbuild/Rollup unter der Haube macht

• Minifizierung: Variablennamen werden verkürzt, Leerzeichen/Kommentare entfernt – kleinere Dateigröße, für Menschen unlesbar, für den Browser identisch funktionsfähig.
• Tree Shaking: UNGENUTZTER Code (z. B. Funktionen aus react-window, die wir nie importiert haben) wird komplett aus dem finalen Bundle entfernt.
• Code-Splitting: Erinnern Sie sich an lazy() aus "React für Einsteiger" Kapitel 20? JEDE lazy()-importierte Seite (ReviewsPage, LoginPage, AccountPage, CartPage) wird zu einer EIGENEN, separat ladbaren Datei – Nutzer laden nur den Code der Route, die sie tatsächlich besuchen.
• Asset-Hashing: Dateinamen bekommen einen Inhalts-Hash (index-a3f8b2.js statt index.js) – ändert sich der Inhalt, ändert sich der Hash, wodurch Browser-Caching sicher und aggressiv genutzt werden kann (alte Version bleibt im Cache gültig, solange sich der Dateiname/Hash nicht ändert).

Den Build analysieren: was ist eigentlich drin?

npm run build zeigt am Ende eine Übersicht der erzeugten Dateien mit Größenangabe. Für eine TIEFERE Analyse (welches PAKET wie viel beiträgt) gibt es das Plugin rollup-plugin-visualizer:

npm install --save-dev rollup-plugin-visualizer

// In vite.config.js:
import { visualizer } from 'rollup-plugin-visualizer';

export default defineConfig({
  plugins: [react(), visualizer({ open: true })],
  // ... Rest der Konfiguration
});

Nach npm run build öffnet sich automatisch eine interaktive Grafik ("Treemap") – größere Kästen sind größere Pakete im Bundle. Ein häufiger Fund bei echten Projekten: EINE versehentlich importierte, riesige Bibliothek (z. B. die komplette lodash statt einer einzelnen Funktion daraus) dominiert die gesamte Grafik.

Umgebungsvariablen für unterschiedliche Umgebungen

Unsere src/api/reviewsApi.js und server/db.js haben feste URLs/Zugangsdaten fest im Code (http://localhost:4000, geheimespasswort) – praktisch für die lokale Entwicklung in diesem Tutorial, aber NICHT für einen echten Produktions-Build geeignet. Vite unterstützt .env-Dateien nativ:

VITE_API_BASE_URL=https://api.mein-produktkatalog.de

// In src/api/reviewsApi.js, statt der festen URL:
const BASE_URL = import.meta.env.VITE_API_BASE_URL;

Wo den dist-Ordner hosten?

Der dist/-Ordner ist reines statisches HTML/CSS/JS – hostbar auf JEDEM statischen Hosting-Dienst (Netlify, Vercel, Cloudflare Pages, GitHub Pages, ein einfacher Nginx-Webserver). Der Reviews-server/ braucht dagegen ein ECHTES Node.js-Hosting (Railway, Render, ein eigener VPS) – zwei UNTERSCHIEDLICHE Deployment-Ziele für die zwei Teile unseres Projekts.