I’m going to go read your other posts now :)

For your load time, I might suggest you just style the page to have a dialog on page load. That way it doesn’t wait for jquery ui to load. Then at the end of the page just hide it with jquery. It stops you from having to load ui at all if that’s the only place, or at least lets you wait until later.

Ideally, the dialog would show first (or immediately after the stuff appears) and the ajax calls would continue to populate the fields, the tabs build, etc. Can this technique help accomplish this even if one set of ajax calls is synchronous? Does the fact that I’m using a master/content .aspx page and my ajax calls are to webmethods further complicate things?

Certainly for most pages, this isn’t the answer. If your data is the core content of your page (often times mobile applications load in this manner), then this would be the ideal way to load your scripts, barring a native XHR implentation in order to save a framework load.

To go further, scripts should never block your page. You can get around ‘max_connections’ issues very easily with a wildcard subdomain, and scripts can be loaded with a javascript loader to always make sure your resources are loaded asynchronously. LabJS (http://labjs.com/) offers a low filesize script loader that will do everything possible to load all of your javascript simultaneously and without blocking. I wasn’t talking about dependency management, and was more showing an easy trick, so I didn’t go into detail about this kind of stuff, but you should _certainly_ check it out if you are _ever_ worried about scripts blocking page load. It just doesn’t have to happen…

Thanks for the feedback!

The ajax call can result in slower page loads potentially. It causes another request to be made and if other resources haven’t finished downloading this can slow down the retrieval of those other resources. Often times those resources (images, stylesheets, other scripts, etc.) are more important then the data in the ajax request to rendering the initial page.

In this case, all the relevant data on my page comes in through that request. The dom is essentially a set of bare templates to be filled in by my application. This would be common practice in many apps that use ajax to load subsequent pages and uses hash urls, etc.

That’s why you’ll also notice, that for this implementation, I have jquery loaded in the head. Generally this is against performance tips, but if the goal is to see the content as soon as possible, it makes a lot of sense here. In my _actual_ application that inspired this post, it only had to work in webkit, so I actually made a native XHR request (since I didn’t have to worry about crossbrowser stuff) for the first request, and still loaded jquery down at the bottom.

As far as single domain max requests, I think it would be pretty simple for anyone with a need for added performance to set up a separate subdomain or two. You can just mirror the whole site on the subdomains, and you won’t have to worry about older browsers limiting you to two requests. (In the case of the _actual_ app, I pulled all my static resources from a cdn, which has it’s own added benefits on top of not blocking my ajax requests).

I think, regardless of when you make that ajax request, if you are worried about max server connections, you should add in subdomains, or a cdn. Chances are, the dom will be ready long before all your requests are finished, which would block the ajax call until they opened up.

Thanks for the salient input!