I'm interested to see at what point the speedup happens. In other words, is offloading static files faster because:

-Node has more cycles to compute things?

-The server node's on has less contention to deal with (disk, network)?

-Putting statics on another server allows the browser more simultaneous connections when loading the page, so it loads faster by default?

"Don't use Node.js for static assets" is an interesting observation but I'd like to know exactly why.

All of those things seem like they would be true. But even on a very basic implementation you shouldn't have to hit the disk all that often unless you have an extremely large number of static files to serve. This is quite possibly the case for many sites, but I think for most sites, all of your static files could be cached with a minimal memory hit.

Because C is faster than JavaScript, and nginx is written in C.

The reason it is advised to not load static files via Node.js is that nodejs is a single thread process, and static files will hold up this thread. Nginx on the other hand, is multithreaded, and can continue serving other assets and requests while the statics are being served.

Express supports sendfile(), so it should be about as efficient as any other Web server. I wonder if anybody has benchmarked it.

Nginx has a lot of tricks to handle this for you, including caching and working over multiple cores. There is also less framework overhead in Nginx because it's not trying to do dynamic content. I'd be surprised if Node beats Nginx for serving static content, but alas I do not have any proof. At the very least it will use time in Node that is better off serving dynamic content.

Hmm, web servers differ dramatically is serving single files.

The approach I favour is to put varnish in front of a classic slow script webserver (tornado, but use node if you prefer).

Tornado has this neat way of baking-in versioning to static content so clients (and proxies) can do aggressive caching http://www.tornadoweb.org/documentation/overview.html#static...

Best of both worlds.

I'm curious, is that an asynchronous sendfile?

Yes.

as in spinning off a thread to serve it?