// next.config.js
module.exports = {
output: 'standalone', // Generează doar fișierele necesare rulării
productionBrowserSourceMaps: false,
typescript: {
// Ignorăm la build dacă facem deja type-check în CI
ignoreBuildErrors: true,
},
eslint: {
// Previne rularea linter-ului în timpul compilării pe server
ignoreDuringBuilds: true,
},
}Am pățit-o chiar acum o lună la un proiect cu vreo 12k utilizatori activi. Pe MacBook-ul meu build-ul de Next.js era gata în 15-20 de secunde, dar pe VPS-ul de 6 euro de la Hetzner dura aproape 9 minute sau, mai rău, murea direct cu Out of Memory.
Dacă ești în situația asta, nu te grăbi să arunci cu bani într-un server mai scump. De cele mai multe ori, problema e la cum își gestionează Next.js resursele în timpul compilării.
1. Limita de RAM și lipsa Swap-ului
Next.js (mai ales de la versiunea 13+ cu App Router) este extrem de flămând după memorie în timpul fazei de next build. Webpack și minificatorul SWC mănâncă RAM pe pâine. Pe un VPS cu sub 4GB RAM, sistemul de operare va începe să omoare procesele (OOM Killer) sau va intra în thrashing.
Soluția rapidă pe care am aplicat-o a fost crearea unui fișier Swap de 4GB. Chiar dacă SSD-ul este mai lent decât memoria RAM fizică, Swap-ul previne blocarea completă a procesorului și crash-ul build-ului.
2. Source-maps active în producție
Verifică imediat fișierul tău next.config.js. Ai cumva opțiunea productionBrowserSourceMaps pusă pe true? Mulți o activează pentru debug ușor în producție, dar asta înseamnă că la build Next.js trebuie să genereze fișiere uriașe de mapare pentru tot codul tău.
Pe mașina ta locală nu se simte atât de mult, dar pe un VPS cu un singur vCPU, generarea de source maps dublează timpul de build. Oprește-le și folosește un tool dedicat de monitorizare a erorilor dacă ai nevoie de stack traces clare.
3. Ignoră chestiile redundante la build
Dacă ai deja un pipeline de CI/CD (de exemplu, GitHub Actions) unde rulezi ESLint și TypeScript type checking, nu are absolut niciun rost să le rulezi din nou pe VPS în timpul build-ului final.
Poți să spui lui Next.js să sară peste aceste verificări în faza de compilat. Am economisit peste 30% din build time doar dezactivând verificarea de tipuri și linter-ul pe server, deoarece făceam deja asta la push.
4. Cache-ul pierdut între deploy-uri
Dacă folosești Docker pe VPS fără să montezi un volum pentru folderul .next/cache, Next.js pornește de fiecare dată de la zero absolut. Nu va putea refolosi nimic din imaginile optimizate anterior sau paginile statice deja generate.
Păstrarea cache-ului între build-uri este probabil cea mai subestimată optimizare. Asigură-te că directorul .next/cache supraviețuiește repornirilor de containere.
Trade-off: Build pe server vs. Build local
Cel mai bun trade-off pe care l-am găsit pentru proiectele medii? Nu mai face build pe VPS. Fă build-ul local sau în GitHub Actions, împachetează totul într-o imagine Docker ușoară folosind opțiunea standalone din Next, apoi trage imaginea pe VPS.
E adevărat că asta adaugă puțină complexitate la setup-ul de CI/CD, dar scapi complet de stresul că serverul de producție va crăpa în timp ce utilizatorii încearcă să acceseze site-ul.
Tu cum procedezi? Rulezi next build direct pe serverul de producție sau preferi să livrezi imagini Docker gata construite?