PRNext 0.1.18 face à Next.js : CPU, RAM et mise en veille

#La version exacte derrière les chiffres

Les mesures du 29 octobre 2026 portent sur le candidat de développement de la 0.1.18-alpha, au commit 2856155. Son manifeste conservait encore le numéro interne 0.1.17-alpha, mais son code et ses optimisations diffèrent du paquet npm 0.1.17-alpha. Le code source mesuré et ses empreintes sont liés en fin d’article.

La référence est Next.js 16.4.3, avec la même famille React 19.3.1 et la même application source. Le petit VPS utilise Node.js 22.23.4 ; le grand utilise Node.js 24.22.1. Sur chaque machine, tous les moteurs utilisent exactement le même exécutable Node. Comparer les deux machines entre elles ne permet pas d’isoler un effet matériel, puisque Node change aussi.

Le profil PRNext mesuré est Balanced, avec le moteur de rendu Web par défaut. Les empreintes complètes du binaire Linux et du paquet candidat, les valeurs avant correction et les plages de débit sont fournies dans les données associées. La version npm 0.1.18-alpha publiée le 30 octobre provient du commit 05a9ccd, avec des corrections supplémentaires de build et de développement. Cette campagne ne mesure donc ni le paquet npm 0.1.17-alpha ni les archives finales de la 0.1.18-alpha. Les chiffres décrivent précisément le candidat identifié, sans attribuer un nouveau benchmark aux changements ultérieurs.

#Ce que nous avons mesuré

Le premier VPS dispose d’un vCPU et d’environ 1,9 Gio de RAM. Le second dispose de huit vCPU et d’environ 23 Gio. Les processus testés reçoivent des plafonds CPU et mémoire via cgroup v2, sans swap. La petite machine est limitée à 70 % d’un CPU et 700 Mio ; la grande est testée avec 1 CPU et 384 Mio, 2 CPU et 1 Gio, puis 4 CPU et 2 Gio.

La matrice principale contient 96 fenêtres : quatre budgets, quatre scénarios, trois variantes et deux passages en alternance. Les variantes sont PRNext avant les corrections, le candidat PRNext testé et Next.js. Chaque fenêtre comporte cinq secondes de chauffe puis quinze secondes mesurées, avec seize connexions et gzip. Les tableaux comparent le candidat à Next.js et donnent la médiane des deux fenêtres pour chaque indicateur.

Les scénarios sont une page SSR dynamique de 100 lignes, une page de 1 000 lignes, une API JSON de seize entrées et une page avec Suspense retardé de 40 ms. Un identifiant frais et des cookies vérifient que les réponses sont correctes et isolées. Le débit compte uniquement les réponses réussies et validées. Ce n’est pas un test de pages statiques servies depuis un CDN.

Le p95 décrit le délai sous lequel se terminent 95 % des requêtes d’une fenêtre. Le CPU est exprimé en millisecondes de travail CPU par réponse réussie, pas en latence. La RAM est la mémoire proportionnelle, ou PSS, médiane de l’arbre de processus : le moteur natif et les workers Node sont inclus. Une réponse peut prendre 100 ms tout en ne consommant que quelques millisecondes de CPU.

Le générateur de charge est séparé des serveurs par ses propres limites, mais partage l’unique CPU physique du petit VPS. Les API très rapides peuvent atteindre sa limite, notamment sur la petite machine et dans le scénario à 4 CPU. Les services déjà présents restent actifs : les quotas ne suppriment pas la contention de ces VPS. Deux passages courts ne donnent pas un intervalle de confiance ; les petits écarts ne doivent pas devenir des promesses commerciales.

#Petit VPS : moins de CPU, sans victoire générale sur la RAM

Avec 0,7 CPU et 700 Mio, PRNext sert 81,33 réponses SSR par seconde contre 51 pour Next.js. Son p95 est de 264,25 ms contre 420,90 ms. Le coût CPU passe de 13,39 à 8,46 ms par réponse, soit environ 37 % de moins. En revanche, la mémoire mesurée est de 113,88 Mio contre 101,38 Mio : PRNext utilise environ 12 % de plus sur cette page.

Le streaming atteint 138,13 requêtes par seconde contre 80,03, avec environ 42 % de CPU en moins par réponse. La page lourde est beaucoup plus proche : 11,33 contre 10,33 requêtes par seconde. L’API est favorable à PRNext dans cette campagne, mais le partage du CPU avec le générateur impose de garder sa limite en tête.

Sur cette machine, PRNext consomme davantage de PSS que Next.js dans les quatre scénarios. Le bénéfice observé est principalement une meilleure efficacité CPU sur le SSR courant et le streaming. Dire simplement « moins de RAM » serait faux pour ces résultats.

#Un CPU et 384 Mio : une autre contrainte, un autre compromis

Sur le grand VPS limité à 1 CPU et 384 Mio, la page SSR atteint 99,77 requêtes par seconde contre 59,90. Le coût CPU est inférieur d’environ 41 % et la PSS de 13 %. Le streaming atteint 220,90 contre 86,27 requêtes par seconde, avec 4,51 contre 11,47 ms de CPU par réponse.

La politique mémoire plus serrée du candidat réduit aussi la RAM par rapport à notre ancien PRNext, mais l’API perd environ 13 % de débit face à cet ancien code. PRNext reste devant Next.js sur cette mesure ; cela n’efface pas la régression interne. Il faut continuer à travailler sur le compromis entre collecte mémoire et débit.

#Deux CPU : un gain net en SSR courant, une limite en rendu lourd

Avec 2 CPU et 1 Gio, la page SSR de 100 lignes passe à 224,70 requêtes par seconde pour PRNext contre 142,97 pour Next.js. Cela représente 57 % de débit supplémentaire, environ 26 % de CPU en moins par réponse et 32 % de PSS en moins. Le p95 est de 89,80 ms contre 154,60 ms.

La page de 1 000 lignes inverse le résultat : Next.js atteint 27,63 requêtes par seconde contre 24 pour PRNext, avec un p95 de 622,20 ms contre 740,80 ms. PRNext utilise moins de RAM, mais environ 29 % de CPU supplémentaire par réponse. Le rendu React lourd reste un axe d’amélioration concret.

Le streaming conserve un gain de débit d’environ 56 % et un coût CPU inférieur d’environ 30 %. Ces résultats concernent cette application dynamique, ce profil et ce budget, pas tous les projets React.

#Quatre CPU : la topologie compte aussi

Pour le budget de 4 CPU et 2 Gio, PRNext utilise deux workers. Next.js utilise deux processus derrière un proxy Node privé ; le CPU et la RAM de ce proxy sont comptés. Les trois autres budgets utilisent des serveurs directs. Cette différence de topologie doit accompagner la lecture des chiffres.

PRNext atteint 383,30 requêtes SSR par seconde contre 247,13 pour cette référence Next.js. Sa PSS est de 206,60 Mio contre 458,33 Mio. L’écart ne prouve pas une économie universelle de 55 % de RAM : une autre topologie ou un proxy différent pourrait modifier le résultat. L’API peut également être limitée par le générateur.

Le candidat perd environ 10 % de débit SSR face à notre ancien PRNext sur ce budget, et environ 6 % sur la page lourde. Ajouter des CPU ne garantit donc pas que tous les chemins progressent. La montée en charge et les allocations du rendu lourd restent à améliorer.

#Navigation : corriger notre propre régression

Le premier audit avait identifié un retour anormalement lent vers une grande page. Le transport différentiel Flight produisait trop de petits fragments. Le candidat borne le travail de comparaison, regroupe les données disponibles et conserve un repli vers la réponse complète lorsque la différence n’est pas intéressante. Le but est de réduire le travail sans retarder les prochains fragments de streaming.

Dans Chromium 153, nous avons répété le parcours grande page, petite page, retour à la grande page. Chaque parcours vérifie 3 000 cellules visibles, l’état du compteur et l’identité du document. Sur le petit VPS, le retour PRNext passe de 1 475,6 à 307,2 ms ; sur le grand, de 932,1 à 228,6 ms.

Le gain d’environ quatre à cinq fois concerne notre ancien PRNext, pas Next.js. Le candidat reste légèrement derrière Next.js sur le petit VPS pour ce parcours et passe devant sur le grand. Les huit contextes par variante sont exécutés depuis un PC via un tunnel : ce ne sont pas des Core Web Vitals collectés chez des visiteurs.

L’hydratation ne bénéficie pas du même progrès. Sa médiane est de 421,6 ms pour PRNext contre 349,8 ms pour Next.js sur le petit VPS, et de 399,2 contre 299,1 ms sur le grand. Transférer moins d’octets ne suffit pas à rendre le client interactif plus tôt.

#Mode sleep : libérer la RAM entre deux visites

Un site peu visité ne passe pas sa journée à saturer le processeur. Sa mémoire au repos peut devenir plus importante que son débit maximal. PRNext peut arrêter ses workers Node après une période d’inactivité tout en conservant le serveur Rust à l’écoute. La prochaine requête de rendu recrée les workers nécessaires.

Nous avons testé ce mécanisme sur le petit VPS avec une page SSR simple et un délai d’inactivité accéléré à deux secondes. La mesure est prise après l’arrêt des workers, observé après environ deux secondes ; le contrôle maintenu à chaud attend environ six secondes. Il s’agit d’une sonde fonctionnelle unique par réglage, distincte des tests de charge et d’endurance.

Dans cette sonde, la PSS descend autour de 10,5 Mio quand les workers sont arrêtés, contre 106,8 Mio en maintien à chaud. Le prix est visible sur la requête de réveil : environ 1,13 seconde contre 22,6 ms. Ces 10,5 Mio décrivent l’arbre de processus de cette petite application dans cet état. Ce n’est ni la consommation totale du VPS ni une promesse pour toutes les applications.

Le préchauffage au lancement, avec --prewarm, prépare le framework avant d’accepter les requêtes. Il n’empêche pas un arrêt ultérieur au repos et n’exécute pas les pages ni les API applicatives. Pour conserver les hôtes de rendu utilisés, le réglage explicite est --worker-idle-seconds 0. Choisir le préchauffage seul ne supprime donc pas le coût d’un réveil après mise en veille.

Aucun mode de mise en veille équivalent n’a été configuré pour Next.js dans cette sonde. Nous ne concluons pas que Next.js ne peut pas être arrêté ou relancé par une infrastructure externe.

#Les avantages indirects pour un hébergement partagé

Pour plusieurs petits projets consultés à des moments différents, libérer la mémoire des workers inactifs peut laisser davantage de place aux applications actives. Une meilleure efficacité CPU peut aussi laisser plus de travail utile dans le même quota. C’est un intérêt possible pour les sites vitrines, les environnements de démonstration et les outils internes intermittents.

Ce raisonnement reste une conséquence possible des mesures, pas un test de densité d’hébergement. Nous n’avons pas déterminé combien de projets supplémentaires tiennent sur un serveur, ni mesuré une facture ou une économie d’énergie. Le système, la base de données, la passerelle, les pointes simultanées et les réveils consomment eux aussi des ressources.

Le framework possède également une commande locale prnext host qui peut mettre une application entière en veille derrière une passerelle. C’est un mécanisme distinct de l’arrêt des workers mesuré ici. La passerelle demeure active ; les requêtes et connexions suivies protègent le travail en cours, puis une nouvelle visite peut réveiller l’application. Cette campagne ne chiffre pas son coût global.

La mise en veille détruit l’état conservé uniquement dans les processus. Les données durables doivent rester sur disque ou dans un service adapté ; un travail de fond non suivi ne doit pas dépendre d’un processus maintenu vivant. Le service managé PRNext Host est encore une autre couche : cet article ne mesure pas ses tarifs ni ses performances de déploiement.

#Stabilité observée et limites du test

Six essais de charge mixte de dix minutes couvrent les trois variantes sur les deux VPS. Chaque essai est suivi de trente annulations de streaming puis de 46 secondes au calme. Aucun échec de contenu, aucune erreur de charge et aucun arrêt pour dépassement mémoire du serveur testé n’ont été observés dans ces campagnes finales.

Une première tentative d’endurance a révélé une rétention mémoire dans le générateur de charge, pas dans le serveur testé. Après correction de l’outil, les six essais finaux ont été rejoués intégralement avec le même générateur corrigé. Le lien vers cet outil pointe sur le commit fb59284, distinct du commit du moteur mesuré.

La mémoire continue de varier : sur le grand VPS contraint, PRNext passe de 119,0 à 130,4 Mio entre la première et la dernière minute. Son débit mixte est d’environ 12 % inférieur à celui de notre ancien PRNext sur cette configuration. Dix minutes ne prouvent ni l’absence de fuite ni la stabilité sur plusieurs semaines.

Après annulation et attente, les descripteurs de fichiers PRNext retombent à 44. Cette observation ne suffit pas à déclarer une fuite, ni à l’exclure à long terme. Les vérifications navigateur ajoutent 48 contextes chronométrés et dix contrôles fonctionnels, dont des replis forcés. Elles ne démontrent pas une compatibilité complète avec tous les projets Next.js.

#Ce que ces résultats changent pour PRNext

L’argument le plus solide est l’efficacité CPU du SSR courant et du streaming dans plusieurs budgets restreints. La mémoire peut aussi être favorable, mais elle ne l’est pas sur le petit VPS physique de cette campagne. Le mode sleep apporte un choix supplémentaire pour les projets intermittents : libérer de la RAM ou préserver une réponse chaude.

Les prochaines priorités sont les allocations du rendu lourd, l’hydratation, les régressions de débit sous certains budgets et la montée en charge à plusieurs workers. Les quelques mesures de compilation de cette campagne ne suffisent pas non plus à annoncer une amélioration générale des builds.

PRNext reste expérimental et sa compatibilité Next.js est partielle. Pour décider s’il convient à votre application, reproduisez ses routes coûteuses, son trafic, ses périodes creuses et ses réveils avec un artefact identifié. Les données de cet article donnent un point de départ vérifiable, pas un classement universel des frameworks.