Meh, this post was pretty unsatisfying.<p>Should anyone be shocked that you shouldn't do synchronous calls in an asynchronous framework? Or that you should use nginx to serve your static content and not Node? Requesting remote services in parallel is a no brainer. What does blazing fast really mean here? Using your framework correctly just sounds like "normal fast".
I like how the 10th tip is completely opposite of the 1st one.<p>2 is just a bad tip. Socket pooling is a useful feature. Opening up more connections than you (or the server) can handle will lead to poor performance.<p>3 and 5 isn't Node.js-specific and you're better off reading <a href="https://developers.google.com/speed/" rel="nofollow">https://developers.google.com/speed/</a> to learn the fine details.<p>Instead of following 1, 8 and 9 you should learn how to profile your application so you can find the true bottlenecks of your app.<p>4 and 7 are just weird. Going session-free or switching to client-side architecture are both big tasks; I'd love to hear more about the real challenges, not just "this is fast, zomg!!"<p>I wish this post had more meat. How did they end up with these tips? How did they profile? How did they benchmark? Where can I read more about the other tips? Without any good links to learn more about the details (seriously, linking to gzip.org was the best you could do?) I'd say these tips can almost do more harm than good…
"We worked hard to make our mobile apps fast. Try them out and let us know how we did: we have an iPhone app, Android app and an HTML5 mobile version."<p>Yay they made loading fast apparently. But any user of the app will notice that the linked in app feels slow and clunky. Great shit loaded. But it still feels slow. For example, take an iPad and go to Flipboard. Rotate the device. Notice how fast and smooth it is. Now go to the news feed in the iOS LinkedIn app and Rotate. It's slow. It feels like a web browser. It feels like they spent so much time optimizing the loading of resources and spent ZERO time actually making the client feel nice and native.
Very interesting to see how just a <i>single</i> sync file call can <i>destroy</i> performance.<p>It makes perfect sense in hindsight, even though at the time it could be easy to think, "how much could this really hurt?"
It's interesting to note that while Twitter has moved away from client side rendering of HTML templates (and is a strong advocate of sending HTML directly down the wire[1]), LinkedIn mobile app seems to be rendering the template on the client.<p>[1]: <a href="http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html" rel="nofollow">http://engineering.twitter.com/2012/05/improving-performance...</a>
"Don't use Node.js for static assets"<p>Obviously if you have node doing less it's going to be "faster". Or is it? I'm not really sure that offloading tasks qualifies as being faster. I'd like to see some data on this though. Basic caching as supplied with connect should serve static files pretty damn fast I would think. Perhaps nginx does that for a living and kicks ass, but node shouldn't be all that bad.
I would love more insight or experiences on going stateless/ session free. Are you explicitly signing every request that requires authentication for security purposes?
Another tip for people using express is to not use middleware that is not needed in every request. You can specify special middleware for every path. So you can even split session usage only on pages that need it. Similarily, cookie parsing, etc can be avoided where not needed.
Why would a company that uses Java even consider Node.js?<p>Java is hands down faster.<p>I have never seen a benchmark that showed Node coming even close to Java performance.<p><a href="http://www.youtube.com/watch?v=bzkRVzciAZg" rel="nofollow">http://www.youtube.com/watch?v=bzkRVzciAZg</a>