I suspect the improvement comes exclusively from increasing the limit on the number of connections, by way of now using two sources instead of one, rather than from the removal of a few bytes in the HTTP request.
Unless I missed something...
I suspect the improvement comes exclusively from increasing the limit on the number of connections, by way of now using two sources instead of one, rather than from the removal of a few bytes in the HTTP request.
Unless I missed something...
http://en.wikipedia.org/wiki/Slow-start
Essentially your client waits for ACKs from the server when it sends its first packets. The greater the RTT the higher the penalty. This is part of why DC -> NJ didn't see much benefit but CA -> NJ saw a nice boost.
There was a great talk on this at Velocity Conf 2010: http://en.oreilly.com/velocity2010/public/schedule/detail/11... - I have not yet found video, but you can flip through the slides.
Checkout this visualization of the slow start and you can see how sending even one fewer green dots over a large distance could considerably change the overall time.
If you transmit 10 static files per page request, and have 256bytes of cookies you're sending 2560 bytes of cookies, or 2KiB per page load. That's on the end user's upload bandwidth too, which is typically dramatically less than their download.
The lessening of the connection limit also allows more entities to load at the same time, the combined effect is a good increase in speed. Two tweaks for the price of 1. =)
It's something worth doing, but it's not the biggest win you can get.
If the actual speed increase is from something totally unrelated to the piece's conclusion then this is really misleading.
The static domain trick has been around donkeys.