AJAX is being implemented on many of today’s modern websites. Some fine examples are Yahoo!, Facebook and even my MiniMoo WordPress theme. It is not a new technology out from the box, it is merely making use of of web development techniques to load data without having to refresh the current page.

A smaller server load from lesser page reloads, a better user experience and other stunning achievable features. What’s there not to like about it? It is however, not without any drawbacks.

Disabled JavaScript Support

AJAX is primarily implemented with JavaScript. Not everybody is a huge fan of JavaScript. For one reason or another, users may choose to disable support for it on their browsers. Where would that leave your implementation hanging?

A pair of solutions for 2 groups of users would be needed for those with enabled JavaScript support and those without it. This would only add to the time spent on development.

Unfriendly with Analytics and Search Engines

Page navigation on an AJAX implemented website is dynamic. You could be looking at an entirely different content while being on the same URL. This poses a huge stumbling block for analytics and search engines. Both the page URL and page title are needed as part of their respective mechanism.

There is a way to track JavaScript events in Google Analytics. However it requires manually making a method call in the source code of the object. JavaScript event tracking is still not very much second nature with analytics. In the case of search engines, spiders do not come crawling websites and then index the dynamic page loads.

Untracked Browser History

We are all so used to using the ‘Back’ functionality of a browser to return to a previously browsed page, me included. That is not quite an alternative with AJAX. Since data is loaded asynchronously without requiring a page reload, there will be no records in your browsing history and the ‘Back’ button would be deemed useless.

Server Overload

Every AJAX requests adds on to the server load. Type suggest and self update scripts are often more server intensive than others. Compare loading a new page of content and suggesting words as you type. Which will bring about the heavier server load? The latter of course. But what if there were more than a user on the site at the same time? You do the math.

You have to also consider whether the server is able to handle so many requests at a time and not cause a lag which will affect the user experience on a whole.

With these drawbacks in mind, you will be able to better decide whether an AJAX approach is the right way to go.