Live data from Hacker News

The Performance Cost of Server Side Rendered React on Node.js

malloc.fi

31–40 of 134 posts

Re: The Performance Cost of Server Side Rendered React on Node.js

#31
post #17
post #13

Earlier quoted context omitted.

They include a comparison with using ES6 Template literals (native JavaScript string interpolation), and saw 10x increase over React. The native string interpolation actually came out just behind serving straight static files. JavaScript CPU performance is actually quite high among interpreted languages. So to answer your question more specifically, no I don't think it is clear. What this is specifically isolating as…

Does anyone actually use vanilla JavaScript string literals for all their backend rendering?

Pretty sure it's just a control so that you can compare the templating performance to what's essentially just string concat.

Re: The Performance Cost of Server Side Rendered React on Node.js

#32
post #2

I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?

Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.

If the Server rendered page is not user specific and is generic for all users then it can be cached and served quickly. Then only potentially one user would experience a slowdown and you can serve much faster.

Of course then you get into the fun of cache management and invalidation.

Re: The Performance Cost of Server Side Rendered React on Node.js

#33
post #5

well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?

I don't understand how this can be your takeaway since you can see how fast Pug is in comparison. The article is clearly singling out React's slow render speed.

Re: The Performance Cost of Server Side Rendered React on Node.js

#35
Note that React doesn't do streaming HTML in the traditional sense. You can't send out initial HTML while you wait on an API response, for example. Instead only the serializer is streaming. Your app renders to a VNode synchronously and then the serializer traverses the VNode, synchronously, and streams the strings out as it goes. This is why streaming is only a little bit better in these numbers.

If/when React gets real streaming it will compete better with traditional templating engines, most of which don't do streaming. If you use Node.js and want a traditional templating engine that uses JS template literals and does do streaming, check out my project: https://github.com/matthewp/flora

Re: The Performance Cost of Server Side Rendered React on Node.js

#38
post #11

OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?

It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.

Re: The Performance Cost of Server Side Rendered React on Node.js

#39
post #11

OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?

The issue is other solutions give you ~10X more page loads per unit of time at the same price.
Post reply on HN