ssr benchmark

Référence SSR Framework

Il s'agit d'une expérience en réponse à https://twitter.com/thdxr/status/1777782835249553517 où il est indiqué que Next.js est beaucoup plus lent sur le rendu côté serveur par rapport à Vanilla React.

Ce n'est pas un test complet ou scientifique. Je voulais juste comparer chacun dans une configuration un peu complexe que d'imprimer hello world .

Frameworks

(indice)	nom	OPS / SEC	Moyenne (MS)	échantillons	corps (kb)	reproduction	relatif à réagir
0	'réagir'	766	'1.305'	7663	'97 .28 '	'x1.00'	''
1	'sveltekit'	589	'1.696'	5898	'184.46'	'x2.00'	«1,30 x plus lent»
2	'remix'	449	'2.224'	4497	'189.10'	'x2.00'	«1,71 x plus lent»
3	'nuxt'	381	'2.622'	3814	'201.12'	'x2.00'	'2.01 x plus lent'
4	'Qwik-City'	278	'3.584'	2790	'139.21'	'x1.00'	«2,76 x plus lent»
5	'Pages suivantes'	104	'9.590'	1043	'187.67'	'x2.00'	«7,37 x plus lent»
6	'Astro'	99	'10 .077 '	993	'99 .91 '	'x1.00'	«7,74 x plus lent»
7	'mfng'	69	'14 .372 '	696	'317.31'	'x2.50'	'11 .10 x plus lent '
8	'suivant'	53	'18 .673 '	536	'284.64'	'x2.00'	'14 .45 x plus lent '

• React n'est ici qu'en tant que rendu de base pour comparer les performances du cadre avec.
• ️ La duplication est le facteur de duplication des données. 2x signifie que chaque élément de données rendu a été observé deux fois dans la réponse. Il est nécessaire que l'hydratation fonctionne. Pour ceux qu'il est 1x, les données d'hydratation sont manquantes.

Rendements

(indice)	nom	OPS / SEC	Moyenne (MS)	échantillons	corps (kb)	reproduction	par rapport à Marko
0	'Marko'	6675	'0,150'	66759	'96 .74 '	'x1.00'	''
1	'Kita'	3074	'0,325'	30742	'97 .34 '	'x1.00'	'2.17 x plus lent'
2	'Hono'	945	'1.058'	9452	'97 .15 '	'x1.00'	'7.06 x plus lent'
3	'Vue'	897	'1.114'	8977	'96 .72 '	'x1.00'	«7,44 x plus lent»
4	'réagir'	764	'1.308'	7649	'97 .28 '	'x1.00'	«8,74 x plus lent»
5	'Qwik'	622	'1.605'	6230	'137.88'	'x1.00'	'10 .73 x plus lent '
6	'solide'	613	'1.630'	6137	'215.93'	'x2.00'	'10 .89 x plus lent '

• Le solide est là mais il transporte également des données d'hydratation pour l'hydratation côté client, elle est plus comparable aux cadres de cette manière.

• Le corps est la longueur du corps de réponse en kb

• La table a été mise à jour grâce au Kiliman. Remix utilise désormais un rendement de très bien meilleurs résultats.

• MFNG est une implémentation RSC minimale. Important de voir ses résultats par rapport à Suivant, car ils reflètent tous les deux les performances de rendu RSC.

Environnement d'essai

• SEULEMENT SSR. Nous ne construisons même pas les faisceaux clients pour la plupart des modules.
• NEXT.js Le cache de route est désactivé à l'aide de const dynamic = 'force-dynamic' . (Sinon, nous serions compliqué un serveur HTTP statique car il n'y a pas de code dynamique comme l'accès aux cookies.)
• Au lieu de passer par le serveur HTTP, le code de référence crée des demandes et des réponses HTTP simulées. Cela garantit que nous ne payons pas pour les frais généraux de TCP.
• Des tests effectués sur Node.js v20.6.1 sur mon MacBook Pro M1 Pro
• Chaque cadre rend un tableau de 1000 lignes, contenant chacune deux colonnes UUID.
• Les données du tableau sont imitées comme asynchrones et nécessitent du suspense sur React, Solid et Vue. Sur le suivant, il est chargé dans un composant RSC asynchronisé. Sur Remix, il est chargé dans une fonction loader de route.
• Rendu en streaming utilisé sur Solid, React et Vue.

En cours d'exécution

$ npm install
$ npm run build
$ npm start