In my ATG Performance Tuning post I mentioned that how a user perceives the site performance impacts their behavior on the site, and that a fast site leads to more purchases/traffic/etc...

Here are some numbers to back that up:

• Amazon found that a 100ms increase in page response time led to a 1% DROP in sales, or conversely improving a page response time by 100ms will increase sales 1%. I suspect that this effect continues beyond the 100ms mark, but probably tapers off at some point.
• Google found that an 500ms increase in page response time led to a 20% drop in traffic and revenue. This is despite the 3X increase in search results delivered (30 results instead of the default 10) to the test group.
• Google also found that a 30% reduction in page size resulted in 30% more traffic/usage due to faster loading and rendering.

Given the relatively low cost/time in performance tuning your application, the resultant gain of 1%-20%+ in revenue makes it a smart move.

"As Google gets faster, people search more, and as it gets slower, people search less"
-- Marissa Mayer, Google vice president of search products and user experience

This is also true for your website, just replace search with "buy", "read", etc...

In fact, I'll lay down a wager: If you improve the page rendering time of the most visited pages of your ATG site by over 10% or 100ms (which ever is greater), and you don't see any improvement in your goal conversion (purchases, sign-ups, whatever your measured goal is) I will give you an iPhone.

My up-coming posts on ATG Performance Tuning will make it easy to improve the page performance much more than that. I'd expect most ATG sites can cut the user experience of page loading and rendering time by 50%, or more, based on the advice I will be posting here.

So check back often!

How to improve the page load time and rendering time for your ATG application!

How your users and customers perceive the speed of your site is critical. The faster and more responsive your site appears to them the better experience they have and the more likely they are to make a purchase. There are plenty of studies about page response time and abandonment, so I won't rehash the "why" of it here.

There are three components that drive how responsive a page feels to an end user:

1. Primary Page HTML response time
2. Primary Page DOM parsing time
3. Secondary Asset load time

The first component is driven by the server's request processing time (DRP service time), the page's HTML size, and the speed of the connection between your server and your end user's computer.

The second component is driven by the size and complexity of the HTML DOM tree.

The third component is driven by the number of secondary assets, such as JavaScript, CSS, images, Flash, etc..., the size of those assets, the speed of the network connection to those assets, and the cache headers of those assets (to avoid having to load them for each page).

So, we have to look at file sizes, DOM complexity, number of files, cache headers, the speed of request handling on the server, and the network speed between the user and the server.

That's a lot.

So where do we start?

Read the rest of this entry »

ATG performance tuning is not a Black Art. I have over 10 years of experience with ATG, and hopefully I can provide a guide to performance tuning your ATG application.

Improving web application performance is an often overlooked way to cut costs and increase sales. Complex ATG E-Commerce applications in particular are often left untuned due to the scope of the application and typical tight timelines of project cycles. It's not mysterious voodoo, and it WILL be worth the time you put into it.

Web application performance can be split into two sections:

1. The End User's perception of the site performance
2. The Server's perception of the site performance

The first section relates to how quickly pages render for the user and how responsive the site feels. The less time the user spends waiting for the page to load and render, the more likely they are to make a purchase/sign-up/or whatever your conversion goal is. Relevant metrics would be page load time, page asset load time, and page render time.

The second section relates to how many users or transactions an application server can support with acceptable response times. Relevant metrics would include requests per second within the context of reasonable CPU load, I/O wait, etc...

Luckily many of the change we end up making to improve the end user's experience will also reduce the processing and request load on the servers, so there are some inter-dependancies.

I'm going to tackle the two sections of web application performance in two separate blog posts here, and hopefully will show you how to diagnose the poorly performing aspects of your site, figure out the biggest improvements you can make, and implement the changes. While these posts will focus on ATG based applications, much of what I'm going to cover is true for any web site or web application.

Once they got it working (I'm the first in my area to get it so there were a few kinks to be ironed out) is awesome!!!

Yahoo mail servers have been consistently delaying or rejecting e-mails for over a year. You can read about it here:

http://www.ahfx.net/weblog.php?article=107

Or just Google for "4.16.50".

The short of it is that even with a low volume personal mail server, with the correct spf records, without running an open relay, without being blacklisted by ANY blacklist site/service, Yahoo still won't deliver e-mail from you. And they aren't responsive about addressing the problem.

So please, if you use Yahoo mail, switch to GMail. You'll like it more, and more importantly, you'll actually get e-mail people are trying to send you.