Isn't AJAX on pageload a bad thing?

Question

I've seen this on nerd dinner and other sites. On page load (in JavaScript, via the browser), an AJAX request will go out to get some data from the same server that rendered the initial page. The data will be small and there are no technical limitations that would have otherwise prevented them from just pulling down that data in the first place.

Isn't this a bad thing? It seems like a waste of an AJAX call, since they could just render this data as JavaScript with the rest of the page.

My bank uses AJAX to pull the information to build form elements for a "Transfer Funds" form. That information is a few kilobytes, an AJAX request there seems overkill.

In nerd dinner, at least in the MIX09 video that I saw, they are querying (via AJAX) a set of dinners to render on the map control on page load.

I could understand if we're talking large amounts of data that would otherwise take too long to pull down, but if its under 10-15kb, wouldn't it just be better to pull the data down with the markup? Are they doing this to avoid caching of the data?

Edit: What I'm proposing is that instead of opening up an AJAX call to the server to pull down json data on the clients onload, simply have asp.net (or whatever) render the json in the pages content when it renders everything else. I just felt the need to point that out because the actual client side code would be exactly the same, except for where the json variable originates.

Answer 1

Generally speaking, in my experience, you want to avoid any Javascript on your page that you can. By this I mean, if you can do it on serverside instead of with Javascript then you should. Your page will load faster and you'll just have a better user experience.

That can sometimes be more work, particularly if that same on-load AJAX call is used during the page at later points. You might be duplicating code by doing it serverside. So there's a tradeoff between performance and how much code you want to write.

The other aspect to this is that Javascript is sometimes used defensively against bots, scrapers, malware (like keysniffers and so on), etc for both your security and that of the site. This can mean, for example, loading page elements with Javascript simply because it makes it harder to hack or scrape. Not impossible midn you, just harder.

Answer 2

I don't how the size of the request/response is of any kind of relevance here. Using AJAX or not is more a question of usability and one factor here is the time to render the initial page. Users don't want to wait. If you need just 2 seconds to compute a page element on the server side, you should definitely think about sending the page without that element first and then get the element via ajax. Even if that page element has only a couple of bytes.

Answer 3

I'd write the initial page server side to include that first would-be AJAX call, then use actual AJAX for anything after that. You want to do more work on your end to make it faster for the end user.

I've seen a site that uses AJAX for the main content. When the side is under load, it will display the navigation bar, then you don't see anything for another 5 seconds because it loads with an AJAX call, and you've lost your place in line. It's annoying as hell.

Answer 4

I use AJAX on load mainly to avoid duplicating effort and keep things simple - if I need to do the client side rendering for updates anyway, it's better to use the same code for the initial rendering.

Having everything produced by javascript does have implications for search etc, but as long as you are aware of this when you design the page it's not too much of an issue.

Answer 5

The AJAX call on load of the page is to preserve the separation of presentation from content/data.

The presentation (HTML page) can be cached by the browser, and the AJAX call only retrieves data to update the UI with.

This can lead to very clean separation as well as some performance benefits too. You are actually transferring less information over the wire since you aren't passing HTML tag soup - just whatever representation you have your data in.

Answer 6

It's not the size that's the main problem but the additional request latency / blockage of available parallel request slots.

Answer 7

Generally you are correct, if you are initially pulling the page from the server, why make another trip to get more data? But, if the data is large, then you might as well have the page load so end users can see something, then pull the data.

The data might be pulled Ajax wise because a similar data retrieval method is used often on the page. Why right a seperate data pull mechanism for the initial load if you are going to be doing a few Ajax loads anyways.

Plus, always remember that demos are just that, demos. The Nerd Dinner guys were probably more interested in showing how to use AJAX with MVC then they were about other priorities.

Anyway, good catch.

Answer 8

Just a reason why I could see this being done:

Doing the AJAX call to load the initial data can serve as a way to verify that Javascript is turned on and that subsequent AJAX calls should work. Otherwise what would happen is that the first call to the server done by the client using JavaScript doesn't work and the user may be frustrated by why this doesn't work without realizing that their security settings are the reason.

Answer 9

Back Button

If the user clicks back / forward, the server will not get called again since its pulling the content out of cache. However, with an ajax call on client side pageload, the server will always get called.

Answer 10

Against Ajax on page load

• Uses an extra available connection on your server to process AJAX request.
• Can leave your page idling while trying to complete the call.
• Not indexable by search engines.

For Ajax on page load

• Convenient. Keeps data out of the page.
• Makes for easier changes in data.
• Ability to implement caching of Ajax response.
• Create many 'widgets' each handling there own calls.

A lot of this also just depends on what site your building. You want to be careful with bigger sites to not rely on tons of little Ajax calls right on page load.

Answer 11

The best reason to do this is to have a single source for the content: instead of getting the first instance embedded in the page, and updated instances coming from Ajax, now every instance comes from Ajax.

In other words: doing it your way is double work, with a chance (due to bugs) that the two versions behave differently.

Answer 12

I agree with Adam. If you have a big complicated page that might take your server a while to render, but that only has a few bits of dynamic content in it, then you can get big performance benefits from aggressively caching the HTML and loading the dynamic content with Ajax.

As an example imagine the main page of a site that is supposed to display the user's name in the corner. Everybody visiting your site will hit that page, so the more caching you can manage for the HTML the better. By filling in the user name with Ajax, you can serve the same cachable version of the HTML for everybody and serve the much smaller dynamic content separately.

Cachability becomes even more important if you are working with a not-terribly-fast server technology - Ruby on Rails in may case. You can get a nice server-side speed boost by serving pages through a proxy such as Varnish or Squid that keeps a cached copy of every page that is served. Subsequent requests for the same resource will be served from the proxy's cache instead of your server code until the cache becomes stale.

Answer 13

The best solution seems to be to call the Ajax function on the server-side and load the json contents on pageload. This keeps things consistent and avoids extra connection at startup.