4 Seconds Loading Time Is Maximum For Websurfers
nieske writes "Of course we all want webpages to load as fast as possible, but now research has finally shown it: four seconds loading time is the maximum threshold for websurfers. Akamai and JupiterResearch have conducted a study among 1,000 online shoppers and have found, among other results, that one third of respondents have, at one point, left a shopping website because of the overall 'poor experience.' 75% of them do not intend ever to come back to this website again. Online shopper loyalty also increases as loading time of webpages decreases. Will this study finally show developers of shopping websites the importance of the performance of their websites?"
It takes a lot longer than 4 seconds for a Slashdot story to load, particularly with the new AJAXy discussion system. I usually open up several things at a time in different tabs, which decreases the average loading time since I can read one thing while another loads. What browser were these people using?
Note that Akamai has a vested interest in this study. They would like to encourage more businesses to use their technology so that their sites load faster.
I am not saying that the study is biased, but one should at least consider that it is in Akamai's best interest to convince every site owner that they will lose customers if their site is not fast enough.
Amazon still codes their pages so they come up "fast" on a 28.8 modem. Ebay is the same. Where as some sites are sold by flashy experiances, they are not. They want to keep the barrier of entry low so you buy from them, and the whole process is fast and easy. To do otherwise is simply bad business.
Sounds to me like people are getting really impatient these days. I'm willing to wait up to 10 seconds to let a page load, and if it still hasn't, but is busy (instead of connecting again) I load another tab and occupy myself with something else.
However, four seconds sounds accurate for how long to wait until the page -starts- to load. If I have to wait longer than 4 seconds just to connect to a web server, I start to get impatient. If it takes much longer, I'll come back to it later and go do something else.
Either the summary is totally off, or this 'research' is total bunk.
Method of processing duck feet
Of course Akamai is going to say that... they're business model revolves around bringing data closer to web surfers in order to speed up busy sites.
That's kind of like two years ago (or so) when RedHat released a whitepaper saying linux has a lower TCO while simultaneously Microsoft released a whitepaper saying windows server has a lower TCO.
The only difference is, there's no one out there selling a service or product that slows down website access to provide a contrasting viewpoint. Well, none except maybe these guys.
Wow, a web caching company has determined that customers abandon a site that is slow.
That is not an issue for me. My highest chance of leaving is determined by when in the buying process, the site provides total price including all shipping, handling, taxes, and acceptance of coupons codes. If they need my name and address I may leave depending on if they have a shipping link or general shipping info somewhere on the site that I can reference first. I will ALWAYS leave if they require CC or payment information before providing the total price or even a hint of shipping costs.
I guess they need my address prior to calculating shipping and handling charges if they do not have flat rates but a place to enter my just my zip code should be enough IMHO.
For a good example of providing a good experience is NewEgg. They includes the shipping costs right next to the product descriptions without even having to go to a cart first.
I view the delay or confusion of shipping and handling charges to be an attempt to hide a total cost or get you to get so far that they figure you will not back out. I will back out and take my business elesewhere.
Almost like the the Ebay sellers that charge $20 to ship a motherboard (at least they are up front about it though).
Bad boys rape our young girls but Violet gives willingly.
This is totally off-topic here, but it's a small little detail anyway: Did you know that "akamai" is the hawaii. word for intelligent, clever?
Stats for http://slashdot.org/ -
Request Count: 78
Bytes Sent: 50.871
Bytes Received: 436.121
RESPONSE CODES
--------------
HTTP/200: 78
RESPONSE BYTES (by Content-Type)
--------------
application/x-javascript: 288.162
application/x-shockwave-flash: 22.517
text/html: 17.348
image/png: 11.410
~headers: 21.942
text/css: 37.599
text/javascript: 9.026
image/gif: 28.117
That certainly takes longer than 4 seconds.
throw new NoSignatureException();
This is the best argument for getting old web application and ajax-ize them, reducing load time and getting a better user experience.
-- Giovanni Daitan Giorgi http://gioorgi.com http://www.siforge.org
Somewhere on your home LAN. Your web page latency will reduce substantially.
Deleted
It's pretty easy:
If you're application uses a lot of repeated screens and is really only a data-view and entry application, you should go AJAX. Because the slightly longer initial load time (to load ALL the interfacey stuff) is better than having to rerender the interface over HTML every time you change views.
If it's a step by step wizard type thing, or informational (think wikipedia) just get on with it using syncronous web pages.
Where AJAX fails is in the hands of inexperienced developers, where they won't allow the app to load almost everything before running. This is not always possible--something like google maps is a good example of this. You are going to have to load the maps as you go because there's too much data. However, google maps really relies on Images as data which is not the most efficient. They need to expand their client to render the maps itself from GIS info (obviously the satellite overlay will need to come from images).
Also, it fails when there is a high latency connection. However, a lot can be learned from past interfaces: feedback! Flash a div on the screen letting the user know it's loading, apply visibility:hidden when it's done. As long as the user knows that it's actually DOING SOMETHING and not just sitting there, they will give it the benefit of the doubt and wait. Test the connection latency at startup and then let the user know what you know. If you tell them in advance that they might experience poor performance because of their current connection, they are more likely to tolerate it.
Good interface design is a lot more than having it be fast. You have to keep the user informed of the current situation. It's not slowness that annoys people so much as not knowing what's going on. Early X windows had that problem for me also. Whereas in Windows when you click something the window immediately is created by GDI while the actual application loads, in X the appliation is started somewhere and then IT creates it's own window. So when you click on an Icon, it takes a few seconds of nothing (it seems) while we wait for the kernel to find on FS, allocate memory for and run the executable which does it's own init and then FINALLY pops up it's window. If you're running over a network connection, there's no disk noise to let you know anything is happening, so you are basically just sitting there wondering if you should click again. I don't know if it's still like this.
Anyway, my point is that there are a lot of tricks you can use to prevent user annoyance because it goes a lot further than some arbitrary time length.
Cool! Amazing Toys.
Not to argue that nothing on the web should take more than 4 seconds to load (on _second_ load), but notice who sponsored the study - Akamai. It's like if Microsoft sponsored a study "proving" that Linux sucks.
Caching is your friend. If you cache, don't forget to version your stuff as well:
<script src="foo.js?d=md5sum-of-the-script"></script>
And do this with everything you cache - css, xml, xsl, whatever.