Slow download of jQuery from Google CDN

Support
1

I’ve noticed this a few times and tested it from a few locations on both sides of the Atlantic…

Resources 16 & 19 in the following tests ar jQuery and jQuery UI retrieved from the Google JS API CDN

http://www.webpagetest.org/result/120227_R0_0ee90552f1d07e947a52dd975ce59ce7/1/details/

For some reason the download times are far larger than I’d expect:

jQuery - 918ms for 27.9KB
jQuery UI - 1518ms for 51.3KB

I’ve tested the same page in Chrome and see nothing like the same level of delay.

Any ideas what might be going on?

Thanks

Andy

2

Looking at the bandwidth line, it looks like the requests are just competing for resources with other downloads that are going on at the same time. It is also possible that IE’s networking stack is running into some contention trying to read the different requests since the data is measured from the browser’s perspective but I’d be more inclined to believe it is just bandwidth starved. Try a higher bandwidth connection (or a dedicated test page) and see if you see the same behavior.

3

Thanks Pat,

I think I’ll have to knock up a dedicated test case as I ran some more tests with even more confusing results!

Firefox 3.6 shows the same delay (http://www.webpagetest.org/result/120228_6M_d1314c5d271dda88324c757e629b8479/1/details/)

Chrome gives a -2 error for the resources from the Google CDN - presuming this is a SSL issue (http://www.webpagetest.org/result/120228_FP_e0c36f3945d84257640ca7aadfa6a208/1/details/)

Running IE9 at 5Mbps maxed out the CPU!

Testing from the UK with IE9 and HTTPWatch shows they download in a reasonable time BTW

4

Not directly related, but the Google CDN also serves the files over http - you can use protocol-relative urls //ajax.googleapis.com… or http:// - the samples on the site just happen to be for https.

Switching to http will get them delivered a bit soner (and probably change the overall timing).

5

Knocked a couple of test pages

With HTTPS:

c1f3dc86a/1/details/

Without HTTPS:

Neither of which show the same level of delay as in the original, so guess I need to hunt around in the original test a bit more.