BENCHMARKS · 29 OCTOBRE 2026
Quand le CPU est contraint, réduire son coût par réponse peut aider. Mais sur un petit serveur, quelques Mio de plus comptent aussi. Ce cas montre pourquoi les deux mesures doivent rester côte à côte.
Mesuré : candidat PRNext 0.1.18-alpha, distinct de l’archive finale npm. Détails et empreintes ci-dessous. Quel code a été mesuré ?
Sur la page de 100 lignes, le candidat PRNext consomme environ 37 % de CPU en moins par réponse et délivre 59 % de requêtes validées en plus que Next.js. Sa PSS médiane est toutefois supérieure d’environ 12 %. Le résultat peut intéresser une application limitée par le CPU, sans démontrer une économie de RAM.
Le budget impose un quota de 0,7 CPU et une limite mémoire de 700 Mio sur un hôte de 1 vCPU et 1,9 Gio. Le générateur partage ce CPU physique. Les mesures décrivent donc ce montage précis, avec sa contention, et non tous les petits VPS du marché.
Le streaming inclut une attente Suspense de 40 ms. Son CPU par réponse baisse d’environ 42 % avec PRNext, tandis que sa mémoire reste plus élevée. L’attente fait partie du scénario : cette route ne représente pas toute application qui utilise le streaming.
La page de 1 000 lignes augmente fortement le coût CPU pour les deux runtimes. Sur ce budget, PRNext garde un petit avantage de débit, mais seulement deux fenêtres ne suffisent pas à considérer cet écart comme stable. Pour une API rapide, contrôlez aussi le signal de limitation du générateur avant de tirer une conclusion.
Mesurez le serveur avec vos dépendances et votre base de données, puis gardez une marge pour les pointes. Une PSS mesurée sous une limite de 700 Mio ne signifie pas qu’un VPS de 700 Mio suffit : le système, les autres services et la charge réelle ont aussi besoin de mémoire. Validez enfin la compatibilité de vos routes avant de changer de runtime.
Quota 0,7 CPU · 700 Mio · Node 22.23.4 · 1 worker PRNext · 1 processus Next.js · old-space 384 Mio
Plus haut pour le débit, plus bas pour la latence, le CPU et la mémoire.
| Mesure | PRNext candidat | Next.js 16.4.3 |
|---|---|---|
| Débit validéreq/s | 81,33 | 51,00 |
| Latence p95ms | 264,25 | 420,90 |
| CPU / réponsems CPU | 8,46 | 13,39 |
| Mémoire PSSMio | 113,88 | 101,38 |
| Mesure | PRNext candidat | Next.js 16.4.3 |
|---|---|---|
| Débit validéreq/s | 11,33 | 10,33 |
| Latence p95ms | 1 550,25 | 1 661,80 |
| CPU / réponsems CPU | 58,92 | 62,10 |
| Mémoire PSSMio | 139,51 | 119,46 |
| Mesure | PRNext candidat | Next.js 16.4.3 |
|---|---|---|
| Débit validéreq/s | 518,17 | 352,80 |
| Latence p95ms | 61,40 | 90,05 |
| CPU / réponsems CPU | 1,27 | 1,94 |
| Mémoire PSSMio | 139,63 | 113,08 |
Le générateur peut limiter le débit de ce scénario. Un écart faible ne suffit pas à départager les runtimes.
| Mesure | PRNext candidat | Next.js 16.4.3 |
|---|---|---|
| Débit validéreq/s | 138,13 | 80,03 |
| Latence p95ms | 182,65 | 307,25 |
| CPU / réponsems CPU | 4,98 | 8,62 |
| Mémoire PSSMio | 135,32 | 115,54 |
La campagne du 2026-10-29 utilise React 19.3.1, le profil PRNext Balanced et gzip. Chaque variante passe par 5 secondes de chauffe, puis 15 secondes de mesure avec 16 connexions. Les valeurs affichées sont les médianes de deux fenêtres alternées par variante, route et budget.
Le débit compte les réponses réussies et validées. Le CPU est le temps CPU consommé par réponse réussie. La RAM est la PSS médiane de l’arbre des processus, en Mio ; elle ne représente ni le RSS, ni toute la mémoire du VPS. La latence affichée est la médiane des deux p95, pas un p95 recalculé sur toutes les requêtes.
PRNext est un candidat de développement pour 0.1.18-alpha, dont le manifeste indique 0.1.17-alpha. Next.js est en version 16.4.3. La version finale 0.1.18-alpha n’a pas été mesurée par cette campagne : ces chiffres ne constituent pas une mesure de son archive npm.
Deux répétitions courtes sur une application synthétique ne donnent pas d’intervalle de confiance. Le petit VPS partage son CPU avec le générateur de charge et les routes API rapides peuvent être limitées par celui-ci. Les machines et versions de Node diffèrent entre les hôtes : comparer les budgets ne permet pas d’isoler l’effet du matériel.
Ces mesures ne donnent pas le nombre d’utilisateurs simultanés de votre produit, le nombre de projets qu’un VPS peut héberger, ni une économie sur une facture. Une base de données, des appels externes, les caches, le navigateur et le réveil d’une application changent le résultat. Les observations de veille et d’endurance restent dans le comparatif complet.
Commencez par vos routes les plus visitées et les plus coûteuses. Vérifiez le contenu et les erreurs avant de comparer la vitesse. Gardez le même quota, les mêmes dépendances, les mêmes réglages de cache et la même charge pour les deux runtimes. Répétez des fenêtres plus longues avant de décider.