I heard Google also found that increasing speed increased users' perception of the quality of the search results. The reason was that when the site was faster, users did more searches. Naturally they found more stuff. But they attributed the gain to Google's cleverness rather than the extra work they'd done themselves.
I have spoken to tons of folks on websites they think are fast, websites they would benchmark against -- in the majority of cases perception of fast loading website triumphs an apples-to-apples comparison of time taken to download & render a page. Perception plays a huge role when it comes to wining the mind games in the users head regd. page download times.
Here's an example which made me quite a bit of money. My website basically looks like this:
AAAAAA
CBBBBB
CBBBBB
CBBBBB
CDDDDD
CDDDDD
CDDDDD
CDDDDD
Most users will have their screen break a bit above the end of the B block. (By design.)
The heaviest part of the page is D. Eliminating it is not an attractive option -- the overall conversion rate suffers. The most valuable parts of the conversion pathway are in B and C. The first thing the customer sees is invariably A.
Solution: a bit of technical magic to make sure that the website loads element in A->C->B->D order (there is a competing technical imperative which means that in the HTML it makes more sense to order them A->B->D->C), and significant microoptimization of how quickly B and C are minimally interactive to the user. (We're talking measuring improvements in the kilobytes or tens of microseconds range.) Since customers have to actively scroll down to engage the D block, and since most do not engage the D block before first engaging the B block, the fact that D is heavy and slow very rarely impacts their experience.
Oh yes, we've made extensive use of Souders' work. But I was asking about something different: what things (besides progress bars and loading animations) have the psychological effect of making software feel faster?
One of the key things I've found works for us is differentiating what we WANT to have from users vs. what we NEED to have.
We used to have a webform that (in summary) asked the user what they wanted to download, how they got there, and how we can contact them later (as sales leads). Conversion ratio was fairly poor, so I refactored the priorities of what we were asking for into 2 forms.
The first form consisted of questions we HAD to know the answer to to service the user's request, and the second form consisted of info we wanted from them (name, email, contact info, etc.)
So between the first form and the second form, we'd kick off the download for the user (and show a progress meter at the top) -- which got them what they needed immediately, making the site seem faster overall.
Plus, since they were waiting for the download to complete anyway, the conversion goals for the information we wanted went way, way up as well.
Again, I didn't actually MAKE things faster, in fact, having to fill out 2 forms was significantly slower, but we kept users engaged and let them waste their idle cycles making us happy since we were already accomodating their request.
Loading animations make people perceive it as fast loading?
It has exactly the opposite effect on me; If someone site has to show me loading animation,it's not fast enough. I'm thankful for the animations though in situations where delay can't be avoided.
That article also links to a great article called "Maximizing Human Performance" (http://www.asktog.com/basics/03Performance.html) which goes over a few topics, including response times and their perceived meaning and optimizing user flows for the human thinking process.
We use the Google Web Toolkit to defer loading large pieces of data that compose slots around the page. The result, which you could achieve with any asynchronous mechanism, is that the page is up fast, and then details pop in as they're ready. If we waited to retrieve all of the data and render the HTML on our server, pages that currently start presenting on the browser in one second or less would take 4 or more seconds. Basically, if it's below the fold for most of our users, we defer loading it.
If I understood prakash's comment, the first way is actually making it faster, either by generating it faster or by caching. I usually launch four or fives sites at once. HN is the first to load, so I usually start browsing it instead of the (slower) others.
Known tricks are explicit sizes for tables and images. The HTML file itself is loaded fast so you can start reading while images are loading.
There's also the opposite method: preloading images so, once the needed items are in the browser, the page renders faster.
I wonder how it would work to preload the images for the initially visible part of a page and leave for later the ones that you must scroll to see.
I've read recently about using sprites for the graphics: one big image with a mosaic of little images used, then split using CSS. This trick reduces the number of HTTP requests.
You could separate it into 2 segments. One portion of users not having used a website in a particular category and the other bucket being folks that had used such websites before. Let's take online travel websites as an example.
In both cases people had a good experience using the website which in turn was a combination of great design including crispness & information architecture, variable font sizes, great presentation of the most important information, a lot of user empathy, generally not making the user think and not surprising the user, heat maps of which areas of a webpage users are likely to look at, etc.
The technical aspects of it included, smaller webpage sizes, tons of caching by abstracting away personalized portions of the webpage, and thereby caching close to 70-95% of the webpage in the browser, using a CDN, compression, reducing RTT, using distributed dns, not accessing the database for requests if possible, having as many static components as possible, use of persistent connections, caching url query strings, and all the things mentioned in Y! performance guidelines.
For folks that had never used an online travel website, they compared the speed of a website to the ones they regularly used like google, rediff, yahoo, etc. For folks that had used an online travel website, the comparison was with the competition and how much better you were with the above aspects.
Things that make me think a site is too slow are staring at a blank screen while waiting for doubleclick and trying to find the skip button for an intro ad. A site should display its content first and then fill in the ads later. Engage your users while all the clutter catches up.
There may be a psychological effect too. I've noticed that once people think of a piece of software as fast, they're more likely to think of it as good in other respects, even unrelated ones.
