TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

174 点作者 dberhane超过 7 年前

23 条评论

laurencerowe超过 7 年前
It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact.<p>Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. <a href="https:&#x2F;&#x2F;github.com&#x2F;janit&#x2F;node-templating-benchmark&#x2F;pull&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;janit&#x2F;node-templating-benchmark&#x2F;pull&#x2F;1</a>
评论 #15745611 未加载
MatthewPhillips超过 7 年前
Note that React doesn&#x27;t do streaming HTML in the traditional sense. You can&#x27;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.<p>If&#x2F;when React gets real streaming it will compete better with traditional templating engines, most of which <i>don&#x27;t</i> do streaming. If you use Node.js and want a traditional templating engine that uses JS template literals and <i>does</i> do streaming, check out my project: <a href="https:&#x2F;&#x2F;github.com&#x2F;matthewp&#x2F;flora" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;matthewp&#x2F;flora</a>
评论 #15744896 未加载
评论 #15747820 未加载
kraftman超过 7 年前
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&#x27;s 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
评论 #15742839 未加载
评论 #15742653 未加载
评论 #15742494 未加载
mottomotto超过 7 年前
If you&#x27;re on the fence about server-side rendering being needed for your webapp don&#x27;t do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy.<p>You might not need SSR. I don&#x27;t. I expect there will be more work to optimize it and eventually it&#x27;ll be obviously a good idea. But you don&#x27;t need it right now if you&#x27;re working on a SaaS product.
评论 #15744835 未加载
评论 #15746067 未加载
评论 #15744713 未加载
评论 #15746724 未加载
qaq超过 7 年前
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?
评论 #15743836 未加载
评论 #15744001 未加载
评论 #15742903 未加载
评论 #15745684 未加载
评论 #15743846 未加载
kennu超过 7 年前
Isn&#x27;t the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML&#x2F;JS&#x2F;CSS assets using a static webserver?
评论 #15743959 未加载
评论 #15743939 未加载
评论 #15744474 未加载
评论 #15744592 未加载
评论 #15743898 未加载
ec109685超过 7 年前
The author mistakes increasing concurrent request as being some sort of proxy for concurrent users. Once you have maximized rps or maximized cpu, increasing concurrent just artificially hurts your average latency.<p>Max RPS equals number of users you can serve per second. Concurrency should just be tweaked until you eliminate the network latency of your test framework.
makmanalp超过 7 年前
So I thought the entire point of SSR was to speed up initial page load - if you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait to download and run a massive JS bundle first.
评论 #15743417 未加载
olegkikin超过 7 年前
Related:<p>Node.js templating engine benchmarks:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;marko-js&#x2F;templating-benchmarks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;marko-js&#x2F;templating-benchmarks</a><p>Framework SSR benchmark (Vue, React, Preact, Rax, Marko):<p><a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;server-side-rendering-shootout-with-marko-preact-rax-react-and-vue-25e1ae17800f" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;server-side-rendering-shootout-with-m...</a>
STRML超过 7 年前
For this reason, we don&#x27;t use SSR for pages that change often, and turn it off completely for authenticated users. Some performance analysis showed it was actually <i>slower</i> in the average case than shipping the JS and having the client render it themselves, especially with a hot cache.<p>This still provides what we wanted anyway; the ability for pages to easily be viewable without JS and easily indexed by search engines.
jondubois超过 7 年前
These results are not surprising to me but it&#x27;s great that they were published because people have been very quick to jump on the hype bandwagon for these kinds of projects.<p>I think that the idea of the isomorphic JavaScript app never actually worked in practice. MeteorJS already had a really good go at it.<p>Sharing JavaScript modules between the client and the server is great but when you start to pretend that the backend and the frontend are the same environment, you&#x27;re bound to run into all sorts of problems and create inefficiencies.<p>The kind of performance penalty incurred by server-rendered React is bound to make your system vulnerable to DoS attacks or at best make it unnecessarily expensive to operate.<p>When programming abstractions shift too far away from the reality of the underlying architecture, you will start paying dearly and the cost won&#x27;t be worth it in the long run.<p>In my opinion, the client-server divide is a fundamental aspect of multiuser applications and no amount of abstraction can make it go away.
dustingetz超过 7 年前
<a href="https:&#x2F;&#x2F;github.com&#x2F;walmartlabs&#x2F;react-ssr-optimization" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;walmartlabs&#x2F;react-ssr-optimization</a><p>React definitely needs work here and i think the right people are quite aware of the issues.
styfle超过 7 年前
Could the performance be improved if you call React.createFactory() and then stream the factory call like this[0] code?<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;styfle&#x2F;react-server-example-tsx&#x2F;blob&#x2F;4586f3431b4bfd424179da3aad2c6adbddb0de10&#x2F;src&#x2F;server.tsx#L12" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;styfle&#x2F;react-server-example-tsx&#x2F;blob&#x2F;4586...</a>
tabeth超过 7 年前
I&#x27;d be curious to know if this cost is similar with Ember&#x27;s implementation of SSR, Fastboot.
yoshuaw超过 7 年前
If you&#x27;re looking for DOM in the front, Strings in the back, check out Bel – <a href="https:&#x2F;&#x2F;github.com&#x2F;shama&#x2F;bel" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;shama&#x2F;bel</a>
justin808超过 7 年前
Did anybody try <a href="https:&#x2F;&#x2F;github.com&#x2F;shakacode&#x2F;react_on_rails" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;shakacode&#x2F;react_on_rails</a> for this comparison?
merb超过 7 年前
well wasn&#x27;t that clear? Isn&#x27;t something like a Template Engine quite CPU intensive? Things were node.js performce poorly?
评论 #15742877 未加载
评论 #15743703 未加载
arkh超过 7 年前
I&#x27;d like to see the results with php through node-phpcgi to render those pages. So we&#x27;d have gone full circle at last.
opvasger超过 7 年前
My clients get to render their own html - it&#x27;s not really that bad if you bundle, split and cache the code.
pteredactyl超过 7 年前
Been using template literals for basic apps instead of the usual overhead. Mostly loving it.
miohtama超过 7 年前
Does React build any cached or compiled intermediates for its templates?
simplify超过 7 年前
I&#x27;d love to see a side-by-side comparison to Marko.js (<a href="https:&#x2F;&#x2F;markojs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;markojs.com&#x2F;</a>). It has a lot of react-like features, but was built from the ground up for SSR speed.
评论 #15744462 未加载
k__超过 7 年前
Render on write, not on read.