Bing and Google Agree: Slow Pages Lose Users

Scott Ruthfield [2009-06-23 04:58 PM]

Eric & Jake gave a great talk.

One of the first questions that business leaders ask technical teams worried about performance is "why should I worry?" - getting real data on the value of improving performance is hard (you can't really simulate it to your users), and we usually end up relying on anecdotes that fly around the web rather than real data.

Kudos to both Microsoft and Google for going in reverse and evaluating the one-time and ongoing cost of degrading performance, and making that data public. Now we have some real data to work with!

It's also worth noting that while the differences they saw were slight in % terms, their performance differences were also slight - most sites I talk to aren't worrying about 200ms or 400ms, they're worrying about 4000ms or 8000ms.

Jesse Robbins [2009-06-23 05:41 PM]

New features that slow a website down... aren't features at all. ;-)

-Jesse

Mike White [2009-06-23 06:30 PM]

i hate slow pages.

Preston Austin [2009-06-23 06:51 PM]

Back when under a few seconds load time was still considered a "good" page and aol dial up mattered a lot and still wreaked havoc with everything (late 90s) I was developing lots of little activities for a very popular children's web site. We saw traffic in excess of 5 million dynamic hits on a good afternoon and wrote our own stats package - so it was easy to measure fine changes in user behavior.

In an effort to increase kid's satisfaction with the site, we started experimenting with simplifying pages to get some kind of page showing _fast_ and then precaching subsequent content in certain non-game activities so that things would be gamelike - and happen near instantly on a click.

It was pretty interesting - we discovered that we could readily lengthen all of number of sessions, estimated repeat sessions, length of sessions, number of clicks per session, and most interestingly rate of clicks per session by pre-caching likely next moves while a child was viewing current content (we used various horrible hacks, and tools like Shockwave and later Flash to do this). To really make a difference, we had to get the response to clicks down under about 200ms.

Just another anecdote really, and the data are proprietary and likely forgotten in history, but these results governed my design approaches for years: If the interface isn't fun and responsive, its bad.

Its nice to see some serious validation from a massive player who can afford to really study these things that these impacts are significant - and very interesting that they are enduring.

David Lantner [2009-06-23 08:39 PM]

While the tests may have set a delay on the server-side, the origin of the Firefox/Firebug add-on YSlow comes from Steve Souders' research that identified the importance of client-side decisions, such as how/where/when to link to CSS, JavaScript and other page components. Google's Firefox/Firebug add-on Page Speed continues in this trend, going so far as to analyze the grammar used within the CSS.

These results provide useful data to support the (intuitive) assertion that speed matters - every millisecond - since they quickly add up to a degraded experience.

FaTe [2009-06-24 02:52 AM]

I agree with Preston, The approach to page loads and pre-formatted design is massively overlooked in today's design and construct. Everyone seems to have assumed that since the launch of cable, wireless, ADSL etc that all pages will just load instantly fast.

User monitoring and tracking personally is also what gives me most information when it comes to page refining and site design without relying on silly 3rd party tools.

Meanwhile all these pages are being gzipped for compression ratio's except the browser decompression time opposed to time saved in data transfer TO the browser is so minimal that sometimes it takes servers longer to generate content that it benefits the speed of the site server overall.

Those of you refining your pages or such I would seriously recommend looking into Firefoxs Firebug

http://getfirebug.com/

Use the speed tool to evaluate your pages content, speed and more while providing relevant information on improving your page load speeds.

Gustavo Muñoz [2009-06-24 09:54 AM]

there is no need of such evaluation to realize that, i think this people likes to loose time or maybe just want to justify their "job"

Prankster [2009-06-24 12:08 PM]

This page took forever to load.

naysh [2009-06-24 12:10 PM]

Well said Mike White.

Everybody hates slow pages.

Tantek [2009-06-24 05:34 PM]

Thanks for this summary Brady.

It's nice to see the anecdotal wisdom that a lot of us share confirmed by *two* independent data-heavy studies.

It's also nice to know that it's not just us fast-twitch video-game-trained MTV-generation-short-attention span folks that can't stand waiting fractions of a second, but rather, a measurable amount of web users in general.

I will be citing this summary in future design/development work and talks.

Anil Kishore [2009-06-24 11:56 PM]

Also, there should be focus on middle ware (in networking) , instead of just focusing on Server side and Browser side.

Vik Chaudhary [2009-07-01 01:09 PM]

Brad - awesome post. I attended the talk, and really liked your summary of it.

Preston - what is your web site? I am impressed that you needed to get your page response time (or was it click response time) down to 200 ms. I'd like to try it to see what this snappy performance feels like. Not too many sites that aim for this level of sub-second performance.

-Vik