Article

Application performance management today, part 4: The challenges of Ajax performance testing

Jack Vaughan

Requires Free Membership to View

From a test and quality standpoint, one of the challenges for developers and testers is that the applications are becoming more sophisticated.
Christopher Merrill
Chief engineerWebPerformance Inc.

Imagine it's 1999. Development and QA teams are relieved that the HTML browser is the client of choice for computing. While there have been fast network pipes to deploy and numerous browser compatibility issues to sort out, UI development and deployment have become easer than during the client-server era. End users are used to clicking on links and waiting for pages to download.

Now, fast forward to 2008. Dynamic HTML and Asynchronous JavaScript and XML (Ajax) applications are abundant. Flash and Silverlight are available as browser plug-ins delivering so-called rich Internet applications (RIA). End users expect faster interaction with interfaces. UI testing is suddenly complex again.

Although the birth of Ajax and RIA has not really changed the basic problems of client-side performance, the nature and amount of change in presentation architectures is beginning to tax the skills of testers.

There are several reasons why Ajax challenges established test plans. By moving more work to the client, it begins more to resemble the pre-HTML user interface. Ajax applications in and of themselves are more complex. Because Ajax works asynchronously, test programs are not able to assume state. How Ajax developers parse out their server calls affects performance and test strategies.

There is more. Like any language, JavaScript, which underlies most of what is called Ajax, presents unique test issues. By some measures, it is a verbose scripting language that can be especially difficult to debug. Testers must find where the JavaScript engine is bogged down and work with developers to architect around this. Ajax applications often tend to call several JavaScript programs, and the order in which the programs load must be accounted for by testers.

While some Ajax client test issues hearken back to the client-server era, others recall the early days of HTML when applications had to be tested against multiple browsers. Today, different browsers treat Ajax differently, and testers must calibrate for that.

Besides different browsers, testers must work with different flavors of Ajax. Many different Ajax frameworks, each with a different twist, have emerged. Since browsers were not originally built to support Ajax, different frameworks have different workarounds for browser shortcomings. Testers must adjust for such workarounds, which, in turn, may change with the next round of browser updates.

Ajax frameworks can vary in many other ways. The JavaScript Object Notation (JSON) format, for example, is gaining in use by Ajax architects as a method that improves JavaScript's object characteristics and somewhat supplants XML's position in the Ajax game. Different Ajax frameworks have different ways of encoding requests, and testers need to take the time to understand this means of messaging when harnessing Ajax applications.

Article series: Application performance today

Part 1: Problems and solutions

Part 2: Role of Java developer groups

Part 3: SOA performance management requires new strategy

Part 4: The challenges of Ajax performance testing

From a broad standpoint, said Matt Brayley-Berger, domain specialist for Borland's Silk Performer and Silk Test offerings, Ajax is not necessarily new. "It's new in that it has become very popular," he said. "And it changes testing on the performance side and the functional side."

But it is a moving target. "Ajax is more of a technique than a standard. There is no standard implementation," said Brayley-Berger, noting that he sees JSON-flavored Ajax becoming more popular than XML-flavored varieties.

Variety led to creativity, but since Ajax frameworks largely originated as open-source Web community projects from many sources, maintaining Ajax applications can be uniquely problematic.

"Before Ajax, we could ignore client processing. That is not true anymore," Brayley-Berger said. Testers must now look at how much work gets distributed to the client and how much to the server.

"Ajax is fraught with some good things and some bad things," he continued. "Its intent was to unload some of the processing from the server." But, he noted, JavaScript running in the browser incurs a security hit.

Meanwhile, the rush to Ajax has led to some "under-specified" application development. Brayley-Berger said a good question a tester may ask about an Ajax application is "Was it specified before it was built?"

The past few years have witnessed a swing toward Ajax clients, but there may be reasons for development managers to move toward RIA systems with stricter program boundaries. RIA is seen, for example, in Adobe Flash and Microsoft Silverlight.

"We are seeing a lot of challenges with security and with consistency," said Brayley-Berger. "In my opinion, Flex is the next wave when we get past Ajax itself."

In fact, while the latest Borland Silk test suite tool additions are ultimately aimed at better Ajax testing, the first support out of the box comes for RIA test scripting capabilities.

Ajax test problems
Ajax blurs the lines between a typical Web interface and a more traditional graphical interface, according to Christopher Merrill, chief engineer at WebPerformance Inc., a testing tools and services company. Ajax presents a special challenge for all types of testing, he said. Merrill contributes to the WebPerformance blog on performance issues.

"The test suites that we are aware of that are out there treat websites as a sequence of pages. If you take Ajax to its full extent, you cease to have more than one page. You have one page, rather than a sequence. And the page changes over time as the JavaScript manipulates the underlying object model.

"Where tools were specific to testing websites, you had the luxury of treating one page sort of as its own entity. Ajax removes that," Merrill said. "This requires the tool to understand more about the page than just sending a request to the server and getting a response back."

And now, when a tool has to simulate an Ajax application, it has to get all the page elements in the right order, where that may not have mattered before, Merrill added.

Hovering above all this is the plain fact that Ajax is a more complicated way of showing Web pages. "From a test and quality standpoint, one of the challenges for developers and testers is that the applications are becoming more sophisticated," Merrill said.

An "extreme Ajax application" is gong to be much more like a classic rich client application, he indicated. For example, with Ajax, the state of the application can persist from one operation to the next, which means all the possible routes to a given state have to be taken into account for each point you want to test. In other words, you can get to a state for an application in many ways.

The state of client-side state
At the Ajax Experience conference last year in Boston, Bob Buffone suggested there are similarities between Ajax performance issues and those found in traditional server-side object-oriented development. To avoid pitfalls, developers have to go back to the basics. Knowing your code, and how it does what it does, continues to be the mantra. The differences between Ajax architecture and more recent HTML application architecture must be reckoned with.

"It's a different environment because, with Ajax, the applications are stateful on the client-side. So it can be harder to capture and replay scripts for test," said Buffone, chief architect at Web client development tool maker Nexaweb Technology.

"Testers have to change the way they utilize their test tools. It's almost a migration back to client-server testing, rather than being forms- or page-based," said Buffone, who regularly covers Ajax performance on his RockStarApps blog.

Among good tools to figure through some problems, he noted, is Yslow, a Firefox plug-in, developed by Yahoo, that gives grades on use of resource requests and other factors in Ajax page creation.

JavaScript performance is quite intrinsic to overall Ajax performance. And it must be looked at from at least a couple of angles, Buffone said.

"I characterize JavaScript performance as runtime performance and startup-time performance. You have to deal with the issue that you run into with Ajax applications, which is that you are dealing with a whole bunch of JavaScript files. It could be 20 or 30. Plus you have multiple [Cascading Style Sheets]," he said.

A tool Buffone has noted for JavaScript profiling is jsLex, which systematically injects profile code.

The layers of complexity that Ajax can introduce may lead some development managers to rethink some Ajax plans.

"There are more abstraction layers in JavaScript programming," said Buffone, describing as example JavaScript calls to objects for drawing to screens. "I do see people running into limits. They should be aware: Ajax won't meet the needs of all their applications."

How performance is perceived
"In an Ajax application, you are trying to accomplish the same things you are trying to accomplish in a traditional application. You are trying to improve the perception of it," said Ryan Breen of Gomez Inc., which is focused on hosted tools that help customers design build, deploy and manage Web application performance.

"When you design an Ajax application you need to look at what you expect the user to do. The genius of an app like Google Maps is to anticipate what the next user call will be -- and do that," said Breen, who blogs and serves as Gomez's vice president of technology.

"One of the downsides of Ajax for the first year or two was that people would see an application like Google Maps and say, 'I want to do that.' But it isn't really easy to do. To build a quality Ajax application and meet performance goals, you have to start from the design stage to think about what your users are going to do."

Useful Ajax performance links
* Ajax Performance (Ryan Breen Blog) 

* RockStarApps (Bob Buffone Blog) 

WebPerformance  (WebPerformance Reports Blog) 

* How we improved performance on Google (Google performance tips) 

* Exceptional Performance: Best Practices for Speeding Up Your Web Site (Yahoo Developer Network) 

* Performance Pages (Ajaxian.com)

The future of Ajax holds more change. After a lull, browser makers may be ready to roll out updated software. "We are seeing all the major browser players coming out with new versions … and they all have pretty substantial tweaks driven by problems people are having," Breen said.

As an example he cites upcoming Microsoft IE 8 changes. "There are substantial changes to the number of connections you can make. The change [Microsoft] made was to allow you to make six connections per host at a time. Before, for every browser, it was two," he said.

Ajax frameworks, Breen noted, had workarounds allowing more connections. But these workarounds could cause havoc for some webmasters unaware of the increase in connections due.

Tools Breen highlighted for Ajax testing at last fall's Ajax Experience East Conference included IBM Page Detailer and (the oft-cited) Firebug for network visualization. He also mentioned Firebug, Firebug Lite and Dojo.Profile for client-side profiling.

Improving Ajax performance
Ajax unquestionably is a Web phenomenon. That same Web is a font of information on the subject of Ajax best performance practices. Programmers and testers both can benefit from their colleagues' experiences. Google and Yahoo, particularly, offer sage performance advice for Ajax application building. Both sites have been major drivers of Ajax use.

It may be said that the goal is not so much to reduce latency as it is to reduce "user-perceived latency" in Ajax applications. Thus, Jacob Moon of Google Developer Programs advises teams to focus on reducing the number of HTTP requests made on initial page loads and to combine JavaScript and CSS files each into single files to improve performance on Ajax code.

For its part Yahoo, offers a set of rules for speeding website performance. Again, making fewer HTTP requests is a basic means to achieve user-perceived client-side speed. The blog advises that 80% of end-user response time is consumed on the front end, mostly via component download. Reducing the number of components required to render a page is key to creating faster pages. Other basic advice from the Yahoo crew: reduce DNS lookups, avoid redirects, pare JavaScript code down to a minimum and reduce duplicate scripts.


There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: