Ben J. Christensen

Software Development and Other Random Stuff

Statistics for Why Web Performance Matters

Following are some good posts with further evidence of the impact of webpage/webapp responsiveness to the user experience, amount of usage and ultimately revenue.

Good introductory quote to the external links and images shown below:

There’s no longer any debate. There’s reliable, reproducible evidence that web page latency is directly tied to the bottom line. At Velocity, Microsoft, Google and Shopzilla made this abundantly clear in a series of awesome presentations: detailed, controlled testing proves that slower pages hurt the bottom line. In Google’s case, adding delay reduces the average number of searches a visitor does each day even after the delay is removed.

Regarding “smaller scale” sites more typical than Google and Bing:

The results of their analysis show how significant a reduction in page latency can be. In addition to reducing bounce rates, and increasing pages per visit & time on site, they found a 16.07% increase in conversion rates and a 5.50% increase in average order value.http://radar.oreilly.com/2009/10/watching-websites.html

External Links:

http://radar.oreilly.com/2009/10/watching-websites.html
http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html
http://www.watchingwebsites.com/archives/proof-that-speeding-up-websites-improves-online-business

Good summary PDF showing metrics of performance impact.

conversion-rate-and-order-value

bing-delayimpact

Filed under: Performance, Production, User Interface

Speed of Thought

I’ve focused on performance for several years in my server-side and web application development – as much as I’ve been able to fit into the timelines. It has involved digging into minute details of Java and JVM tuning that rarely get explored by most java developers (from what I can tell anyways) and focusing on tuning the CSS, images, caching, GZIP and other settings of the front-end. It has generally paid off. Today my team operates servers processing millions of complex, dynamic, uncacheable web service transactions completing on average in around 250ms each (server side, not including network transport to client). I believe with further investment we could improve that even more.

I have read comments from companies such as Google and Amazon how the performance of an application can dramatically affect how much people use it. I agree. The slightest friction in searching makes me search less, or shop less, etc.

This past week I’ve been using the new iPhone 3GS which is at least 2x faster than the previous iPhone 2G I had. In some cases it’s 4x and 6x faster.

I already used the iPhone a lot. The increase in speed has further reduced the “friction” of use to the point that if I even have a thought of quickly looking something up or performing some other action, I am much more likely to do it.

On my last iPhone, I consciously chose to not bother at certain times because of the time it would take. Yes, I’m talking in seconds and even milliseconds here — but when it’s a “thought”, if the tool doesn’t work at the same speed, then it’s friction. Same goes for another application I use which involves looking up reference materials and documents. Before I kind of had to avoid “flipping around’ while someone was referring to things. It was actually faster to use the paper documents. Now, I can keep up or be faster with my iPhone than the paper version ‘users’. Therefore it encourages use.

The new user experience of using the iPhone 3GS, so significantly improved just by the performance improvement, has reminded me as a developer and architect how critical it is to design, plan for and develop to achieve high performance. Functionality isn’t enough — we should be aiming for the “speed of thought”.

Interestingly, Google has just launched a new site just for “speeding up the web“.

The following video shows “the experts” talking about how the human mind perceives changes of 100ms (one tenth of a second).

It’s my belief that this isn’t just a “nice to have” feature. If a product, service or application wants to be adopted and deemed “necessary” by its users, its performance must reduce friction as much as technically feasible to the point where it approaches or achieves “speed of thought”.

Filed under: Architecture, Performance, Production, User Interface

Charts with Javascript

Filed under: User Interface

WebApp Performance Optimizations

Playing around with real-world performance optimizations found JSMin to work quite well … and very big gains by doing the following:

- combining multiple Javascript files into a single file
- using a JSMin servlet filter to minimize and cache in memory the Javascript file to return
- adding a filter to add HTTP Header caching to static files
- reducing file sizes for product images

Filed under: Performance, User Interface

Javascript optimization?

From what I can tell … the best bets are:

Use this to minimize file size: http://alex.dojotoolkit.org/shrinksafe/

Then enabled mod_deflate rather than mod_gzip

… make sure Apache is doing compression in memory, and not on the filesystem.

Then, actually change JS and CSS filenames each time they change so we can forcefully set very long cache refresh times so they never expire.

Filed under: Performance, User Interface

Javascript and CSS Optimization

Some good links on the subject …

http://yuiblog.com/blog/2006/10/16/pageweight-yui0114/

http://www.crockford.com/javascript/jsmin.html

http://dojotoolkit.org/docs/compressor_system.html

http://www.thinkvitamin.com/features/webapps/serving-javascript-fast

http://www.die.net/musings/page_load_time/

Filed under: Performance, User Interface

Multithreaded in Javascript

http://www.onjava.com/lpt/a/6539

Filed under: Code, User Interface

More cool AJAX links …

On the Prototype website there are already links to these sites, but
they’re worth noting … I haven’t used them yet but likely will.

http://script.aculo.us/

http://openrico.org/rico/home.page

This e-mail is privileged, confidential and subject to copyright. Any unauthorised use or disclosure of its contents is prohibited.

Filed under: Code, User Interface

Twitter Updates

View Ben Christensen's profile on LinkedIn