Why UpdateControls are dangerous (or: why Fiddler is a great tool)!
The next days I will have a deeper look into web sites that are using AJAX frameworks that will replace the typical postback used in ASP.NET.
Today I found a new job portal (http://www.dot-net-jobs.de/) using the Atlas framework to allow paging throug a list of job offers. I started Fiddler to see how the page is using the framework and what data will be transferred during the AJAX calls.
I deleted my local cache of Internet Explorer and entered the URL. After everything was loaded I checked Fiddler to see each request. The default.aspx showing the inital page is about 17 KB, then the Atlas framework is loaded using the WebResource.axd, the size is about 243 KB. Because I'd like to compare this web site using AJAX or not I don't want to have a look at the size of the css file and images (these are cached after the first call).
Now, I'd like to go to the next page using the weiter link (German translation for next). In Fiddler I see the request using the Atlas framework. The request is returning 14 KB html source code, only 3 KB less then the complete initial page showing the same info. Saving 3 KB per page means: we need about 81 clicks on weiter to save traffic!!
243 KB JavaScript / 3 KB saved = 81 clicks
The next thing I noticed is that maybe the web.config configuration for Debug is set to True. The Atlas framework JavaScript file (WebResource.axd) is not cached locally, so each visit it will be again 243 KB for this file. For more details on this read the Scott's article Don't run production ASP.NET Applications with debug="true" enabled.
One thing you have to look at when using AJAX-styled web applications is that you may lose several features (is not an Atlas only problem, most AJAX framworks do not have an build-in support for these problems):
- If you use backspace or the back arrow (history buttons) it will not work because everytime only parts of the web page will be replaced. There are several ways to add this support by changing the document.location of the document using anchors.
- The feature to open a link in a new window (either by pressing shift while clicking on the link or using right click -> open in new window) will fail because every link in the web page is using JavaScript code. This will end in an error because the JavaScript is not working in a new window where the function is missing.
- The next problem is that search engines (crawlers) will only find the start page, sub pages will not be found.
I hope we will find more and more things where we have to be careful using AJAX frameworks.
6 Comments
Comments have been disabled for this content.
scottgu said
When debug="true" is set two things happen:
1) The script library gets downloaded on each unique page you visited.
2) The script library is un-compressed. When compressed it is about 50k total and is cached forever for the site -- so applies to all pages and survives the browser being reset.
If you look at the page you linked to, almost all of the content is updated when you click next. That is why there isn't a huge difference in html download size between doing a normal post-back (the only non-ajax part of the page is the menu).
With the <atlas:updatepanel> control you can select portions of a page to be updated conditionally with Ajax callbacks. So one approach that we usually recommend is to partition pages into multiple updatepanels so that only those parts that need to be updated are updated (this saves a lot of network bandwidth).
Scott
Bertrand Le Roy said
Using an UpdatePanel is not so much about saving bandwidth as it is about providing a more fluid experience.
Making your point with a poorly configured site is probably not the most objective thing you've done.
Paul Glavich said
Your absolutely right Michael. The debug=true was in the web.config. Good catch too. It was a case of laziness on my part. I am constantly working on the site and the last set of modifications were really just tests and had since been removed, and I was still working on the site, but had other priorities come up so it was left in this "half state" with debugging on.
I have since turned it off, and am about to do some more mods to the site so I need to make sure I dont get side-tracked again and leave it as is.
Also, FYI that Atlas functionality on my site is still really just a plaything and not what I would class as really enhancing useability (perhaps apart from the UpdatePanel on the downloads section). I hope to be revamping how its all done soon and really make much better use of it.
MDR said
Hey Micheal, yes you do point out alot of subtle flaws that developers who jump on the AJAX band wagon "because it's cool" make. Microsoft's Hotmail is a fine example of this at work. the Non-AJAX version takes 1 second to load, 1 second to click an email and open it and you can easily open it in a new window or new tab. All told it probably takes under 5 seconds to go from Logged in to viewing a new email (3 page loads). Microsoft's beta hotmail takes almost half a minute on the same machine just to laod the main page. That's not counting opening an email and it's not letting you choose to open it in a new window or a new tab. Alot of subtle flaws and improper testing and alot of bandwagoning being done.
Christian Kiefer said
in the page www.dot-net-jobs.de web.config configuration for Debug is definitly set to False.
interactive said
But why is the client-script framework not cached on the local PC? Maybe there is still a bug in Atlas??