XMLHttpRequest Misuse on Page Load with AJAX Written on February 27, 2011, by danbrown.
Introduction
XMLHttpRequest is a JavaScript function that allows the core dynamic data part of AJAX (Asynchronous JavaScript And XML) to work. It lets JavaScript running in a web browser call a URL on the same server and receive data back again to process. Either normal HTML, XML or any format such as JSON can be returned and the JavaScript can do what it likes with it. This lets the page update itself or submit a form without making the whole page refresh which typically gives the user a much better experience. Obvious examples are a news website with up-to-date news ‘ticker’-style headlines or live sports commentary, Viewing more comments in YouTube, Search engine pop-up suggestions as you type, and so on.
The Misuse
“When you have a shiny new hammer, every problem looks like a nail.”
As a way to update a page or get new data according to user actions or a timer this is incredibly powerful. But I see so many sites using it as a way to fill in the initial content during the initial page load. Apart from slowing down the overall page load itself by making additional requests to the server, it gives a jarring wait when it looks like it should have finished but then goes on to display ‘Loading…’ or worse, nothing. I am not writing this to give a flashy solution, it should be obvious for developers. I wrote it to raise awareness that it is a problem.
As an example, and not picking on him in any way, Ben Marsh made a hit website last year that became very popular during this winters snow and I’m sure will again in the future – http://uksnow.benmarsh.co.uk/. As a social content aggregator and public service it worked fantastically and I spent a large amount of time there myself watching the weather move around the UK. But watch what happens when you load/refresh the page… The main part loads, the Google Maps interface comes up and the tweet panel sits there empty with a message at the top saying ‘Updating tweets’… He had to cache the messages on his server to avoid the twitter API locking him out so it is all stored there to use. So why are we waiting? The data can’t have changed significantly in the few seconds since the page loaded so why isn’t the list pre-populated as part of the page load itself? It makes the page extremely slow to load, especially when the server load was very high in the worst of the cold spell.
A worst-case example was a mapping component I saw on an internal government department website. In IE8 and Firefox it cached things and worked reasonably but in IE6, which we are forced to use at work, it reloaded every icon and menu item multiple times (over a thousand requests for a single refresh) after the page load. It sometimes took a full minute to bring the map system up fully… This wasn’t even dynamic content! The map part worked fine once it was working, it was the map layer menu and fixed icons that it was reloading which would have stayed the same for months at a time. It was live for about a week before they had so many complaints that they had to go back to the old ActiveX version which they still use six months later. They also have a site main menu that loads via AJAX after the page load and a few forms that reload several seconds after the page has loaded, resetting the focus and making me type into nothing until I notice half a blank sentence later.
Why it happens
The reason for this, I believe, is a misguided attempt to avoid duplicate code – One block for the AJAX handler and another almost identical on the page load. As developers it is easy to look for ways to re-use code (or just avoid re-writing it again), put two and two together and decide to use the AJAX version for both purposes. Running on a local unstressed web server it is pretty responsive and people may either not test it remotely or work in a company where the production server is also local. This means they never notice how slow and/or visually odd it is for real world users.
Another reason that this may sadly become more common is Googles recent announcement that they may take page load time into account for rankings. Some web spiders (although not Googles I believe) don’t do JavaScript and so will see the empty page as the full load time. Misusing XMLHttpRequest this way will let them get a better ‘score’ on some phrase if that search engine adopts the time measurement also.
This does cause another SEO problem with bots that can’t follow AJAX requests – If the initial data never gets loaded, it can’t be indexed. So no free secondary ‘splash’ search engine ranking when a phrase matches something in their content. Plenty of non-techy website owners that use cheap outsourcing facilities would put page rank on a specific page/phrase above this other method of getting free incoming traffic as they simply don’t know about it. The 2nd world ultra-low budget bulk outsourcing firms aren’t going to care which method they use if they can claim to boost pagerank.
How to avoid
Very easily -
Make both your AJAX handler and the main page generating code call a common function which generates the content. Tada! – code reuse and faster, smooth page loads for users.
Your page size will go up. That is saved by not having to do a second server request so it actually ends up about the same bandwidth used apart from in one case – If your original page can be cached. It’s up to you if the slight bandwidth saving is worth giving your users/customers a worse experience for. If you have an e-commerce site you should already know how fickle a large percentage of customers can be and a very slow page load can be a good enough reason for them to leave your site and go to the next one the search engine suggests.
Conclusion
Test your sites remotely on a stressed server to see it the same way a user does.
There are valid reasons to use XMLHttpRequest this way, mainly if the user expects it not to be instant anyway. Google Maps is a good reason to load content just after the page load as it can’t tell browser dimensions until then.
Are there any others? Have you noticed this as a problem as well or do you think it isn’t worth worrying about?
Leave feedback in the comments if you want.
Read more from the Coding, Rant, Webdev category. If you would like to leave a comment, click here: Comment. or stay up to date with this post via RSS
Social Bookmark :
Technorati,
Digg,
de.licio.us,
Yahoo,
Blinkbits,
Blogmarks,
Google,
Magnolia.
Leave a Comment
If you would like to make a comment, please fill out the form below.