

Faster sites mean users do more stuff - herdrick
http://www.drunkenfist.com/304/2008/12/29/why-front-end-performance-matters-to-everyone/

======
nickb
I remember a study, can't find it at the moment since I'm on the phone, that
showed that slower sites have much higher engagement than fast loading sites.
Fast loading sites also have a larger bounce rates than slower loading sites.
I have no idea why that is but the data was conclusive. So maybe fast loading
sites are great for transactions (shopping etc) where the speed is important
but maybe not so when you're loading someone's profile. My best guess is that
by waiting, people are investing time into a page and they want to check it
before they hit that back button. (ping me if you want the source and I'll dig
it out).

~~~
bd
This can be another facet of the "uncanny valley" of web applications [1].

When you are in the "web" mode, you operate asynchronously - click, do
something unrelated, return to see the result.

When you are in the "desktop" mode, you expect instant reactions. If it's just
a tiny bit slower, you feel something is broken [2].

Now as you make your site more ajaxy and faster, user expectations change,
instead of perceiving fast website, they perceive slow desktop application.

[1] [http://billhiggins.us/weblog/2007/05/17/the-uncanny-
valley-o...](http://billhiggins.us/weblog/2007/05/17/the-uncanny-valley-of-
user-interface-design/)

[2] <http://www.useit.com/papers/responsetime.html>

------
teej
I don't have the exact numbers on hand, but the game I worked on saw a similar
10-20% increase in daily pageviews as an immediate result of making the site
faster. I would optimize a few core pages or add more capacity and, like
magic, traffic would jump the next day.

------
Timothee
Interesting. And it comes after I realized how slow Salesforce was (for my dev
account at least).

What would be the things to work on to increase the performance? The article
mentions mostly the size of the files. I also understand that the lower the
number of different files is, the better. What else should be taken into
account on the front-end? For example, if I were to use jQuery only for a
couple of things, would it be better to have a bigger but simpler JS file? (as
in: I rewrite what I need myself but can't match the file size)

~~~
delano
Front-end performance is a compound problem. You need to consider everything
that sits between your customers and your data because it all has an impact on
the actual and perceived performance.

In regards to browser rendering performance, YSlow is a good place to start:
<http://developer.yahoo.com/yslow/help/.> The 13 performance rules is a
succinct and accurate list of things to look out for.

Steve Souders (creator of YSlow, but now works at Google) does a lot of great
work in this area:

<http://stevesouders.com/cuzillion/>

<http://stevesouders.com/ua/report.php>

[http://stevesouders.com/blog/2008/09/30/hammerhead-moving-
pe...](http://stevesouders.com/blog/2008/09/30/hammerhead-moving-performance-
testing-upstream)

Some more good stuff:

[http://www.websiteoptimization.com/speed/tweak/average-
web-p...](http://www.websiteoptimization.com/speed/tweak/average-web-page/)

<http://wtr.rubyforge.org/>

<http://seleniumhq.org/>

<http://sahi.co.in/w/>

------
rantfoil
The quote about the 30 results sounds tenuous at best.

Did the user search 20% less often because of an imperceptible page load time,
or because they became overwhelmed with the number of search results and
decided to quit?

User experience drives more activity than performance. Perf is important, but
that particular example sounds totally bogus to me.

