2026 SSR sur Mac distant :
Next.js & Nuxt — mémoire Node et concurrence de build
Public cible : devs front-end / full-stack en SSR (Next.js, Nuxt) sur Mac distant (SSH ou runner CI). Mots-clés runbook : Mac distant, Next.js, Nuxt, mémoire Node, concurrence de build. Objectif : paramètres exécutables versionnés avec votre YAML pour éviter les OOM opaques quand le nœud manque de marge. Liens : pnpm & Turborepo, isolation Node/npm, cache Vite/Webpack.
00 Trois douleurs récurrentes quand le SSR part en SSH
- Heap implicite — plafond V8 trop bas ; explosion en fin de minification ou collecte de pages.
- Concurrence involontaire — deux SSR en parallèle doublent le RSS et déclenchent le killer macOS.
- Caches fatigués —
.next/.nuxtobsolètes → écarts local vs runner.
01 Plafond mémoire et seuils de déclenchement OOM
La compilation SSR retient graphes de routes, bundles serveur et source maps en RAM. Sur Mac distant / CI/CD, échec typique : JavaScript heap out of memory, code 134 ou 137 sans stack lisible.
Seuil : si le RSS dépasse ~70 % du budget RAM du job avant pic prérendu/Nitro, zone à risque — les pointes viennent de la minification et du serveur, pas du premier passage TypeScript.
Correctif : plafond de tas V8 explicite avant le build :
- Tas par job :
export NODE_OPTIONS="--max-old-space-size=8192"(6144 sur hôtes 16 Go ; 12288–16384 seulement si la machine dispose réellement de marge et qu’un seul build lourd tourne à la fois). - Parité CI : répliquez la même chaîne
NODE_OPTIONSdans Actions, GitLab, Jenkins et votre session SSH afin d’aligner le nœud distant sur le portable de référence. - Bruit Next :
export NEXT_TELEMETRY_DISABLED=1pour les pipelines Next.js ; combinez avec des installations à lockfile gelé déjà documentées pour la supply-chain.
02 Workers concurrents et relation avec le CPU (tableau)
Les builds SSR mélangent CPU et RAM. Plus de workers sans bande passante mémoire multiplie les OOM parallèles. Le parallélisme utile = f(cœurs, tas par processus).
Plafonnez turbo run --concurrency pour éviter deux SSR en crête simultanée (Turborepo).
| Cœurs performance (profil M4 typique) | Builds SSR parallèles sûrs sur un hôte | Point de départ --max-old-space-size (Mo) |
Notes |
|---|---|---|---|
| 4 | 1 | 6144–8192 | Réserver RAM pour sshd, watchers et cache OS ; éviter Playwright lourd dans la même fenêtre. |
| 8 | 1 (grosses apps) / 2 (plus petites) | 4096–6144 chacun | Si routes >300 ou i18n dense, rester à 1 job ; mettre la seconde app en file. |
| 10+ | 2 | 4096–8192 chacun | Surveiller le swap ; si la pression mémoire passe au jaune dans Moniteur d’activité, redescendre à 1 job avant d’augmenter le heap. |
- Pool libuv :
UV_THREADPOOL_SIZE=8peut aider certaines dépendances natives ; gardez la valeur ≤ nombre de cœurs performance. - Tests vs build : limitez séparément les workers Jest/Vitest (
--maxWorkers=50%ou compte explicite) ; ne réutilisez pas les réglages « machine de build » pour les shards E2E.
03 Répertoires de cache et stratégie de nettoyage
Caches périmés sur Mac distant → dérives CI et disque plein. Distinctez reset comportement (framework) et ménage disque pour ne pas purger un cache chaud en incident.
- Next.js :
.next/,.next/cache/— reset : supprimer.nextavantnext build. - Nuxt 3 :
.nuxt/,.output/,node_modules/.cache/— purge forte si Nitro/routes changent. - pnpm : pas de suppression store ad hoc ;
pnpm store pruneaprès migrations. - Planning : cron ou job CI +
df -havant nightly.
04 FAQ sur la stabilité du nœud distant
Portable OK, Mac loué OOM ? NODE_OPTIONS différents, RAM plus étroite ou matrice parallèle (SSR + Storybook). Un job par étape, heap aligné.
Workers au max ? Non — RSS crête monte ; viser 50–100 % des cœurs perf. seulement si un build monopolise l’hôte.
Disque plein ? Next échoue sur .next/cache ; Nuxt/Vite corrompt l’incrémental. Libérer, purger caches, lockfile gelé, rebuild.
Rosetta ? Préférer Node arm64 ; x64 émulé gonfle RAM et ralentit le CI/CD.
05 Tableau comparatif Next.js / Nuxt et checklist
Référence pour doc interne ou Terraform ; complète le tableau CPU (leviers attendus en incident).
| Sujet | Next.js (SSR / App Router) | Nuxt 3 (Vite + Nitro) |
|---|---|---|
| Levier RAM principal | NODE_OPTIONS=--max-old-space-size=… autour de next build |
Même NODE_OPTIONS autour de nuxt build ; surveiller les pics Nitro |
| Répertoires de cache typiques | .next/, surtout .next/cache |
.nuxt/, .output/, node_modules/.cache |
| Esprit de parallélisation | Limiter les jobs matrice ; une grosse next build par fenêtre hôte |
Plafonner les builds Nuxt concurrents ; aligner upgrades Vite/Nitro avec bust de cache |
| Signal fumée CI/CD | Erreurs heap pendant « Collecting page data » ou prerender | OOM durant bundle serveur ou phases rollup Nitro |
- Checklist express : exporter
NODE_OPTIONSetNEXT_TELEMETRY_DISABLED(Next) dans le même shell que le build. - Imposer un seul build SSR lourd par étape sauf profilage RSS contraire.
- Versionner la suppression de cache (
.next/.nuxt/.output) derrière un drapeau runbook.
06 Cinq étapes CI/CD exécutables
NODE_OPTIONSfigés ;node -v= CI.- Une fenêtre par build SSR lourd ou
turbo run --concurrencybas. - Purge caches framework sur changements majeurs de branche.
- Log
uname -m,node -p process.arch, RAM libre en tête de job. df -havant nightly pour.next/.output.
- Heap : chaîne
NODE_OPTIONSobligatoire sur chaquenext build/nuxt builddistant. - Concurrence : un pic SSR à la fois sur hôte <32 Go sans métriques contraires.
- Cache : changement Nitro/App Router → bust
.next/.nuxt/.outputtracé.
Mémoire Node + concurrence = entrées couplées du CI/CD : pas de heap géant pour masquer du parallélisme SSR abusif. Caches Next.js / Nuxt cartographiés, nettoyage automatisé, toolchain arm64 sur Mac distant. Achat sans connexion · tarifs.
Mac Mini M4 pour builds SSR et CI/CD
RAM prévisible, Node arm64, espace disque pour .next et .output. Finalisez sur achat.html sans compte obligatoire, consultez tarifs et aide SSH/VNC.