BENCHMARKS · 29 OCTOBRE 2026
Un runtime se choisit sur les routes de votre application. Explorez quatre budgets de ressources et quatre scénarios, puis regardez ce que chaque résultat permet vraiment de conclure.
Mesuré : candidat PRNext 0.1.18-alpha, distinct de l’archive finale npm. Détails et empreintes ci-dessous. Quel code a été mesuré ?
Quota 2 CPU · 1 Gio · Node 24.22.1 · 1 worker PRNext · 1 processus Next.js · old-space 384 Mio
Ces valeurs sont des quotas de ressources, pas les caractéristiques de serveurs dédiés.
| Mesure | PRNext candidat | Next.js 16.4.3 |
|---|---|---|
| Débit validéreq/s | 224,70 | 142,97 |
| Latence p95ms | 89,75 | 154,55 |
| CPU / réponsems CPU | 7,57 | 10,29 |
| Mémoire PSSMio | 117,50 | 173,30 |
Plus haut pour le débit, plus bas pour la latence, le CPU et la mémoire.
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.
Lire les résultats et les compromis →Le SSR de 100 lignes et celui de 1 000 lignes ne racontent pas la même histoire. À ressources identiques, la route exécutée peut changer le choix du runtime.
Lire les résultats et les compromis →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.