// next.config.js
module.exports = {
// Dezactivează source-map-urile pe producție dacă nu ai neapărat nevoie de ele.
// Generarea lor consumă enorm de multă memorie RAM.
productionBrowserSourceMaps: false,
experimental: {
// Limitează numărul de worker threads pentru CPU-urile slabe de pe VPS-urile ieftine
cpus: 1,
workerThreads: false,
},
}Salutare! Am văzut discuția asta de zeci de ori pe forumuri și am pățit-o și eu acum vreo două luni pe un proiect mediu, cu vreo 4.000 de pagini. În local zburda totul în 12-15 secunde, dar când dădeam deploy pe un VPS de 6 euro de la Hetzner, build-ul dura peste 8 minute. Uneori chiar îngheța serverul complet.
Dacă ești în aceeași situație, nu dispera. Nu e neapărat Next.js de vină, ci resursele limitate și modul în care rulează build-ul în producție comparativ cu modul de development. Hai să-ți zic ce am verificat eu și cum am redus build time-ul la sub un minut.
1. RAM-ul și inamicul invizibil: OOM Killer
Cele mai multe VPS-uri ieftine au 1GB sau 2GB RAM. Când rulezi next build, compilerul SWC (scris în Rust, destul de gurmand) încearcă să folosească toate nucleele CPU disponibile și mănâncă RAM ca un monstru.
Dacă serverul rămâne fără memorie, kernelul Linux pur și simplu omoară procesul (Out of Memory Killer) sau intră în "swap thrashing" – adică mută datele pe SSD încontinuu pentru că nu mai are loc în RAM. De aici vine încetinirea masivă.
Cum verifici? Deschide un al doilea terminal pe VPS și rulează htop în timp ce pornești build-ul. Dacă vezi memoria pe roșu (100%) și swap-ul plin, ai găsit buba. Soluția rapidă este să adaugi un fișier swap de 2-4GB. Nu e ideal pentru SSD pe termen lung, dar salvează build-ul de la moarte.
2. Generarea de pagini statice (SSG) la build time
Dacă ai pagini dinamice care folosesc getStaticPaths cu mii de ID-uri și nu ai setat fallback: 'blocking', Next.js va încerca să randeze absolut toate acele pagini în HTML și JSON în timpul build-ului. În modul dev (next dev), Next nu randează paginile statice în avans, ci doar la cerere. De aceea pe laptop e instant.
Cum rezolvi asta? Folosește fallback: 'blocking' sau fallback: true pentru rutele dinamice. Lasă build-ul să genereze doar cele mai importante 50-100 de pagini (de exemplu, cele mai accesate produse), iar restul lasă-le să se genereze în background, la prima accesare a utilizatorului.
3. Lipsa cache-ului (.next/cache)
Dacă faci deploy-ul printr-un pipeline de CI/CD sau o imagine Docker care se reconstruiește de la zero la fiecare deploy (fără volume persistente), pierzi cache-ul Next.js. Next cachează rezultatele compilării anterioare în .next/cache. Fără el, fiecare build pornește complet de la zero.
La proiectul meu de care spuneam mai sus, păstrarea cache-ului între deploy-uri a redus timpul de build cu aproape 60%.
Trade-off-ul pe care trebuie să-l accepți
Poți să optimizezi setările webpack în next.config.js ca să limitezi numărul de thread-uri și să dezactivezi generarea de sourcemaps. Merge excelent ca să nu-ți blochezi complet VPS-ul în timpul deploy-ului (utilizatorii tăi îți vor mulțumi pentru că site-ul nu va mai pica în timpul build-ului), dar dezavantajul e că build-ul va dura ceva mai mult pe un singur core.
Alternativa reală? Nu mai face build direct pe VPS-ul de producție. Fă build în GitHub Actions (unde ai resurse destul de generoase pe runnerii moca) și urcă doar artefactul final (.next și node_modules) pe VPS. E mai curat, dar necesită un pic de bibileală la setup-ul de CI/CD.
Voi cum faceți deploy la Next.js pe servere proprii? Mergeți pe build direct pe VPS sau folosiți un pipeline extern?