Performance de Nodefony
Les chiffres sont mesurés à la main, sur une machine nommée, puis versionnés dans le dépôt — cette page ne fait que les rendre.
Où aller
Ce que Nodefony encaisse
Une route qui ne fait AUCUN travail applicatif, servie par le pipeline complet — sécurité, routage, contexte asynchrone, en-têtes : le pire cas pour un framework, puisqu'il y pèse 100 % du budget. Médiane de 3 tirs de 10 s à 64 connexions.
Face à quoi
médiane de 3 tirs, même route, même machine, même fenêtre
Comparer un pipeline complet à un serveur nu ne compare pas le même travail. Le camp qui
compte est Express équipé : même route, mêmes garanties — un scope
AsyncLocalStorage avec identifiant de requête, la corrélation W3C
traceparent, CORS, les en-têtes de sécurité, le contrôle anti-CSRF par
Fetch Metadata, et le matching des zones du pare-feu, sur CHAQUE requête.
Ce que ces chiffres veulent dire
Un pipeline ne se juge pas au débit d'une route vide, mais à ce qu'il FAIT pendant qu'il la sert — et à ce qui reste de cet écart quand l'application, elle, commence à travailler.
Le prix des garanties est mesuré, et il est payé par tout le monde
Express nu rend 20 088 req/s ; le même Express, équipé des six briques ci-dessus, en rend 19 235. Équiper Express coûte 4,2 % de son débit. Ce prix n'est pas celui d'un framework : c'est celui des fonctionnalités, et il se paie quel que soit l'outil qui les rend. Nodefony arrive avec ces briques déjà en place — les 21 686 req/s ci-dessus sont mesurées pipeline complet traversé, pas moteur nu.
Reste alors l'écart d'implémentation, et lui seul : -5,9 µs par requête (46,1 µs contre 52,0 µs de temps de service). C'est le seul terrain où le choix du framework décide.
Puis le travail du développeur commence
Une application ne sert pas des routes vides : elle interroge une base, appelle un service, rend une vue. Ce travail-là s'ajoute au temps de service des deux côtés, tandis que l'écart de pipeline, lui, ne bouge pas. Sa part relative fond donc à mesure que l'application devient réelle. Le calculateur ci-dessous le montre sur VOS hypothèses.
Ce que ce comparatif ne mesure pas
Le camp équipé reproduit six briques. Il ne reproduit ni les sessions, ni l'autorisation par rôles, ni le WebSocket co-citoyen du même contexte, ni l'ORM, ni le plan d'administration — tout ce qu'une application finit par réclamer. Chacune de ces briques, ajoutée à Express, sera un intergiciel de plus dans la chaîne, et se paiera comme les six premières se sont payées (4,2 %). Chez Nodefony, elles partagent la traversée déjà comptée dans les 21 686 req/s ci-dessus.
C'est une différence de STRUCTURE, et nous ne la chiffrons pas ici : il faudrait un banc par brique ajoutée, des deux côtés. Ce qui est chiffré, et qui suffit à situer le débat, c'est que le prix des six premières est déjà connu — et qu'il est plus élevé que l'écart de -5,9 µs qui sépare les deux pipelines complets.
Sur quoi ces chiffres ont été pris
Une page par version publiée
Ce qui a été mesuré, sur quelle machine, avec quel protocole — et ce que ces chiffres ne permettent PAS de conclure.
| Nodefony 10.0.0 version courante | 2026-10-01 |
Le dossier du chantier
Où part le temps, et comment on l'a su — le profilage, les lots gardés, celui qui a été annulé par son propre A/B, les instruments qui ont menti avant qu'on s'en aperçoive, et ce qu'un chemin virtualisé interdit de conclure.