# PRNext vs Next.js avec 2 CPU · 1 Gio : SSR et rendu lourd Budget de 2 CPU et 1 Gio : PRNext gagne en SSR dans cette campagne, mais Next.js garde l’avantage sur le rendu lourd. Chiffres, conditions et limites. 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. ## SSR : un gain sur les quatre mesures Sur la page de 100 lignes, le candidat PRNext atteint environ 57 % de débit supplémentaire avec 26 % de CPU en moins par réponse et 32 % de PSS en moins que Next.js. Le p95 est également inférieur. Ce résultat décrit une page synthétique sous charge, pas la vitesse de toutes les navigations d’un utilisateur. Les deux serveurs sont directs, avec un worker PRNext et un processus Next.js, Node 24.22.1 et une limite mémoire de 1 Gio. Le quota de 2 CPU est appliqué sur un hôte de 8 vCPU et 23 Gio. Ce n’est donc pas un benchmark d’une machine physique à deux cœurs. ## Sur 1 000 lignes, Next.js prend l’avantage Le candidat PRNext livre environ 13 % de requêtes en moins et consomme 29 % de CPU en plus par réponse sur le rendu lourd. Sa mémoire reste inférieure. Si ce travail domine votre application, le gain du SSR court ne suffit pas à justifier une migration. Le streaming présente de son côté un gain de débit pour PRNext dans cette campagne. Une API JSON courte peut être limitée par le générateur : mieux vaut garder les chiffres et leur réserve ensemble que construire un classement à partir d’un seul test. ## Choisir à partir du mélange de routes Identifiez la part du trafic qui rend de gros arbres React, celle qui attend des services externes et celle qui renvoie du JSON. Rejouez ce mélange avec un cache représentatif et des contenus vérifiés. Le meilleur résultat sur une route sert à formuler une hypothèse ; la charge de votre application permet de la confirmer ou de l’écarter. ## 2 CPU · 1 Gio Quota 2 CPU · 1 Gio · Node 24.22.1 · 1 worker PRNext · 1 processus Next.js · old-space 384 Mio ### SSR · 100 lignes | Mesure | PRNext candidat | Next.js 16.4.3 | | --- | --- | --- | | Débit validé (req/s) | 224,70 | 142,97 | | Latence p95 (ms) | 89,75 | 154,55 | | CPU / réponse (ms CPU) | 7,57 | 10,29 | | Mémoire PSS (Mio) | 117,50 | 173,30 | ### SSR lourd · 1 000 lignes | Mesure | PRNext candidat | Next.js 16.4.3 | | --- | --- | --- | | Débit validé (req/s) | 24,00 | 27,63 | | Latence p95 (ms) | 740,75 | 622,25 | | CPU / réponse (ms CPU) | 64,42 | 49,91 | | Mémoire PSS (Mio) | 164,17 | 198,96 | ### API JSON · 16 entrées | Mesure | PRNext candidat | Next.js 16.4.3 | | --- | --- | --- | | Débit validé (req/s) | 2 078,33 | 1 001,40 | | Latence p95 (ms) | 14,00 | 28,25 | | CPU / réponse (ms CPU) | 0,83 | 1,22 | | Mémoire PSS (Mio) | 144,80 | 203,93 | ### Streaming · Suspense 40 ms | Mesure | PRNext candidat | Next.js 16.4.3 | | --- | --- | --- | | Débit validé (req/s) | 341,00 | 218,67 | | Latence p95 (ms) | 55,15 | 105,00 | | CPU / réponse (ms CPU) | 4,40 | 6,31 | | Mémoire PSS (Mio) | 154,70 | 206,20 | ## Quel budget ressemble à votre projet ? [PRNext vs Next.js avec 0,7 CPU · 700 Mio : le compromis CPU/RAM](/fr/benchmarks/prnext-nextjs-0-7-cpu-700-mio) ## Comment lire ce benchmark 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. ## Quel code a été mesuré ? 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. Source commit: 2856155dc32618d00ea7cbe05d771f589c9df536 Native SHA-256: e78bce35c1029500eec67d4aad5e3c08a5d9b74b3125aa3d10c854c5a286b843 Package SHA-256: 0099abf612f223625caf769f97608be1b4f6daf87a33c2bc92abe9517edbb095 ## Ce que ces résultats ne prédisent pas 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. ## Tester sur votre application 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. ## Données et protocole [Télécharger les données JSON](/benchmarks/prnext-vs-next-2026-10-29.json) [Lire le comparatif complet](/fr/blog/prnext-vs-nextjs-benchmarks-vps) [Fixture](https://github.com/Lorkydey/PRNext/blob/2856155dc32618d00ea7cbe05d771f589c9df536/tests/performance/production-fixture.mjs) [Générateur de charge corrigé](https://github.com/Lorkydey/PRNext/blob/fb59284854850ba0293fab30cc215bbd9aba6c72/tests/performance/production-load.mjs) [Tous les benchmarks](/fr/benchmarks) --- Language: fr Canonical: https://prnext.dev/fr/benchmarks/prnext-nextjs-2-cpu-1-gio Index: https://prnext.dev/llms.txt