Sincer, nimic nu e mai frustrant decât să dai un push și să aștepți 10 minute să vezi dacă crapă ceva în producție. Am avut cazul ăsta recent la un proiect cu vreo 8k de useri activi, unde pe local totul zbura în câteva secunde, dar pe un VPS cu 2 vCPU și 4GB RAM, next build parcă mergea în reluare. Diferența asta uriașă dintre mediul de dezvoltare și server vine de obicei din trei locuri: resurse hardware limitate, lipsa cache-ului și procesele de validare pe care le ignorăm în dev.
Prima oprire: RAM-ul și Swap-ul
Next.js e un mâncător de resurse când vine vorba de compilare, mai ales dacă folosești intensiv imagini sau pagini generate static (SSG). Pe laptop ai probabil 16GB sau 32GB RAM și un procesor cu multe nuclee care mănâncă task-urile pe pâine. Pe un VPS ieftin, când procesul de build atinge limita de memorie, sistemul de operare începe să facă 'swapping' pe disc.
Dacă discul nu e un NVMe foarte rapid, viteza scade dramatic. Am pățit ca un build să stea blocat minute în șir doar pentru că făcea swap agresiv. Am rezolvat temporar mărind swap-ul la 4GB, dar soluția reală a fost limitarea memoriei pentru Node. Am folosit NODE_OPTIONS="--max-old-space-size=3072" ca să-i spun procesului să nu încerce să înghită tot ce prinde și să forțeze garbage collector-ul mai des. A salvat cam 2 minute din start.
Cache-ul de build e sfânt
În dev, Next.js păstrează un cache persistent în folderul .next/cache. Când rulezi build-ul pe un server de CI/CD sau direct pe VPS, dacă ștergi folderul de proiect la fiecare deploy, pierzi toată optimizarea asta. E ca și cum ai învăța de la zero la fiecare examen.
La proiectul menționat, am observat că re-generarea imaginilor și a paginilor statice dura 70% din timp. Am configurat scriptul de deploy să păstreze folderul .next/cache între build-uri. Rezultatul? Build time-ul a scăzut de la 8 minute la sub 4 minute. E un trade-off sincer aici: ocupi mai mult spațiu pe disc, dar câștigi timp prețios și scapi de uzura inutilă a procesorului.
Type checking și Linting: chiar e nevoie de ele la build?
Implicit, next build rulează tsc (TypeScript) și eslint. Pe un VPS cu procesor slab, asta poate dura o veșnicie. Dacă ai deja un pipeline de CI (GitHub Actions sau GitLab CI) care verifică tipurile și lint-ul înainte de merge, poți să le sari liniștit la build-ul final pe server.
Am adăugat în next.config.js opțiunile ignoreDuringBuilds pentru ambele. Am mai economisit vreo 90 de secunde așa. Totuși, e nasol dacă nu ai verificările astea automate în altă parte, că te poți trezi cu erori de runtime pe care TypeScript le-ar fi prins imediat.
Output Standalone
Dacă folosești Docker sau un VPS curat, activează output: 'standalone'. Asta face ca Next.js să copieze doar fișierele strict necesare pentru runtime, ignorând tonele de module din node_modules care nu sunt folosite în producție. Nu scade neapărat timpul de build în sine, dar scade enorm timpul de deployment și mărimea artefactului final.
În final, am reușit să aducem build-ul la vreo 3 minute și jumătate. Nu e ca cele 12 secunde de pe local, dar e rezonabil pentru un server de 10 euro pe lună. Voi cum gestionați build-urile mari? Mergeți pe varianta 'build on server' sau faceți build-ul într-un pipeline extern și livrați doar artefactele gata comprimate?