Improving ASP.NET AJAX Performance ASP.NET

There are several ways to improve your ASP.NET AJAX performance.

Server-Side Rendering Versus Client-Side Rendering

The Ajax web portal can be rendered in two ways: from the server or from the client.Server rendering means that the HTML on a page, along with all the widgets, is created in server code, rendered by the server code, and delivered statically to browser. So, the browser just renders the HTML, loads the JavaScript (or Ajax framework,extenders, widget scripts, etc.), and initializes it. iGoogle is a good example of serverside rendering.

In contrast, client rendering means the content of the widget is not sent along with the page content. Once the scripts download and initialize, the page calls a web service to get the content of the widgets and dynamically creates the widgets on the page,one after another.

The advantages of server rendering include:

• Uses server-side technologies to their full potential.For example, it makes full use of ASP.NET features.

• Renders and delivers entire page to the client in one shot.If the page does not have too many widgets, the perceived speed is better than client-side rendering approach.

• Shows the content and then downloads the Ajax runtime, core scripts, widget scripts, etc., and initializes them later. Because the user sees the widgets before the whole page is downloaded, she feels it is a fast-loading page.

The disadvantages of server-side rendering include:

• The page’s cache output is delivered every time the user visits the site because it doesn’t know if the user has already changed the page on another computer or if the page’s content has changed by other means.

• All widgets need to be developed mostly using server-side technology like ASP.NET. You cannot have JavaScript-only widgets.

• If a widget does not follow the ASP.NET-style postback model, it will need a lot of support from a client-side framework.For example, you will have to provide support for features, such as expanding,collapsing, closing, and resizing, in the client framework and make sure the server is kept in sync with such client-side activities via web service calls.

The advantages of client-side rendering are:

• A server-side framework for widgets is not needed.

• Widgets can provide all functionality from the client side.

• Completely client-side web portals and widgets require zero postback, not even any asynchronous postback,which improves responsiveness.

• The response can be cached via a web service call. Thus, the next time the user comes back,the cached response is loaded from browser cache and rendered very fast. Just as Default.aspx is rendered from the server on every visit, you can easily decide whether to load page content from the cache or make a fresh call to get fresh page content if it has changed between the visits.

But the disadvantages of client-side rendering include:

• Widgets are mostly developed with JavaScript so they are a lot more difficult to develop than regular ASP.NET web controls.

• Too much JavaScript on the client side makes the browser slow unless the user has a powerful computer.

• Browsers’ debugging support is still very poor compared to server-side debugging support

Runtime Size Analysis

ASP.NET AJAX has a pretty big runtime that consists of the core framework, scripts for UpdatePanel,and a preview script that is required for drag-and-drop functionality. Additionally, we need the Ajax Control Toolkit.These requirements total a staggering 564 KB of download for 12 script references on the page.The download size mostly depends on the usage of extenders and Ajax features, so moderately using an extender creates the output in Figure.

A 256 kbps Internet speed simulation shows, which files are downloaded on the first visit to a site

A 256 kbps Internet speed simulation shows, which files are downloaded on the first visit to a site

To capture traffic and simulate slow Internet speed by throttling data transfer speed,I used a tool called Charles ( the durations, you cansee almost 20 seconds is spent on downloading the runtime over a 256 kbps line!Surely this is unacceptable speed.

The following is an explanation of what each script in Figure does. Entries starting with /Dashboard/WebResource.axd or /Dashboard/ ScriptResource.axd are Java-Script and the following list details functions by the size of the file.

21.64 KB
Handy script for postbacks

83.38 KB
Microsoft Ajax core runtime

30.16 KB
UpdatePanel, partial update, asynchronous postback scripts

136.38 KB
Preview version of Ajax that allows drag-and-drop script

36.02 KB
The actual drag-and-drop script in Preview library

45.25 KB
Ajax Control Toolkit

4.08 KB
Timer script

140.86 KB
ACT animation framework

18.05 KB
ACT behavior base implementation, which is required for Ajax Control Toolkit behaviors

16.48 KB
ACT animation behavior

7.32 KB
My custom drag-and-drop behavior

9.73 KB
My custom floating behavior

The total payload for the runtime only is too high—you cannot make a user wait 20 seconds just to download Ajax scripts before she can actually start interacting with the page. So, to reduce the size of the download:

• Eliminate the preview version of Ajax completely and use ACT for drag-anddrop functionality
• Use IIS 6 compression to deliver compressed scripts from the client
• Combine multiple script files into one file

ACT comes with its own DragDropManager, which is needed for drag-and-drop functionality. You could use Sys.Preview.UI.Drag DropManager, but the Drag Drop Manager alone adds nearly 180 KB of scripts for the entire preview library runtime.

By using ACT’s Drga Drop Manager, you can get rid of the preview runtime and improve response delay by seven seconds. Without the preview scripts,the scripts downloaded are shown in Figure

the scripts loaded without the CTP version of ASP.NET AJAX, which saves about 180 KB

the scripts loaded without the CTP version of ASP.NET AJAX, which saves about 180 KB

When IIS 6 compression is enabled, the situation improves dramatically as shown in Figure

IIS compression dramatically decreases the download size of each script

IIS compression dramatically decreases the download size of each script

The total download comes down from 448 KB to 163 KB, which is a 64 percent reduction!

The scripts are downloaded in two steps. First the core runtimes download, and then ACT and other scripts download.The content is displayed after the core runtime is downloaded. So,the time it takes to show content on the browser is reduced significantly because only 50 KB is needed to download before something is visible on the screen, compared to 130 KB in the noncompressed mode.

ScriptManager control has a LoadScriptsBeforeUI property that you can set to false to postpone the download of several scripts after the content is downloaded. This adds the script references to the end of the <body> tag. As a result, you see the content first, and then the additional scripts, extenders, and ACT scripts:

You can explicitly set ScriptMode=Release to emit highly optimized Ajax runtime scripts during local debugging to gauge their size on a production server.

Reducing Extenders and UpdatePanels to Improve Browser Response

Because extenders are downloaded and initialized, the fewer you have, and the faster the page will download and initialize. Each extender is initialized using a statement such as the following from the output of Default.aspx:

Here CustomDragDropBehavior is initialized. If the extender operates a lot during initialization,then browsers will get stuck, especially Internet Explorer 6. SometimesIE 6 will freeze while several initializations are happening. To avoid this, you need to avoid putting many extenders on widgets and yet somehow deliver a rich client-side experience.You could load extenders on demand when they are needed, e.g.,postpone the drag-and-drop initialization.Generally, a user looks at the page for a while before interacting with it,so you could easily postpone the drag-and-drop initialization using a delay timer. Another idea is to create extenders programmatically instead of putting them on the ASPX or ASCX code,which will group the initialization of extenders for a later time. So, instead of this:

<cdd:CustomFloatingBehaviorExtender ID="WidgetFloatingBehavior" DragHandleID="WidgetHeader" TargetControlID="Widget" runat="server" />

You can force it to happen later once the page is fully loaded and the browser is free for some heavy JavaScript operations:

var floatingBehavior = $create(CustomDragDrop.CustomFloatingBehavior,

{"DragHandleID":handleId, "id":behaviorId, "name": behaviorId},{},{},child);

Comparing Debug Mode Versus Release Mode

During performance testing,make sure you turn off debug mode. If it is on, Ajax will deliver debugged version of the scripts that are gigantic and full of debug statements.They are so slow that you will hardly be able to drag-and-drop widgets on IE 6, even on a dual-core machine. Once you switch to release mode, an optimized version of the scripts is used,which is quite fast.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

ASP.NET Topics