Browser Connection Limits
This page was inspired by the fact that Google seem to have imposed timeouts on the tile fetches. That’s fine for Google tiles that are provided by fast servers, but if you have a slow server, it looks like the API doesn’t always wait long enough before giving up and deciding that the fetch has failed.
I noticed that fetching an individual tile from a page that exhibits the problem wasn’t much any longer than fetching an individual Google tile. The significant difference was that the Google map types were fetching more tiles at once, so the total time taken to fetch all the tiles was significantly shorter. Google achieve this effect by using aliases to break the browser connection limits.
What are Browser Connection Limits?
Although browsers are capable of fetching many files simultaneously, only two files will be fetched simultaneously from the same domain. This limit made some sense back in the days when the majority of Internet users had slow dial-up connections, but it makes no sense with today’s high speed connections. For most pages, the continuing existence of these limits doesn’t slow the page loading down to make it worthwhile for the limits to be redesigned, but they do have a significant effect on map tile fetches.
So what can we do?
What Google do is have four different subdomains mt0.google.com, mt1.google.com, mt2.google.com, mt3.google.com, and share the tile fetching between them. The browser doesn’t know that these are all aliases for the same machine, and allows two simultaneous fetches to each subdomain. So eight tiles get fetched at the same time, instead of two.
Here’s an example where I spread the load across four subdomains of econym.org.uk.
The code looks like this
return "http://sub" +subdomain+ ".econym.org.uk/gmap/tiles/"+a.x+"_"+a.y+"_"+(17-b)+".jpg"
The rest of the code is the same as that used in custommap1.htm.
I created “sub0.econym.org.uk” etc., as subdomanins that have the same destination (or “Document root”) as “econym.org.uk”, so there actually is only one set of tiles on the webserver, but the browser has no way of knowing that.
How much faster is it?
In those examples, you may not notice much speed difference visually, but when the pages are analysed with PageTest, the old one typically loads in 4.5 seconds and the new one in 3.4 seconds.
Even then, that doesn’t seem like a huge improvement, but if you compare the timings from the start of the first tile request to the completion of the last tile request, those times have gone down from 2.9 seconds to 1.4 seconds. If you have a slow server, the differences would be expected to be more significant.
I don’t know how long PageTest keeps the timing results, but for now you can see one set of results for the custommap1 at pagetest.patrickmeenan.com:8080/result/RC8/1/details/ and for custommap1p atpagetest.patrickmeenan.com:8080/result/RC7/1/details/