PRNext vs Next.js avec 2 CPU · 1 Gio : SSR et rendu lourd

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.

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.