Ajax – Too Much of a Good Thing

I’ve stated this many times, but working as a lead php developer at eroi has been both an adventure and educational. Each project brings new challenges, requirements, and the obligatory ‘experiments’. I’ve had the opportunity to deploy some pretty good size projects, at least what I would dub ‘enterprise’ scale websites with enough traffic to keep it humming and with that much traffic comes a good helping of feedback. One of my latest projects involved heavy use of ajax to provide eye candy and the majority of the site navigation. Some people may shriek as they read this but being powered mostly by user-driven content, SEO was not a priority. What I discovered through my own use of the site as well as overwhelming feedback from the community is that simply put… too much ajax can be detrimental to user perception. This is ironic considering this is what it was deployed to improve.

The keyword here ends up being perception. Depending on server and internet conditions, the time it takes to load an entire page is usually pretty consistent with how long an ajax request takes to respond. This means in the time it takes to populate a div with a paragraph of text, an entire page with images could have been built, rendered, and delivered. Wait…. wtf? Well let’s revisit my logic for deploying ajax so heavily:

1. Less data is transmitted so it should take less time

2. Less data is rendered so it should take less time

3. Less stuff changes on the page so there is a perceived seamlesslness

Ok now let’s explore why these are noble ideals but in practice don’t hold water.

1. The problem isn’t how much data gets downloaded unless you’re on a painfully slow connection. The average person has some form of broadband so this isn’t as critical as it used to be, although you still should make your best effort to reduce the footprint of your sites as it still matters. The problem tends to be the overhead it takes for the server to respond to a request, especially for larger enterprise style sites. Now I tend to write pretty hefty MVC sites with a lot of infrastructure in the bootstrap so I don’t have to write very much code in my controllers, (The efficiency of this is debatable but it allows me to pump out sites very quickly). This means that every minor ajax call which is intended to quickly grab a tidbit of information must invoke the entire machination of the app’s infrastructure, given the transient nature of php processes. That means apache forks, a php process is started,  the bootstrap code is executed, routes are built,  permissions are checked in the Acl, the controller is loaded and invoked, and finally a template is loaded and rendered. That’s a lot of stuff to happen in the 1 second or less that the ajax request is supposed to respond within. On a site where content is getting polled for updates on a frequent basis, you are dramatically increasing the number of requests to the server, meaning you are increasing the server load and as traffic increases, the lag between requests starts to get noticeable. What ends up happening is your user is watching your animated spinny gif for just as long as it would take for the page to reload, only its a little more annoying than the former because the user expects the content refresh to be near instantaneous.

2. It stands to reason that less content is quicker to render, but for all of the reasons why #1 doesn’t stick, #2 also fails the test.

3. This one is the double edged sword. It’s true that it is usually perceived to be snappier and more application-like when parts of pages update in response to clicked links and/or buttons rather than being forced to another page but this is only the case if it works well. We all hate to wait. Waiting for what should be a minor update is especially egregious and the user really notices because there is usually a spinner or throbber there taunting them about it. It’s like those annoying trivia commercials before a movie in the theater that no one is really interested in watching, but they have to because the show hasn’t started yet.

So let me put this all into perspective. I am not advocating using less ajax. On the contrary it’s become a critical component of modern websites, however experience is teaching me to use it only when you can get away with it. In other words, don’t make it obvious. If a user knows you are using ajax for a particular action, you are probably doing it wrong. Here are some rules of thumb that I’ve learned from my own mistakes:

Ajax calls should return very quickly and be like their namesake: Asynchronous. Blocking further action while an ajax request is being handled contributes to a negative perception about the site’s performance.

Ajax should not impede easy navigation. This means don’t break the back button. Additionally, everything that can be reached through ajax should be accessible through a permalink (ie. can be bookmarked).

Beware of queued requests. A good example of this hazard is screen name availability checking where an ajax call gets made when a text field is changed in order to query the database. As the user types, they can potentially trigger several ajax requests each performing the same operation. Make sure to cancel existing requests before making new ones otherwise the response that comes back could be stale and appear slightly shizophrenic as it updates content.

So in a nutshell I discovered most of my use of ajax in site navigation is usually pretty gratuitous and this has had a negative impact when the server load is high. I have also noticed that overuse leads to considerably more complex code on both the server side and in the javascript. The final issue is one that is a no-brainer for veteran developers, is that ajax does not always degrade gracefully. I never considered this much of a problem since most everyone with an IQ above 100 is using a modern browser, however with introduction of mobile browsers, this has become a bugabear from the shadows of the past and is once again an issue. It’s better to keep the site simple and functional and add eye candy only when available. Veterans may read this and say ‘well duh’ to all of this but my teacher has always been experience.