The ajax.googleapis.com URL refers to an external JavaScript library, that holds functions the web page might be using in some inline JavaScript of its own.
In most (if not all) browsers, nothing in the page is rendered until all inline scripts are done executing*. Even when the inline JavaScript does not need anything from that external JavaScript libraries, your browser needs to download all of the defined external libraries first, just in case they are needed. So, if the external script is not in your browser's cache† (or: whenever you explicitly refresh your browser‡) then everything halts until the script is downloaded.
The ajax.googleapis.com URL loads fine on my internet connection and I assume Safari and Chrome still have the library in their caches? As for the very slow proxy: this could be some virus scanner (not too likely on your Mac) or some firewall? If the problem is in the proxy then that's out of your control, so (assuming you need to use that proxy): contact the administrators? Meanwhile, you could repeat your test for other libraries hosted at Google, like jQuery 1.3.2 or jQuery UI 1.7.2.
(If really all else fails, then you could try to find some way to rewrite request for ajax.googleapis.com/[..]/1.3.2/jquery.min.js to a URL of some other host...)
* See (slow) example at Cuzillion. And though IE8 is the first browser to download scripts in parallel, it will still not execute them in parallel.
† Google tells your browser to cache it for 31,536,000 seconds, thus 365 days. And it allows for public caching, so a proxy is allowed to cache it, and use it for other clients as well.
‡ When hitting Refresh, then for cached items most browsers will add a If-Modified-Since header to the request, thus only truly downloading if the thing in the cache is outdated. But: even if the server responds with HTTP/1.x 304 Not Modified, the browser still needs to await that answer. So: hitting Refresh when things are slow might make things worse!
xx.mxmcproxy you're using is something needed in your office or required for your internet provider, right? (And just to confirm that yourcurl --proxy name:port urlworks fine for me, with my provider's proxy.) – Arjan Nov 5 '09 at 15:54