|
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
poll - How many MS should it take to load a site's home page?
Looking forward to hearing everyone's thoughts.Nate Willard 01/20/08 03:43 A IIRC when Macromedia had launched their new website a few years agos. isaac dealey 01/20/08 05:07 A > I believe users are generally okay with waiting a little longerBobby Hartsfield 01/20/08 09:32 A > page?Jim Davis 01/20/08 12:17 P > Looking forward to hearing everyone's thoughts.Jim Davis 01/20/08 11:53 A Slightly different scenario, but back in the days of big iron (CICS andDave Francis 01/20/08 12:37 P > Slightly different scenario, but back in the days of big iron (CICS andTom Chiverton 01/21/08 05:23 A > page?Jim Davis 01/21/08 12:33 P 4 secondsJames Wolfe 01/21/08 03:10 P Seems like 4.2 seconds should have been the answer...Sonny Savage 01/21/08 03:31 P Normally I work to a rule of around 2 seconds perceived time beforeNeil Middleton 01/21/08 05:43 P Thanks for everyone's thoughts on around this topic. INate Willard 01/21/08 08:33 P > It's a pet peeve of mine (I'm not really talking about whatDave Watts 01/21/08 01:10 P > On the other hand, to be successful, your application simply has to be noTom Chiverton 01/22/08 04:41 A > page?Jim Davis 01/22/08 09:47 A >>Speed is important in the CONTEXT of that experience but isn't the SUMJerry Guido 01/22/08 10:13 A I kinda disagree on this.Neil Middleton 01/22/08 08:00 A > page?Jim Davis 01/22/08 09:49 A Looking forward to hearing everyone's thoughts. How many milliseconds should it take for a site's home page to load? IIRC when Macromedia had launched their new website a few years ago (Dylan I think they called it), they published a few articles that described web-wide averages as well as their own targets (the research they'd done during the planning phase). They hit their target of having pages load completely in under 15 seconds... as compared to a web-wide average of about 7 seconds. (Those numbers are from memory -- they may not be entirely accurate.) The overwhelming response from users was that although it was visually appealing, it seemed tragically slow (for what seemed to be relatively static pages anyway - I believe users are generally okay with waiting a little longer for pages that are returning data dynamically from a search for example). -- s. isaac dealey ^ new epoch isn't it time for a change? ph: 503.236.3691 http://onTap.riaforge.org/blog > I believe users are generally okay with waiting a little longer > for pages that are returning data dynamically from a search for > example Well, the kind of users who visited MM may be a good basis for that but the average user doesn't know or care that there is a database even involved. They just want what they came for and wouldn't wait much longer than 5,6,7 seconds for a page to load when there were plenty of google results for their search term. They would just hit back and click the next one. .:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com IIRC when Macromedia had launched their new website a few years ago (Dylan I think they called it), they published a few articles that described web-wide averages as well as their own targets (the research they'd done during the planning phase). They hit their target of having pages load completely in under 15 seconds... as compared to a web-wide average of about 7 seconds. (Those numbers are from memory -- they may not be entirely accurate.) The overwhelming response from users was that although it was visually appealing, it seemed tragically slow (for what seemed to be relatively static pages anyway - I believe users are generally okay with waiting a little longer for pages that are returning data dynamically from a search for example). -- s. isaac dealey ^ new epoch isn't it time for a change? ph: 503.236.3691 http://onTap.riaforge.org/blog ----- Excess quoted text cut - see Original Post for more ----- It's not so much that they're more willing to wait for databases (they don't know or care HOW the thing works). There are actually a few things that work here. People are always willing to wait longer for information specific to them. If they enter a search term they will wait for the results. This doesn't change user experience - they still notice the delays, lose focus, etc - but they are willing to wait because "the page" is working for them. I've never actually seen it studied (and I'm too lazy to do so) but I strongly believe there's a form of "queue affinity" going on. Queue Affinity is when people get into line, say at the grocery store or the bank - anyplace where there's multiple lines moving at different speeds. Once people make a decision to get into line there's a strong tendency to stay there even when they're faced with another line moving faster. They'll stay in the line past normal levels of task abandonment (the time it takes to drop a task in frustration). There's been some work correlating this to phone queues as well as technology decisions ("fanboyism", where an essentially arbitrary choice - a cell phone, game system, computer OS, etc) results in string emotions AGAINST the competition. Once people fall down that road they become more and willing to put up with the negatives of their chosen option. This is one of the main reasons that (I think) sites like Amazon.com and eBay.com - sites which have taken severe plunges in usability - are still so popular. Despite the fact that these sites are usability nightmares they still have rabidly loyal followers (I still buy more from Amazon than from anybody else). Jim Davis > Looking forward to hearing everyone's thoughts. > > How many milliseconds should it take for a site's home > page to load? The rule of thumb is: +) .1 seconds (100ms or less) is what people consider "instant response". They won't lose focus or notice any delay. +) Anything up to 1 second will allow most people to stay focused. They'll notice the delay but it won't interrupt or frustrate them - they still "move freely through the information space". +) Anything up to 10 seconds will let the user maintain attention on the task, but the delay will be frustrating and disconcerting. +) Anything greater and the person loses focus (wants to do other things). This is where you need to start considering progress bars, warnings, background downloads and other mitigating interfaces. These aren't specifically for web pages but for general computer transactions. Similar numbers result in nearly all interaction scenarios: industrial design, communication (notice, for example, how communication often breaks down on live satellite conversations when the delay grows larger than a second), etc. There aren't separate expectations for "web applications" vrs "applications" - we're talking about user experience and the delivery mechanism doesn't alter that. Also note that this isn't "ColdFusion time" or "Download time" or "Browser Rendering time" - this is EVERYTHING. Click-to-done. You can sometimes use the "click-to-useful" time (the time it takes for useful information to be displayed as when a browser is done displaying the requested information but not down downloading non-essential graphics) but that can get touchy and should be tested - depending on the page being unfinished can be very noticeable or barely noticeable. Jim Davis Slightly different scenario, but back in the days of big iron (CICS and 3270? terminals), IBM came up with a study that stated that anything over a 2sec response time "caused anxiety in the user". page? > Looking forward to hearing everyone's thoughts. > > How many milliseconds should it take for a site's home > page to load? The rule of thumb is: +) .1 seconds (100ms or less) is what people consider "instant response". They won't lose focus or notice any delay. +) Anything up to 1 second will allow most people to stay focused. They'll notice the delay but it won't interrupt or frustrate them - they still "move freely through the information space". +) Anything up to 10 seconds will let the user maintain attention on the task, but the delay will be frustrating and disconcerting. +) Anything greater and the person loses focus (wants to do other things). This is where you need to start considering progress bars, warnings, background downloads and other mitigating interfaces. These aren't specifically for web pages but for general computer transactions. Similar numbers result in nearly all interaction scenarios: industrial design, communication (notice, for example, how communication often breaks down on live satellite conversations when the delay grows larger than a second), etc. There aren't separate expectations for "web applications" vrs "applications" - we're talking about user experience and the delivery mechanism doesn't alter that. Also note that this isn't "ColdFusion time" or "Download time" or "Browser Rendering time" - this is EVERYTHING. Click-to-done. You can sometimes use the "click-to-useful" time (the time it takes for useful information to be displayed as when a browser is done displaying the requested information but not down downloading non-essential graphics) but that can get touchy and should be tested - depending on the page being unfinished can be very noticeable or barely noticeable. Jim Davis > Slightly different scenario, but back in the days of big iron (CICS and > 3270? terminals), IBM came up with a study that stated that anything over a > 2sec response time "caused anxiety in the user". Different era. Users are more used to waiting for things now, esp. over the internet. That said, sub-10 second is OK, but I would aim for sub-5. -- Tom Chiverton Helping to adaptively reinvent bleeding-edge products on: http://thefalken.livejournal.com **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ----- Excess quoted text cut - see Original Post for more ----- Not really... user expectations haven't really changed. "Anxiety" may be a strong word but it's still appropriate (I'd probably use "frustration"). It could be argued while the internet has created an expectation of delay faster computers have created an expectation of speed. It doesn't really matter tho' as users tend not to distinguish things that way. It's a pet peeve of mine (I'm not really talking about what you said) but developer's really have to stop assuming that people are as sophisticated as they are. More specifically (and less arrogantly) they have to stop assuming that people actually give a rat's ass about the stuff they do. ;^) People want things to work, work fast and work correctly - they don't care if it's web-based or not, uses a database or not, etc. People may sit down to a web application and intellectually think "this is going to be slow" but it doesn't alter their innate transactional timetable. People may EXPECT a satellite feed to be delayed, they KNOW it will be delayed. But they are still disconcerted and frustrated by the delay nonetheless. These numbers aren't what people are willing to put up with - they describe the results of waiting for response, generally. Even if a person KNOWS that this web application will be slower they will still lose focus and attention. It's just the way we're wired - regardless of how fast our technology happens to be. Jim Davis This is a great thread with very interesting inputs and I want to thank everyone for that. Here's my take (not research result but more on 'gut' instinct), different demographics may have a slightly different tolerant level for page loading speed. The younger could be less tolerant of speed while the older just the opposite... (on the other hand, generalization always has its limitation too...) It would be interesting to find some study/research result on eBay finding of this idea... >Looking forward to hearing everyone's thoughts. > >How many milliseconds should it take for a site's home >page to load? 4 seconds http://news.bbc.co.uk/1/hi/technology/6131668.stm >Looking forward to hearing everyone's thoughts. > >How many milliseconds should it take for a site's home >page to load? Seems like 4.2 seconds should have been the answer... On Jan 21, 2008 2:58 PM, James Wolfe <james-cftalk@goqs.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- Normally I work to a rule of around 2 seconds perceived time before stuff starts appearing on the page with everything else appearing in the next two. The thing with page loads aren't anything to do with ms duration in CF, but the perception by the user. The user does give a t*ss what the server, code, or anything else are doing to achieve that. That said, if you can't manage 4-5 seconds, distract the user with something else (ASCII Porn?). Neil On 20 Jan 2008, at 08:34, Nate Willard wrote: > Looking forward to hearing everyone's thoughts. > > How many milliseconds should it take for a site's home > page to load? Thanks for everyone's thoughts on around this topic. I enjoyed reading your comments. Incase anyone's interested I highly recommend Yahoo!'s yslow: http://developer.yahoo.com/yslow/ its a great tool for performance issues around this topic. Right now my goal is to always have the site I'm building be under 3 seconds loading, 200ms processing. --- Neil Middleton <neil.middleton@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- ----- Excess quoted text cut - see Original Post for more ----- On the other hand, to be successful, your application simply has to be no slower than your competitors' while providing the same level of functionality and reliability. As a result, the answer to the original question - how many MS should it take to load a site's home page - is a business question, not a technical question. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! > On the other hand, to be successful, your application simply has to be no > slower than your competitors' while providing the same level of > functionality and reliability. That's a very interesting take on it, cool. -- Tom Chiverton Helping to centrally reinvent innovative systems on: http://thefalken.livejournal.com **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. > page? ----- Excess quoted text cut - see Original Post for more ----- Speed is very important but experience is moreso. People are definitely willing to invest more (time, money, whatever) for even a perceived gain (In quality, status, whatever). The classic example is Starbucks where (at least for a regular cup of coffee) you pay more and wait more for a cup of coffee that's doesn't test as better than many quickserv chains. It's the experience that keeps them. Speed is important in the CONTEXT of that experience but isn't the SUM of it. Usability is a huge, almost completely overlooked (by most organizations) part of that: people will pay more, suffer lag and accept fewer features to work with a highly usable system. Jim Davis >>Speed is important in the CONTEXT of that experience but isn't the SUM of >>it. Usability is a huge, almost completely overlooked (by most >>organizations) part of that: people will pay more, suffer lag and accept >>fewer features to work with a highly usable system. I am willing to wait quite a bit of time for Gmail to load a good 5- 10 seconds on a fat pipe. Sometimes longer when FF gets sluggish. But after the initial load time it is pretty snappy. But them again I am checking my email and Gmail loads a lot faster than Outlook so I am willing to wait. So it is relative to the perceived value of the content relative to the "competition". Jerry Guido Programmer MGT of America, Inc. jguido@mgtamer.com The information contained in this electronic communication is intended only for the use of the addressee, and may be a confidential communication. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited. page? ----- Excess quoted text cut - see Original Post for more ----- Speed is very important but experience is moreso. People are definitely willing to invest more (time, money, whatever) for even a perceived gain (In quality, status, whatever). The classic example is Starbucks where (at least for a regular cup of coffee) you pay more and wait more for a cup of coffee that's doesn't test as better than many quickserv chains. It's the experience that keeps them. Speed is important in the CONTEXT of that experience but isn't the SUM of it. Usability is a huge, almost completely overlooked (by most organizations) part of that: people will pay more, suffer lag and accept fewer features to work with a highly usable system. Jim Davis I kinda disagree on this. For me, you only need to look at performance overall if you are slower than your competitors, but that first hit should always be nice and snappy. Once the user is looking at your site, they are less likely to run off on the first slow page hit. Neil On Jan 21, 2008 6:12 PM, Dave Watts <dwatts@figleaf.com> wrote: > On the other hand, to be successful, your application simply has to be no > slower than your competitors' while providing the same level of > functionality and reliability. As a result, the answer to the original > question - how many MS should it take to load a site's home page - is a > business question, not a technical question. ----- Excess quoted text cut - see Original Post for more ----- Exactly true - it's part of that queue affinity I was talking about. Until you get people "in the line" they've no loyalty to their choice. Once they choose a line their loyalty for it increases the longer they stay even in the face of obvious negatives. That's all a long way of saying "ya gotta get 'em through the front door!" ;^) Jim Davis I agree with the 1 to 2 seconds on Broadband. I allow 10 seconds on my phone. Its all to do with how long you think it *should* take. I just though I would share with everyone a really interesting page on the android website. http://code.google.com/android/toolbox/philosophy.html . It talks about fast, efficient, and seamless code. I think its well worth a read. Cheers, Joel
|
Mailing Lists
|
Latest Fusion Authority Articles
|
||||||