I'm a little confused. How much of this is client-side optimization-specific? It seems like most of these (if not all) are also standards in making your server-side rendering apps faster as well. For example minifying, CDN, GZip, etc. would all be used in a Rails app, not to mention a bunch of these come by default with Rails.

If I'm not mistaken, a bunch of the speed problems with the client-side apps has to do with memory leaks (not addressed) and client-side browser speed (not really addressed). I was wondering if there are any solutions to these.

In any case, good article, was pretty helpful.

Title is pretty misleading, I expected it'd be something about the importance of pushing users to activate quickly in your product.

Instead, it's assorted tips for web app performance -- from someone who used to work at Twitter -- talking about his current side project.

At the end, he name drops other well-known front-end devs to show how cool he is.

I agree about the title, but this was a little unnecessary. I mean, he himself is a pretty well-known front-end dev with a pretty impressive background (http://alexmaccaw.com/). Critique the work, not the author.

I think Alex is wrong about the GIL causing the VM to block on I/O. Ruby allows a thread to be scheduled when another is blocked on I/O (using rb_thread_select()). In the past 3rd party libs with poorly written C extensions, e.g. mysql gem, didn't take advantage of this functionality hence the effect of threads being blocked with idle CPU. This is no longer the case. However, it should be noted that a single thread runs at a time in YARV.

JRuby does not have a GIL (or GVM (Global VM lock) as it's been called since 1.9), he can use that now if he wants true concurrency, with threads truly executing in parallel.

Yes, I think you're right, my article isn't accurate. I'm going to publish an update.

The fact that you need multiple SQL queries to fetch the user handle seems like a orm fail and not a call for denormalization. Why not, you know, use a join ?

(And I find the fact that Twitter actually cares about their initial load time pretty amusing)

There must be a big disconnect between the tech team & the product team. Time to first tweet takes several minutes because the user is forced to follow multiple accounts upon signup. The latency is not the tech. I wonder how much $ goes into shaving off a few milliseconds, despite the fact that even latency zero still results in minute long signup?

*I'm sure it's in twitter's interest to keep the on-boarding the way it is, but that's a separate topic.

[edit for clarity]

OK, I read the article wrong. The article is talking about viewing.

My comment refers to user signup & composing first tweet.

This was really enjoyable to read. I didn't know too much about Chrome's web auditor. Does anyone have any other suggestions on bench marking for server or client performance?

For client performance, I've daydreamed about an addon to Jasmine that could record the execution time of tests or functions and log them over time.