Accelerate your Web apps by Tricking the Browser
- By Matt Stephens
- December 29, 2006
There’s a clever idea in this blog entry at Ajax Performance. Web browsers typically make 2 concurrent connections to any one web host. In fact, IE and Firefox by default restrict users to 6 connections total, and 2 connections per host. For users on a dial-up connection, this makes sense; but increasingly, your users will be connecting to your website over a broadband connection. Result? Lots of idle bandwidth while their browser trickles images down over those two socket connections, meaning slower page load times.
Should we care that our websites display slowly, when arguably it’s our users’ browsers that are mis-configured? Quite possibly. A recent survey by Akamai showed that Internet shoppers will only wait an average of four seconds for a web page to load before giving up. So ignoring this problem could be costing you money.
Of course, you could politely ask all your users to fiddle with their browser settings and increase the number of concurrent connections. But a far cleverer way is to trick the web browser into opening more connections to your server.
How? Simply configure your webserver to retrieve its images from more than one host, e.g. images1.mydomain.com, images2.mydomain.com and so on. The clever part is that all of these point back to the main host, so you’re not actually adding more servers. An example of this trickery in action can be found at Google Maps, which dispatches its image tiles from mt0.google.com through mt3.google.com.
A refinement of the technique (as pointed out in the blog comments) is to use wildcard DNS entries, and again make them all resolve to the same IP address. This approach has slightly less maintenance overhead than specifically listing certain CNAMEs. As also pointed out in the comments, you should consistently use the same host names/numbers for the same images, so that browsers can cache the results.
As demonstrated in the article, going from 2 connections to 6 concurrent connections resulted in an average 40% drop in page load times. This technique will work anywhere you've got a large block of resources served by one host: and it could just save your customers from wandering off in search of a faster e-commerce site.