Slashdot Log In
4 Seconds Loading Time Is Maximum For Websurfers
Posted by
CmdrTaco
on Wed Nov 08, 2006 09:21 AM
from the longer-than-i-wait dept.
from the longer-than-i-wait dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
tabs (Score:5, Interesting)
Re:tabs (Score:5, Insightful)
Parent
Re: (Score:2)
Re:tabs (Score:4, Insightful)
Parent
Re: (Score:2)
Re: (Score:2)
Re:tabs (Score:4, Insightful)
Here in the UK slashdot is near instantaneous over 24 Megabit ADSL. 2 Megabit ADSL accounts are given away for free in the UK now with most phone connections. The slowest account people actually pay money for is 8 Megabit ADSL.
As for all the people saying they still use dialup, why? Here you can get better net connections than 56kbit using a mobile phone (3G - UMTS).
To me the idea of waiting 4 seconds for a page to load is monsterous, expecially if the next page I clicked took just as long even though half the images were already cached.
Parent
Re: (Score:3, Interesting)
What?! What?!!!! If you're referring to the offers from people like Carphone Warehouse, it's far from free. Virtually everyone is still paying for their ADSL. And I'm paying for mine, which is currently running at 512K, because thats all the line supports. 8Mbit/s is just a dream unti
Run a squid proxy and cacheing nameserver (Score:3, Interesting)
Re:tabs (Score:4, Informative)
because internet service in my area is practically a monopoly. the phone company refuses to run DSL-capable line the 3000 ft from the highway into the village and install the nessesary hardware. they're making buckets of cash off of raping us for our dial up ($60 a month for 180 hours/month of net time, plus the "unlimited long distance" required to be able to get that 180/month plan), not to mention the overage charges they pull if you go over the 180/month, wheras you can get the cheapie 1.5mbps DSL for $15/month in town.
the only other options in the area are wireless high speed (similar to Wi-max), but for that you need to buy the antenna and gear upfront ($250) and satalite internet, with is not an option as a. our satalite provider doesn't do internet and b. it would be useless in any case due to the lag from satalite (stupid laws of physics).
Parent
Re:tabs (Score:4, Interesting)
Slashdot does not use AJAX, just some Javascript, for the new discussion system. In essence, the only thing it does is hide all posts until you click on its header to expand it. The posts are there anyway, loaded along with the rest of the page. That way, it uses about the bandwith of the nested option, while presenting it as a dynamic threaded view. If they used AJAX, it would (probably) send an asynchronous query to the Slashdot servers asking for precisely the post you try to open. That does not happen, I checked tcpdump myself.
Had they really used AJAX, a comment thread might have been a lot quicker to load initially, but slightly slower loading each post.
Parent
Re:AJAX completely lacks performance. (Score:5, Insightful)
This is a nonsensical thing to say. It all depends on what you are doing. Ajax can significantly increase performance too. Remember when GMail was first launched? The #1 thing everybody said was that it was fast. Why? Because it used Ajax.
Without mentioning what those systems were using Ajax for, there is zero useful information there. It's certainly possible that Ajax decreased performance in these cases, there's plenty of people throwing Ajax at things where it just isn't useful just because it's the buzzword du jour. On the other hand, there's also plenty of people using it as just another tool, and getting decent performance and usability improvements out of it.
In short: "Ajax completely lacks performance" == stupid. "Ajax harms performance when used to do [x], [y] or [z]" == useful information.
Parent
Re:AJAX completely lacks performance. (Score:4, Interesting)
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.
Parent
Re: (Score:3, Funny)
Friends, I would like you to meet the newest Slashdot troll. The "AJAX performance is terrible!" troll.
Unless, of course, you'd like to actually provide a few examples of these "AJAX-based Webforums" that suck so much?
What the fuck are you talking about? (Score:3, Informative)
From the Wikipedia page about XMLHttpRequest [wikipedia.org]:
Re: (Score:3, Informative)
new ActiveXObject("Microsoft.XMLHTTP");
Well.. (Score:3, Funny)
Re: Amazon.Com clearned this along time ago. (Score:3, Interesting)
Re: (Score:3, Informative)
Doesn't sound like the Amazon and Ebay sites I visit on my 56K modem.
I ran a little test using Safari's show page test load window [webkit.org] option from the debug menu, results below.
Who is conducting that study? (Score:5, Interesting)
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.
Re: (Score:2)
Re:Who is conducting that study? (Score:4, Interesting)
I get frustrated by a delay of even 1s.
Parent
Re: (Score:2)
Re: (Score:2, Interesting)
Exactly. I remember that the figure used to be 10s back in the days of dialup, but now that connections are faster we are getting more and more impatient.
What really annoys me are sites where the main text of the page seems to load last. Everything else, like image intensive navigation strips, logo headers, ads (if Camino's ad blocker hasn't caught them) etc. seems to slowly load first and then it's a couple of seconds before the main text appears.
Re:Who is conducting that study? (Score:4, Funny)
Parent
Re: (Score:3, Insightful)
Agreed, also, I would say the old humorous adage of...
I'd also think that this is more FUD, since of course people are going to say "I'll never return to that website because once it never loaded for me". Of course, if said website was Amazon.com, I'm going to go all in and say that they will most likely return and that they where just unhappy at the time.
Also, what where the survey questions? Where
Great (Score:5, Funny)
Bullshit (Score:3, Funny)
Only four seconds? (Score:3, Interesting)
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.
Re: (Score:2)
I think it's experience, not impatience that leads to this behavior. If you get nothing for 4 seconds after trying to open a site, aren't the odds of it working right today going down with each additional second? If nothing has happened after 4 seconds, will 5 help, or 500? At that point, you start to assume the tubes are clogged at the other end.
If a person is shopping or reading the news, long waits between each action can be very irrit
I call bullshit (Score:5, Interesting)
Either the summary is totally off, or this 'research' is total bunk.
Re:I call bullshit (Score:5, Interesting)
I think it all comes down to what the site is doing, and how readily available another, virtually identical site (or range of merchandise, at similar prices, etc) actually is. The more sites there are that present and transact the same things in essentially the same way, the more that things like raw speed differentiate one from another. The more unique something is (niche merchandise, a blog with a particular perspective), the more patience people will have. Those things are nearly impossible to quantify, and thus you get largely BS, context-less reports like the one being discussed. I think that the larger conclusion ("people are less patient than they used to be") is valid - but pretty hard to nail down, in terms of specific seconds, for specific demographics, on particular platforms, across particular pipes, under certain seasonal circumstances, blah blah blah.
Parent
This old bag? (Score:2)
People are still spending money on stuff like this?
Here's a question: is gmail.com the same as brochureware.com? Would a user visiting a web(2.0)-based application have the same load time expectations as visiting an about page of a company's website?
Of course the answer is no. People with half a brain start to sound like a broken record here when they say "This has no value. It all depends on the site's audience, not a general audience.", but that's because the people behind studies like this never listen
Akamai provides content acceleration services (Score:2, Interesting)
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 [dallaway.com]
This survey was sponsored by... (Score:5, Informative)
Disturbing... (Score:4, Insightful)
Poor Layout (Score:5, Insightful)
But for me the ability to sort through goods is the #1 priority. Yes I like to have a pretty site to look at but if I cannot find what I am looking for with a few simple queries then I am gone. Newegg is a fine example of a site where I can find what I want quickly. Tigerdirect is getting better. Dell is the worst. I have a theory that Dell is like many supermarkets, they rearrange stuff and make searching difficult so you see the maximum number of items before finding what you are actually looking for.
Web designers, if you want business, make it easy. I dont really think most people go to sites just to browse. Most of the time we are there with a purpose and as an ADD generation we want it quickly or we will move on.
It can't be that simple. (Score:3, Insightful)
Now, whether Akamai is being disingenuous or something else... I really couldn't imagine
Flash? No thanks. (Score:4, Insightful)
FlashBlock (Score:5, Informative)
https://addons.mozilla.org/firefox/433/ [mozilla.org]
If you can't stand flash, then its for you.
Parent
Why I leave.. (Score:5, Interesting)
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).
Ignores Parallel Processing (Score:2, Insightful)
off-topic on "akamai" (Score:2, Interesting)
Any web developers who didn't already know this (Score:2, Insightful)
I must be part of that statistic (Score:3, Funny)
Speaking of which.... (Score:3, Interesting)
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.
No. It's registration (Score:4, Insightful)
Not developers (Score:5, Insightful)
Developers already know this. But at the end of the day, we're paid to implement the ill-considered plans of marketers and designers.
Depends entirely on what... (Score:3, Insightful)
In short, measuring cost (time) without measuring benefit (content) is meaningless. If google's search page took four seconds to load, they'd be a dead duck. Other pages couldn't be rendered in four seconds with a Core 2 Quad and GigE, but are still highly successful. The pages you want to check is where the user asked you for something specific, in which case you'd better deliver ASAP without crapping up the page with everything he didn't ask for. Pages that are slow, I can live with. Pages that are slow, deliver little and waste time on meaningless stuff I don't.
Notice who sponsors the study (Score:3, Interesting)
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.