Improving application performance over the network is the main goal of most people performing application testing, right? Everyone wants their applications to run well for their end users, after all happy end users = a happy and healthy (low stress and high growth) enterprise.
We often deal with web based applications and focus on improving the load time of web pages under various network and user load conditions. In most cases the motivation is straight forward, application stakeholders are looking to deliver the best user experience from those applications. But recently I was involved with a client that was looking to reduce the load time of web pages for an entirely different reason – money.
This client is an online retailer that relies heavily on web traffic from sponsored ads. Until recently the client’s main concern was simply the quality of content on his web site, the more engaging it was the more relevant the ads were. But a few months ago, web site performance became a factor in Google’s Adwords Quality Score, giving priority to ads pointing to faster landing pages. So now the web site team had to focus on improving the speed in which pages were loading.
A successful implementation of this web site optimization project included testing web pages under various bandwidth levels (64Kbps – 3 Mbps) and latency (0 – 300 msec) looking for web page bottlenecks, fixing the bottlenecks and repeating the process.
Some of the culprits we found included:
- Blocking javascripts (js files that block other page content from rendering while the script is being loaded)
- Unoptimized CSS files
- Heavy images that needed compression (surprising, I know)
This was a fun project that highlighted the value of having a repeatable test environment for iterating through an optimization process. We were able to significantly reduce the web page load times and improve the effectiveness of the client’s advertising campaign.
What has been your experience with optimizing web page load times? What tools are you using?
Best,
Amichai
February 9th, 2009 at 1:43 pm
This is a great introduction to the ALM concept as it relates to web based content. The premise that speed can help drive traffic is even more important in online retail applications. Not only can speed help you attract more customers because of higher search engine placement, but it can also help you keep them.
We have found that most companies do not embrace a holistic ALM approach when they could without significant incremental investment and a substantial return. The approach I am advocating is additive to the approach outlined in your post and applies most directly to retail sites and other sites that generate revenue directly from their web applications. A sketch of the process can be found at http://www.absolute-performance.com/productsandservices/application-lifecycle-support and is summarized as follows:
Business Requirements: define application delivery requirements and use those to drive the technical requirements for the application and it’s delivery to your customers. The ongoing management/delivery of the application should be measured against those requirements in near real time
Development: develop your application as usual but add pre-production and iterative pre-release stress testing to identify performance bottlenecks in end user experience coupled to the underlying technology and fix the issues before you release to your customers. Adopt a “measure everything possible” approach that can follow the application into production. Application internals instrumentation should become part of the application release process.
Production: Use the instrumentation from the development phase to continuously enhance your ability to proactively deliver the application with the highest quality possible. Feedback from the production management team to development is critical. Enhancements to application monitoring happen here which are often not passed back to the development teams — make sure that is not allowed to happen.
Performance and Capacity Planning: Ongoing performance and capacity planning are crucial as you gain success with your application. It costs too much to get customers to loose them when you start generating the traffic and revenue volumes you were hoping for.
I’ll be writing more on these topics in my blog at http://www.absolute-performance.com/blog
-Jerry
February 11th, 2009 at 8:18 am
Jerry,
Thanks for the elaborated comment. I agree with the process that you outlined and hope to see more organizations embed performance throughout the development lifecycle. One suggestion that comes to mind is with regards to the instrumentation added by developers. It is crucial that developers add their own instrumentation to monitor their internal processes, this could shorten a troubleshooting situation from weeks to minutes. However as the performance centers tend to standardize on commercial performance tools that are blind to the internal application code, it becomes difficult to correlate the metrics collected by the performance tool with the internal instrumentation. One option is to expose the internally collected metrics, for example as a perfmon metric so it could be collected by external performance testing and monitoring tools.
Hope this helps,
Amichai