Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

malloc.fi

Post reply on HN
Print view View original

111–120 of 134 posts

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

#111

Post by _greim_ »

Swizec wrote: post #24
_greim_ wrote: post #10

Earlier quoted context omitted.

Correct, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.

If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?

Yes, that's exactly what React SSR + caching accomplishes!

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

#112

Post by scaryclam »

lucaspiller wrote: post #93
spinlock wrote: post #70

Earlier quoted context omitted.

Also, if you _need_ SSR, rails might be a better approach. It's too bad the author didn't include it in the benchmark.

We did this recently with a small app that needs to be fast. The relatively simple page that you see when you first visit the site is rendered with plain old Rails, then when the user interacts with the page (based on DOM addEventListener hooks) it causes additional React components to be mounted and rendered. Originally I’d hoped to be able to render a basic version of the page with Rails, then ‘enhance’ it with Rea…

This is something we've done in the past, and it works well. In fact, the ability to do this (usability is important to us so progressive enhancement is a lifesaver) is why we looked at react in the first place.

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

#113

Post by _greim_ »

rhizome wrote: post #44
_greim_ wrote: post #10

Earlier quoted context omitted.

Correct, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.

initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app This is "bounce before document.ready()?" How does it compare to "bounce before ad networks/API calls finish" and "bounce before end of autoplay video?" I'm thinking that with all the other API goo in many mainstream/mass-media sites, "initial app load time" is some…

> This is "bounce before document.ready()?"

Since we're talking about SSR which happens before anything else, latency is going to push out all load-time metrics equally.

> I'm thinking that with all the other API goo in many mainstream/mass-media sites, "initial app load time" is something users are probably pretty tolerant of

It's all relative. Presumably you're competing on some level with those mainstream/mass-media sites, so users will punish/reward you if your site takes more/less time to load than average.

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

#114

Post by _greim_ »

abritinthebay wrote: post #43
Swizec wrote: post #24

Earlier quoted context omitted.

If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?

> If all first time users see the same thing That's a big, important, if.

It's good odds, though. Obviously depending on the app, these would be non-logged-in users who don't get personalized content.

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

#115

Post by abritinthebay »

_greim_ wrote: post #114
abritinthebay wrote: post #43

Earlier quoted context omitted.

> If all first time users see the same thing That's a big, important, if.

It's good odds, though. Obviously depending on the app, these would be non-logged-in users who don't get personalized content.

There can be (though you’d be surprised- there’s rarely such a thing as a non-identifiable user nowadays). Just pointing out it’s a very big conditional.

For example: I work at Bleacher Report and our non-logged-in users get data customized for them. That can be as simple as GeoIP data or can be us knowing (and inferring) what articles or content they’ve seen.

The permutations are quite large.

Now some blog, or a very simple app won’t do something like that (hell, they might not have the depth of content to be able to) but it’s reasonbly common to have that requirement on large sites outside of v.limited pages (like login/signup etc)

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

#116

Post by dasil003 »

timr wrote: post #109
mottomotto wrote: post #91

Earlier quoted context omitted.

But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast. > build the few dynamic elements on their pages with a simpler, more robust technology This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a me…

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for th…

I've been a web developer since the beginning, so I understand this frustration with the current generation of web developer that reaches for React first purely because it's trendy with complete ignorance of the strengths of traditional approaches.

However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps. A pure API is easier to optimize, and is generally a sensible separation of concerns. Of course this doesn't come without overhead, but you don't have to have Facebook-level complexity for this architecture to make sense.

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

#117

Post by dfee »

dustingetz wrote: post #105
dfee wrote: post #81

Earlier quoted context omitted.

I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.

What is the scroll bug exactly, or are you referring to the perf problems?

No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.

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

#118

Post by batmansmk »

dustingetz wrote: post #71
batmansmk wrote: post #59

Earlier quoted context omitted.

50% on plain rendering is very unexpected. Complex apps tend to have bottlenecks on IO/data fetching more than just plain rendering. I would love an article detailing your experience and measurements.

our renders are compute heavy because it is so dynamic (most of today's apps aren't). Think of it this way. Virtual DOM is like a spreadsheet. You only want to recompute the stuff downstream of what's changed. That's basically what React's render-tree pruning is all about. But there are a couple problems. First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratc…

No need to try to explain why you think it is slow based on your understanding of React.

Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)

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

#119

Post by timr »

dasil003 wrote: post #116
timr wrote: post #109

Earlier quoted context omitted.

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for th…

I've been a web developer since the beginning , so I understand this frustration with the current generation of web developer that reaches for React first purely because it's trendy with complete ignorance of the strengths of traditional approaches. However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps. A pure API…

"However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps."

I don't believe I am. There are certainly uses where I openly acknowledge that using a React is a good idea. If you're building something that needs to be a single-page application, for example, then I grant you that concerns of SEO and URLs and whatnot are superfluous. If you have a totally dynamic site, coupled with a Facebook-esque guarantee that your assets are nearly always in the user's cache, and a huge team of front-end engineers to optimize your code, great. But again, that's a tiny minority of teams.

All webpages are "client-side rendered", so that's a bad use of words. That said, JS-based rendering only "saves resources" if you don't count the bandwidth of the user, the amount of code needed to display a page, render speed, time to first render, and so on. I can't count the number of Reactionary sites I visit on a daily basis that hang for 10+ seconds before rendering or peg my CPU -- and nine times out of ten, they're rendering static content. It's an epidemic, caused by people making bad technical decisions, and even big sites like Instagram get it wrong on the regular (Instagram, in particular, pegs my CPU so often while looking at photos that I believe their secret business model is to mine bitcoin in my browser.)

A pure API may be easier to optimize, but unless you've transferred the time you're saving to front-end optimization, I guaranteed that you're punishing your users -- particularly those who are on low-bandwidth connections and/or mobile devices -- with lower performance and higher system demands.

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

#120

Post by timr »

mottomotto wrote: post #110
timr wrote: post #109

Earlier quoted context omitted.

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for th…

It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering. So I would ask you at this point to turn this all around. Look at it from my perspective. I've been…

"It's not an ugly hack at all. It works well"

URLs are addresses of resources on the internet. They're parsed by your browser to request resources on another server.

If you've rewritten this functionality in JavaScript to support storing application state in your single-page application, it may "work well" but it is, in fact, a hack. If you've done this to support storing application state in your web application that sometimes has to actually talk to servers on the web, it's an abomination, and a complete violation of the way web browsers are supposed to work. The fact it is a currently popular hack does not change the nature of the thing. Lots of bad ideas were once popular (remember when everyone wanted to build SPAs in Flash?)

"for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type"

If your problem is that you don't want to use an ORM, then don't use an ORM. Likewise, there's nothing stopping you from writing a server-rendered webapp with single-datatype endpoints. You can use HTTP2 with server-side rendering. None of these things are enabled by React.

If these are truly the arguments in favor of a particular client-side stack, it's clearer to me than before why so much of this thick-client stuff is terrible.

Post reply on HN