Clearly AJAX improves the user interface but does this also decrease server load? You would think it does because the entire page will not have to be served up each time, but maybe there are other variables I'm not considering.
It depends on what you're doing and how you're doing it.
If you're replacing full page loads with AJAX requests (i.e. only doing AJAX calls when a user clicks on what would have been a full page load) then AJAX will decrease server load because you're (presumably) doing less processing and returning less data.
On the otherhand, if you're adding auto-update type AJAX that polls the server every few seconds then that could increase load depending on the user (it might not increase the server load if the user keeps hitting F5 to refresh manually anyway, but most people generally don't do that for hours)
Another AJAX optimization is to only load more data as you scroll. In that case if the user doesn't scroll all the way down, that's wasted processing.
Of course actually implementation can skew results either way, these are typical results assuming reasonably good implementations.
Of course it does serve to decrease the server load. Look at this presentation @ jsconf'09 -- for how Facebook used ajax to do that.
Ajax is async. server communication -- and you can use that in myriad of ways. People use it for loading simple JSON to real-time Web, and everything in between.
Remember -- the real challenge is the balance between client and server. Strive to make each party do it's work such that the system is optimized and you get obvious benefits of Perceived Responsiveness and real Speed.
There are other factors you are not considering -- in most cases, AJAX will increase server load. In a typical, non-ajax scenario, a user loads one big page every few seconds or few minutes. Yes, that single page is a bit more work for the server, but it has plenty of time between requests to recover and serve other requests. In an AJAXified scenario, that single page load is now dozens of small hits, constantly hammering the server and waiting for responses.
It is a bit like death from 1000 cuts -- none of the requests are that big in and of themselves, but the total weight is a killer. Especially when you start considering that these small requests are just about as expensive to serve as a full-page request. In both cases, you are probably running through an entire web application pipeline, hitting a database and waiting for an answer while sitting on a precious HTTP connection.
Here is an example of how ajax can get ugly on the server real fast. Let's take a typical "executive dashboard" that features 4 slots for widgets. Let's say the CEO likes a full sales report in the right side, a top 10 list of earners in the middle and a company share price report on the right. And let's say we are going to do this via simple ajax remote requests. Without taking into account stylesheets, images and other assets, your page now requires 4 HTTP round trips (main page, each of the dashboard reports) against the server. Each of these requires a full web stack to execute -- you are going to be hitting databases and rendering HTML using your web framework, right? Now multiply the single CEO by 2000 remote users some of whom have spotty connections.
Conversely, you could have a single server-side page that executues and returns a HTML skeleton as well as the data (included in in-page JSON) to render the reports. Single, bigger connection but less beating on the web server in total because you are not handling 4 requests and spinning up 4 pipelines, etc.
If you are using AJAX to replace work that the server would otherwise be doing then yes that will improve server performace. However, you may have designed things so that the server is still doing just as much and now whatever is happening with AJAX is on top of what the server was already doing.
If HTML rendering is a huge part of your application server's performance profile, then moving HTML rendering to the client can be a performance win on the application server.
However, if HTML rendering is a small part of your application server's performance profile, then more requests will typically mean more trips through the stack, more queries, more of everything on the application server, a performance loss.
Of course, the only way to know in your particular case is to try it out.
You have to consider the best way to implement your solution. A simple non dynamic form does not need ajax and adding it may actually harm perfomance. If your problem is bad queries all the ajax optimization in the world is not going to get you a performance increase that will be acceptable.
If your server is overworked you need to figure out why.
If you are getting alot of hits then ajax is not going to fix that problem you need more capacity. Adding ajax will just increase the number of requests that your server has to handle.
If you have a complicated page you should see if there is anything you can do client side to reduce the load on your server. If your page is dynamic but really has a limited data package caching that for client side adjustment may pay off better.
And some times Ajax will help. When you have complex forms with dynamic data ajax wins the day. But if you queries are complicated and take a long time to run then ajax still will not solve your problem.