The book contains extensive performance/load test results giving you hard data to work with when deciding which changes to make in your environment.  Some of the results were very surprising and the book has a lot of valuable data.

The author, Francesco Marchioni, also runs a popular JBoss related blog called MasterTheBoss.com.  There are a ton of great articles and posts there, so check it out!

I strongly disagree with the first tutorial however. CSS: Using every declaration just once.

The premise of the tutorial is that in order to make your website faster, you should make the code you send to the browser smaller (TRUE) and that one of the best ways to optimize CSS files is to use every declaration just once. This second part is the part I disagree with so strongly.

Basically the author recommends reversing the standard organization of the CSS declarations. Here are the before and after examples from the tutorial:

Before:

h1, h2, h3 { font-weight: normal; }
a strong { font-weight: normal !important; }
strong { font-style: italic; font-weight: normal; }
#nav { font-style: italic; }
.note { font-style: italic; }

After:

h1, h2, h3, strong { font-weight: normal; }
a strong { font-weight: normal !important; }
strong, #nav, .note { font-style: italic; }

So instead of having your selector/class/id contain all of the relevant styling declarations, you group the relevant selectors for each declaration. It’s changing the traditional one-to-many relationship of selectors and style declarations to a many-to-one relationship.

The upside, and the premise of the article, is that this reduces the size of the CSS by reducing duplicate lines of declarations. This is true, but is a very small upside compared with the downside.

The downside of this is that it makes writing, maintaining, and debugging your CSS MUCH harder. The styles applied to a given selector/element/class/id are now spread out over the entire CSS file.

If you’re a Java developer, this is akin to re-factoring every property in every bean you have into their own interface (since Java doesn’t do multiple inheritance) and having each bean implement a huge number of these interfaces. It’s backwards, and makes maintaining your application amazingly difficult.

The other thing is that the CSS file size savings are only 20-40%. If you’re gzipping your CSS files on your web server and setting a far futures expiration header (and you are doing both of those things, right?), then the savings are closer to 2-4%. Totally not worth it considering the downsides above.

Mr. Slow by Vox

An application I’ve built is going into production soon. It’s the first application I’ve been involved with which will be using MSSQL server in production, I have some learning about MSSQL to do. After some research, I ended up using the jDTS JDBC driver instead of the Microsoft JDBC driver (which is feature incomplete and has some serious open issues).

We recently began performance testing and saw some odd behavior. Initially the application was performing well. However after few runs of the stress test the performance went from good to awful. The main web service call went from 600 ms to 23,000 ms. The database server’s CPU was pinned, and the app servers were barely loading, spending all their time waiting for the database server to return queries. Stranger still, my local instance (running against PostgreSQL) performed well with the same code and same stress tests. Luckily a smart MSSQL DBA was able to figure out why the database was burning so much CPU and responding so slowly.

One of the primary queries is against a table which has been growing. The select query is simple and had an indexed column in the WHERE clause. Even as the table grew to over a million rows, it should have been a very quick query. Unfortunately it was taking several seconds to complete. My local instance had over 30 million rows in the same table in PostgreSQL and the query was lightening fast. The DBA discovered that the query execution was converting the indexed varchar column into nvarchar values for comparison with the query parameter used in the WHERE clause which was inexplicably coming over as an nvarchar. This datatype mismatch between the column definition and the query parameter meant that MSSQL was doing a scan of the million+ record index instead of the almost instant seek it should have been doing.

It turns out that jTDS sends String parameters over as Unicode (nvarchar) by default. It’s easily fixed by adding this property to your connection-url:

sendStringParametersAsUnicode=false

That immediately fixed the performance issues.

So, if you’re using jTDS and are using indexed varchar columns in your queries, you should add the property above to avoid your indexes being wasted and your queries running slowly.

Rather than waste your time playing with Photoshop export settings for each image, you can now use Smush.it, a web applicaiton built to shrink your image files for you:

Performance just got a little bit easier. Optimizing images by hand is time consuming and painful. Smush it does it for you.

I’ve used it on a few images, and so far I’m impressed with the results.

Do you have any handy tricks for optimizing the size of your media files?

• Akamai
• Mirror Image
• Multicast Media
• Limelight

End user performance is typically increased roughly 20-25% by the addition of a good CDN solution. This does not count the reduced capacity requirements of your server farm, which is an added bonus.

A Content Delivery Network, or CDN, is essentially a system of geographically distributed web servers which serve static content, typically images, video, and other bandwidth intensive files. This serves two purposes: it keeps your servers from having to handle those requests and it serves those files to the end user from a low latency server closer to the user (network-wise). Both of these aspects improve the user’s perception of page and site performance. CDNs can also be extremely useful for things like streaming video or other very high bandwidth uses.

How do CDNs work?

CDNs typically work in one of two ways: for some you have to deploy the files to the CDN manually via FTP or some similar mechanism while others work as a transparent proxy automatically loading the files from the source or origin (your servers) into the CDN as users request them. The latter is preferable as you don’t need to take the CDN into consideration when building your application’s page and referencing media, this also makes handling non-production environments more complex. Also it allows the media to be reloaded from the origin based on cache expiration headers, so you don’t need to do anything special during deployments of new media. However those CDN solutions also seem to be more expensive, so it’s a balance you have to weigh yourself.

Roll Your Own Apache Pseudo CDN

You can also roll a pseudo-CDN yourself using Apache. I call it a pseudo-CDN because unlike Akamai and other large providers you don’t get the advantages of hundreds or thousands of geographically distributed servers. You also don’t get lots of fancy math routing user’s requests to the quickest servers based on location, network congestion, and more. What you do get is transparent proxying and off-loading the request handling from your application servers.

This means you don’t have to do anything special or complex when coding your web application and your JSPs to facilitate the CDN, and it means that your application servers are freed up from having to handle the requests for static media, large and small, which means they have more CPU time available for handling the real dynamic processing of your web application.

Apache makes this simple by way of the mod_disk_cache module. I’d recommend avoiding the mod_mem_cache. Even though it sounds like it would be the preferred caching mechanism, I have had significant problems with mem_cache, and have abandoned it. If you’re using Linux (and you should be) the kernel’s ability to aggressively cache recently accessed files means that when you’re using mod_disk_cache, Apache will cache the files you specify on the local hard drive and will use all available RAM to cache those files in memory for rapid serving. If you plan on using mod_gzip and mod_disk_cache together, please read my post on the issues encountered using them together.

The reason that these secondary page assets are so critical for page performance is two-fold. First, there are many more of them for each page than the single HTML file. This means more HTTP connections have to opened and closed, more files have to be transfered from the server to the user’s computer. This takes a lot of time. Second, most of these assets tend to be static, they don’t change very often. This means we can cache them.

Reduce the number of assets

The first thing we need to do is to try to reduce the number of secondary assets which need to be loaded. You can try to simplify the page design to require less assets, reduce the number of images used, replace images with text (which is more accessible and search engine friendly anyhow), etc… Also reducing large files like videos and Flash files can make a significant improvement on page load times. Personally, for things other than video players and similar things, I strongly dislike the use of Flash. There is an impressive amount of rich interface and interaction that can be created using DHTML and AJAX. It generally performs better, loads faster, and is easier to make search engine friendly.

Another approach is to try to combine multiple CSS or JavaScript files into a single CSS file and a single JavaScript file. However, this makes managing the CSS and JavaScript during development much more difficult, especially if you’re using 3rd party CSS or JavaScript files or libraries. So I don’t do that. There is a great taglib which solves this problem for you. pack:tag. This tag library allows you to reference multiple JavaScript or CSS files from your JSPs. It then merges the files together and optionally minify and gzip compresses them. This allows you to develop and maintain CSS and JavaScript files which are organized logically by functionality, and yet only serve a single, minified, gzip compressed, JavaScript or CSS file to the end user. This can be a huge benefit. For instance the BestBuy Televisions page we used as an example before references 23 external JavaScript files. Reducing that down to 1 minified file would dramatically increase the performance of the page.

While we’re talking about JavaScript, try to put the JavaScript references at the bottom of the page, this reduces the time the browser waits before rendering the DOM tree. And you should also put the CSS scripts inside the head of the HTML document.

We can also reduce the number of images we request by using CSS Sprites. This is method of putting a number of small images into a single large image and referencing the images based on the coordinates. The downside is that you have to manage/edit the images within the single large image file. The upside is you can dramatically reduce the number of HTTP requests for images to build the page.

Reduce file sizes

We need to also reduce file sizes, if we can. Images, Flash files, video files, etc… should all be examined to ensure they are encoded for the minimal size possible and to still maintain the quality needed.

Caching files

Now that we’ve reduced the number of files that need to be loaded, and ideally their size, the next step is to reduce the number of times they need to be loaded. Your basic website will use the same general CSS file(s) and maybe a few commonly used JavaScript files, the same widgets and design images on almost every page. The default behavior is for the browser on the end user’s computer to request those files each time a new page is loaded. This is obviously wasteful. By setting the appropriate HTTP headers in the response with a file, you can tell the browser to cache the file for some period of time, and not request it again. This lets the subsequent pages use an image or CSS file that is loaded from the end user’s computer (memory cache or hard disk cache), which is much faster. Many times those files can be safely cached for days or weeks, which means every time the end user returns to your site, the pages load rapidly.

If you’re using ATG on DAS, you can use this ATG pipeline Servlet I create to set the cache related headers easily. If you are using JBoss as your application server then you’ll want to look at this cache header managing Servlet filter that I wrote.

Summary

At this point the user’s browser should be requesting fewer, smaller secondary assets to display the webpage, and should only be requesting them once (per expiration time period-week or day). Not only does this make pages load much more quickly, but with the use of caching the static content on the browser, you’ve dramatically reduced the number of HTTP requests that hit the server, thus freeing up your web application cluster to handle more users and page requests on the same hardware. Plus it reduces your bandwidth used, which can save money.

Since the DAF pipeline is only executed for JSPs the pipeline Servlet it doesn’t allow you to set headers for the static media items you’re more likely to want to cache. I created a Servlet Filter which allows you to set cache headers in JBoss based on URI patterns. It doesn’t allow the same fine grained control that the old pipeline Servlet does, but it should work for most situations.

Servlet Filters are very similar to ATG pipeline Servlets in that they are executed within the lifecycle of a request and can read the request and modify the response. The filter I created gets configured from the web.xml and sets the response headers relating to caching. You can configure different instances of the filter for each cache time you need, an hour, a day, or a week, and map different URL patterns to the appropriate instances.

I’ve added the filter into Foundation, the open source ATG e-commerce framework project, which is hosted at the Spark::red Development Community.

The Servlet filter code looks like this:

package org.foundation.servlet.filter;

import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.Locale;
import java.util.TimeZone;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

/**
 * The Class CacheHeaderFilter.
 *
 * @author Devon Hillard
 */
public class CacheHeaderFilter implements Filter {

    /**
     * The Constant MILLISECONDS_IN_SECOND.
     */
    private static final int MILLISECONDS_IN_SECOND = 1000;

    /** The Constant POST_CHECK_VALUE. */
    private static final String POST_CHECK_VALUE = "post-check=";

    /** The Constant PRE_CHECK_VALUE. */
    private static final String PRE_CHECK_VALUE = "pre-check=";

    /** The Constant MAX_AGE_VALUE. */
    private static final String MAX_AGE_VALUE = "max-age=";

    /** The Constant ZERO_STRING_VALUE. */
    private static final String ZERO_STRING_VALUE = "0";

    /** The Constant NO_STORE_VALUE. */
    private static final String NO_STORE_VALUE = "no-store";

    /** The Constant NO_CACHE_VALUE. */
    private static final String NO_CACHE_VALUE = "no-cache";

    /** The Constant PRAGMA_HEADER. */
    private static final String PRAGMA_HEADER = "Pragma";

    /** The Constant CACHE_CONTROL_HEADER. */
    private static final String CACHE_CONTROL_HEADER = "Cache-Control";

    /** The Constant EXPIRES_HEADER. */
    private static final String EXPIRES_HEADER = "Expires";

    /** The Constant LAST_MODIFIED_HEADER. */
    private static final String LAST_MODIFIED_HEADER = "Last-Modified";

    /** The Constant CACHE_TIME_PARAM_NAME. */
    private static final String CACHE_TIME_PARAM_NAME = "CacheTime";

    /** The Static HTTP_DATE_FORMAT object. */
    private static final DateFormat HTTP_DATE_FORMAT = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z", Locale.US);

static {
HTTP_DATE_FORMAT.setTimeZone(TimeZone.getTimeZone("GMT"));
}

    /** The reply headers. */
    private String[][] mReplyHeaders = { {} };

    /** The cache time in seconds. */
    private Long mCacheTime = 0L;

    /**
     * Initializes the Servlet filter with the cache time and sets up the unchanging headers.
     *
     * @param pConfig the config
     *
     * @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
     */
    public void init(final FilterConfig pConfig) {
        final ArrayList<String[]> newReplyHeaders = new ArrayList<String[]>();
        this.mCacheTime = Long.parseLong(pConfig.getInitParameter(CACHE_TIME_PARAM_NAME));
        if (this.mCacheTime > 0L) {
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, MAX_AGE_VALUE + this.mCacheTime.longValue() });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, PRE_CHECK_VALUE + this.mCacheTime.longValue() });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, POST_CHECK_VALUE + this.mCacheTime.longValue() });
        } else {
            newReplyHeaders.add(new String[] { PRAGMA_HEADER, NO_CACHE_VALUE });
            newReplyHeaders.add(new String[] { EXPIRES_HEADER, ZERO_STRING_VALUE });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, NO_CACHE_VALUE });
            newReplyHeaders.add(new String[] { CACHE_CONTROL_HEADER, NO_STORE_VALUE });
        }
        this.mReplyHeaders = new String[newReplyHeaders.size()][2];
        newReplyHeaders.toArray(this.mReplyHeaders);
    }

    /**
     * Do filter.
     *
     * @param pRequest the request
     * @param pResponse the response
     * @param pChain the chain
     *
     * @throws IOException Signals that an I/O exception has occurred.
     * @throws ServletException the servlet exception
     *
     * @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse,
     *      javax.servlet.FilterChain)
     */
    public void doFilter(final ServletRequest pRequest, final ServletResponse pResponse, final FilterChain pChain)
            throws IOException, ServletException {
        // Apply the headers
        final HttpServletResponse httpResponse = (HttpServletResponse) pResponse;
        for (final String[] replyHeader : this.mReplyHeaders) {
            final String name = replyHeader[0];
            final String value = replyHeader[1];
            httpResponse.addHeader(name, value);
        }
        if (this.mCacheTime > 0L) {
            final long now = System.currentTimeMillis();
             final DateFormat httpDateFormat = (DateFormat) HTTP_DATE_FORMAT.clone();
            httpResponse.addHeader(LAST_MODIFIED_HEADER, httpDateFormat.format(new Date(now)));
            httpResponse.addHeader(EXPIRES_HEADER, httpDateFormat.format(new Date(now
                    + (this.mCacheTime.longValue() * MILLISECONDS_IN_SECOND))));
        }
        pChain.doFilter(pRequest, pResponse);
    }

    /**
     * Destroy all humans!
     *
     * @see javax.servlet.Filter#destroy()
     */
    public void destroy() {
    }

}

And the web.xml configuration looks like this:

	<filter>
		<filter-name>CacheFilterOneWeek</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>604800</param-value>
		</init-param>
	</filter>

	<filter>
		<filter-name>CacheFilterOneDay</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>86400</param-value>
		</init-param>
	</filter>

	<filter>
		<filter-name>CacheFilterOneHour</filter-name>
		<filter-class>org.foundation.servlet.filter.CacheHeaderFilter</filter-class>
		<init-param>
			<param-name>CacheTime</param-name>
			<param-value>3600</param-value>
		</init-param>
	</filter>

.......

<filter-mapping>
		<filter-name>CacheFilterOneDay</filter-name>
		<url-pattern>*.js</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneDay</filter-name>
		<url-pattern>*.css</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneWeek</filter-name>
		<url-pattern>*.jpg</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>CacheFilterOneWeek</filter-name>
		<url-pattern>*.gif</url-pattern>
	</filter-mapping>

There are two parts to this: first, the time it takes the JSP servlet to generate the HTML response, and secondly the time it takes to transmit that HTML response back to the user’s browser.

Caching content sections

The easiest way to reduce the time it takes for the JSP servlet to generate the response is by reducing the amount of dynamic content on the page. Or more precisely by reducing the amount of real-time or unique individual content on the page.

The Cache droplet is THE most under-utilized ATG droplet.

The Cache droplet caches the rendered output of the contents of the oparam based on a content key (such as category, user gender, logged in/logged out state, etc..) for a configured period of time. This can be very useful for things like navigation menus dynamically built based on the catalog. The catalog won’t change too often, so this dynamically generated menu can be safely cached for hours. Or for some or all of a category or product page, when you set the key to the category id or product id.

Look at your pages and evaluate what parts of the page don’t change that frequently. Even if you can only cache the page or block for five minutes, that can be a huge performance win.

Read on for more….

I’ll talk about things like repository caching and other related topics when I dive into the server side of performance tuning your ATG application in a future post.

Reduce CPU utilization in page rendering

You’re also going to want to look at potential CPU draining elements of your pages. Think about what has to happen to render the page. Don’t use RQLQueryForEach if you have the Repository Id you want, just use the RepositoryLookup droplet. Don’t loop through collections if you don’t have to. Think through it. If you have to do something computationally expensive, don’t do it twice. If you need the same data later just store the first result in a param or JSP variable.

Reduce the size of the HTML

Now that we’ve reduced the CPU time need to render the JSP, we need to reduce the amount of time it takes to transmit to the end user. First, we want to shrink the generated HTML. The smaller the output HTML is, the less time it will take to transfer across the wire to the end user. Also, you want to keep the HTML output under 100k, as Google does not index page content over the first 100k (that’s 100k ungzipped). Also, the smaller the HTML is, the quicker the browser can parse it out into the DOM tree.

Don’t use inline JavaScript or CSS styles in your JSP. Extract them out into separate JavaScript and CSS files. This reduces the size of the output HTML, and increases the amount of content that the browser can cache locally (more on this in my future post on secondary media).

Simplify the html structure as much as you can. Don’t use more tags than you need. I’ve seen an amazing amount of useless nested divs on pages.

Move comments from HTML comments to JSP comments (if you can). Most comments shouldn’t be seen by end users anyhow.

Reduce spaces. This is huge. JSPs (especially ones heavy in ATG droplets) tend to generate a huge amount of extraneous spaces. Part of it is that you generally want to format the JSP files using spaces and tabs to make it easy to see the tag hierarchy structure. It makes development and maintenance much easier. Unfortunately these linefeeds, tabs, and spaces get multiplied by iterative or recursive droplets, and other outputs.

For instance the ATG home page source has 431 lines. 103 are blank. The BestBuy televisions page has 2519 lines and 902 are blank. If you take that BestBuy page, and remove the extra blank lines, comments, and inline JavaScript and CSS, it goes from 98k to 80k. That’s a 20% size reduction, or a 20% transfer speed improvement.

If you’re using JBoss the Tomcat engine has an option to strip out extraneous whitespace. It doesn’t remove all of it, but it helps with multiple blank lines very well. In the tomcat55.sar/conf/web.xml file add the following init param to the <servlet-name>jsp</servlet-name> section:

<init-param>
     <param-name>trimSpaces</param-name>
     <param-value>true</param-value>
</init-param>

This, and other helpful performance configurations are listed in the Tuning Site Performance section of the Installation and Configuration Guide for JBoss Application Server ATG documentation. You should really read through the whole thing, and generally follow it.

Compressing the HTML response using gzip

Now we’ve reduced the size of the HTML the JSP is outputting. We can further shrink the data we need to send from our server cluster to the end user’s browser, hence making the HTML transfer faster, by compressing the HTML using gzip. Most modern browsers understand gzipped content and decompress it on the fly. Some don’t, and we’ll work around those in a moment.

Assuming you’re using JBoss for your application server and Apache for your web server, you actually have two options for gzipping the content: You can compress it from within JBoss Tomcat, or you can compress it as it passes through the Apache web server.

If you want to compress it within JBoss you can configure Tomcat to do that by editing the tomcat55.sar/conf/server.xml file. Find the connector you are using (the one with port=”8080″ for HTTP, or port=”8009″ if you’re using AJP) and add the following properties to that section:

compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml"

That should use gzip compression for output that is html or xml, and is greater than 2k in size.

I prefer to perform the gzip compression in Apache instead of JBoss/Tomcat. Firstly the Apache deflate module is more flexible than the Tomcat option, allowing greater control of compression based on path, mimetype, extension, browser, and more. Second in a three-tier infrastructure, the web servers are typically acting as pass-through proxies, plus handling some caching perhaps (more on this later), but are generally light on CPU utilization, but higher on thread and bandwidth usage. App servers on the other hand are using this CPUs a great deal to actually handle the dynamic application. Gzipping the outgoing content does use some CPU power, so I prefer to have that load be on the web servers who can handle it easily, versus having it impact the application performance.

To make Apache gzip compress the output, you need to enable mod_deflate.

You then need to configure the module using settings similar to this:

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE no-gzip 

# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSIE\s7  !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|swf|flv)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary

You can read more about this configuration, plus some issues that arise when using mod_disk_cache and mod_deflate together here. You can get around this by only gzipping html output from your JSPs, which you won’t be caching anyhow, however doing that in a clean fashion appears to be tricky. The AddOutputFilterByType directive doesn’t work with proxied content, and the mod_filter based approach for that is only built into Apache 2.1 and 2.2, so if you’re on 2.0 it’s no good. When I have a good solution for Apache 2.0 + ATG, I’ll post about it.

By gzipping the HTML we can reduce the BestBuy page further, from 80k to 14k, an additional 80% reduction. We’ve shrunk the data that has to transfer to the end user’s computer by a total of 85% at this point. This means the end user’s browser can parse the HTML dom tree, display the page, and start loading the secondary media (images, css, js, etc…) 85% faster. It also means your request handling thread is now free that much faster (after doing the actual processing of the JSP servlet) and is available to handle a new request.

Summary

So at this point we’ve made the JSP as efficient as possible, used the Cache droplet wherever we could, reduced the size of the output HTML, and gzipped the HTML for faster transmission to the end user. We’ve taken a 98k page and ended up only having to move 14k across the wire.

Next we’ll look at all those secondary media files that your page needs: JavaScript, CSS, images, video, Flash, 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!