I remember switching my homepage from AltaVista to Google back in 2000 for one simple reason: it was blazingly fast. It's the same reason I don't use personalized Google, or Google suggest as my homepage: they're simply too slow.
Dare Obasanjo* wonders if AJAX apps are rolling page load speeds back six years:
One big problem with the AJAX craze that has hit the Web is how much slower websites have become now that using Flash and DHTML to add "richness" to Web applications is becoming more commonplace. My mind now boggles at the fact that I now see loading pages that last several seconds when visiting Web sites more and more these days.
Dare uses Yahoo! Mail as an example, but I've experienced similarly long load times for the new Hotmail beta, too. The load times can be so long that a combination disclaimer/escape hatch appears below the loading animation:
Maybe I'm just impatient. However, there's a lot of concrete data to support the theory that unless you make it load fast, nobody will stick around long enough to find out what you have to offer. For instance, a recent study found that most shoppers will only wait four seconds for a page to load before abandoning the site entirely.
Dare also cited this post by Greg Linden which provides more quantitative data on page load times from Google and Amazon:
Google VP Marissa Mayer just spoke at the Web 2.0 Conference and offered tidbits on what Google has learned about speed, the user experience, and user satisfaction.Marissa started with a story about a user test they did. They asked a group of Google searchers how many search results they wanted to see. Users asked for more, more than the ten results Google normally shows. More is more, they said. So Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%.
Ouch. Why? Why, when users had asked for this, did they seem to hate it?
After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds. Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.
This conclusion may be surprising -- people notice a half second delay? -- but we had a similar experience at Amazon.com. In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.
And let's not forget the classic reference on application responsiveness: Response Time in Man-Computer Conversation Transactions, written way back in 1968 by R.B. Miller. I know it primarily through Jakob Neilsen's Response Times: The Three Important Limits.
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
The 10 second number seems too high for today's world of ubiquitous broadband and quad-core CPUs. That level of delay should be increasingly rare. I'd argue the user attention threshold is now more like 5 seconds. If your application is going to spend more than 5 seconds doing something, you owe your users an estimate of when you'll be done, and real-time feedback on your progress. A basic hourglass doesn't cut it.
What's more important? Getting flash after 5 seconds, or functional no-frills layouts in less than a second? Let's get our priorities straight. Speed still matters. And remember, the perception of speed is just as important as actual speed. If you can't be fast, be clever. Exploit progressive rendering and HTTP compression.
* It's ironic, then, that Dare's blog is so incredibly slow to load every time I've directly visited it. One benefit of RSS aggregators, I suppose, is that I rarely need to.
Is, uh, how to put it... "graceful expansion" possible? As a counterpoint to graceful degradation, how about the possibility of loading a small page in to the browser for immediate display and then using javascript to pull in the heavier content and add it to the layout as it becomes available?
I'm envisioning either a responsive-yet-rich Web2.0-ey application here, or perhaps just a giant pile of steaming segfault and CPU cycle wastage.
I'd question that Google homepage takes too long to load. While you say that AJAX is increasing the time taken to load pages, I find that the vital components of personalised Google home are loaded as fast as any site, and I have quite a number of different components on there.
I would argue that well-planned use of AJAX could decrease page load times - as in the case of Google personalised home - since you can have the important parts loaded (i.e. the google search form) in no time, and let the rest of the content load itself in the background as the information becomes available.
Perhaps, too, the users who were presented with 30 results on a single page were simply overwhelmed by the sheer volume of results presented to them.
Maybe I'm just wierd, but if I go to Amazon to look for a book, dvd, or cd I'm going to buy it, regardless of how long it takes the page to load.
Greg Poole on November 10, 2006 5:11 PM>Maybe I'm just wierd, but if I go to Amazon to look for a book, dvd, or cd I'm going to buy it, regardless of how long it takes the page to load.
What if it was an impulse buy?
Dare Obasanjo on November 10, 2006 5:41 PMhere's the inconvenient truth (due to Al Gore, natch): widespread broadband, or any cash and energy hungry tech, is a myth. energy prices are rising rapidly, incomes (as measured by the median) are falling and have been every year since 2000 (overall longer than that, but with some respite years).
I expect, over the next few years, that dial up will rise from the dead. and sites that are parsimonious of bandwidth will win. after all, it's just internet. pandering to a minority only works for so long. ask Bush.
this course of events is not without precedent. HD TV was supposed to be everywhere by now. the networks were smart/crafty enough to get an escape clause in the law: if usage didn't rise to some percentage of sets (I don't recall the number, but recall that it wasn't all that high) by some date, they didn't have to implement HD.
IIRC, the date has passed (or nearly) and we're no where near the penetration figure.
I couldn't agree more with hating slow websites.
The only reason I'll use a slower website is when it has all of the best features, but the second a faster website comes along that offers all of the same things, I'll switch... and that's just for the websites I need to use often.
If I'm shopping around for something, I will always leave a slow website.
I also use plain google.com as my homepage.
My favorite site: http://local.live.com
My least favorite example of AJAX: http://local.live.com
I cannot stand the fact that the page layout changes as pieces are loaded. Especially since the first thing I do is try to close the Welcome panel on the left side of the screen, but the click is cached until the toolbar loads. Instead of having a useable, beautiful map, I'm taken to Live QnA.
Tip: if you're going to take forever to load, at least let me interact with the stuff that's there!
GoodOldDays on November 10, 2006 9:57 PMLet's face it as we move away from software installed directly on the PC and more feature rich web applications it is going to take a bit more time to load. Outlook does load in less then 1 second, but once it is up, it's up. Web applications tend to have to send massive amounts of markup language back and forth, which until we are all running on fiber networks and have faster PCs is going to be a problem. But does the hardware drive the software, or does the software drive the hardware?
Tim on November 11, 2006 1:02 AMSpeed depends on the connection speed, too. Have they considered, that if they were not testing with the slowest possible connection type, then half a second is more than that for some people? Then there is only limited amount of time. If the speed is reduced, the customers do not have as much time to browse before they are going to eg. for a dinner.
But as more and more people are having faster connections, some sites are starting to put up more and more content. Like Music Television site, it has ads, pictures and lots of stuff around. But then again, MTV is a multimedia channel by nature, anyway. If you want multimedia over the web, you need a fast connection. Decision makers are noticing this trend for multimedia and are lobbying faster connections, which should take care of the problem, if implemented. Computers and connections get faster as technology gets better.
Don on November 11, 2006 3:12 AMI have a huge assortment of widgets and information on my google personalised home - a page which I use purely for the bookmarks, TODO list, news aggregation, etc. It stays open in a firefox tab because it's a useful information collector.
It's silly to actually *load* a google page just to do a search. In firefox it's Ctrl-T, Ctrl-K, type your search query and hit enter. Much quicker. The size or speed of one's homepage is a moot point.
Back to the point though, the less responsive any interface is, the more frustrating it is to use. Take, for example, the failed Nokia 7710 - http://google.co.uk/search?q=nokia+7710+slow
Gorgeous screen, and the stylus input works quite well, but when it takes seconds and even minutes to perform some tasks, you'll soon be restraining the urge to throw it through the window. Nokia's current N series phones are also guilty of this to a lesser degree, leaving you feeling that the interface is flimsy and half-baked. Much the same with websites :)
Mark Webster on November 11, 2006 3:47 AMThis is the main reason that I stick with regular Yahoo Mail and avoid the newer Yahoo Mail Beta like the plague, despite Yahoo's urges for me to migrate.
The beta version uses AJAX in a way that make startup times unacceptable. If you find this annoying as well, make sure to tell Yahoo in their feedback forms!
One of the paramount rules of web site design, don't make the user wait. Like Steve Krug says in "Don't Make Me Think," keep the home page simple. Of course he's referring primarily to confusing content, but he also mentions speed as a big reason.
By the way, I completely agree about Dare's site...suuuuuuuuper slooooooooow. Like Great-Grandma slow.
tod hilton on November 11, 2006 9:57 AMOn Amazon's site -- I habitually, when I see an Amazon link, go through a thought of "is looking at this page worth 10-15 seconds of everything else I'm doing on the net being painfully slow?" Sometimes it is. A lot of times it isn't.
Yes, I use dialup. People in Silicon Valley and similar places tend to forget that a lot of people live in places where broadband simply doesn't go, or just don't consider it worth the cost. (Both my mom and my mother-in-law have sufficiently low-grade phone service that a phone modem won't even get anything above 28.8, and they're each only about ten minutes from the nearest town! I'm in the "not worth the cost" camp.) These dialup users are potential customers.
I'd been noticing more and more slowdown in page rendering/presentation from sites I've long visited (for example, slashdot). In Firefox, I not infrequently would notice a suspiciously market-y URL in the status bar during these delays.
For an unrelated reason, I finally got around to installing the extension Adblock Plus. Mixed feelings, as I don't want to deprive sites of the revenue that supports my habit, and I'd already been using the extension Nuke Anything (now Nuke Anything Enhanced) to manually click away the flashing, egregiously distracting stuff. Never did install Flash into Firefox, so that wasn't a problem.
Well, with Adblock Plus in place, the same old sites/pages are loading significantly more quickly. I'm not waiting on third party marketing servers to churn.
Another point for an open architecture, and for the user to be proactive. There are some things we can do, currently, from the client side, to maintain a responsive interface.
Paul B on November 11, 2006 12:19 PMIn light of this, how do you explain digg's success? The first time you visit, loading all the js takes up to 9 seconds. That didn't stop them from becoming one of the most popular sites on the web?
JackL on November 11, 2006 12:24 PMIn a Web application I recently developed, we just finished a major maintenance release. One of the things I've noticed about ASP.NET applications in general is the number of postbacks that occur as a result of the nature of ASP.NET's intrinsic architecture. Users perceive the postbacks as general slowness in the overall application. It bugged me as the application designer, since the application had lots of custom validators for the fields (can't always trust the users to enter valid data).
In the maintenance release, a major effort on my part was to find ways to improve application speed by (1) eliminating unnecessary graphics, (2) eliminating unnecessary postbacks wherever possible, (3) scripting some of the validation on in the HTML pages to provide immediate feedback (which led to elimination of some of the postbacks), and (4) reduce the user's need to scroll (which, for some reason I have yet to understand, users perceive as a performance issue because they have to spend a lot of time scrolling to get to the information they're interested in).
All of these things were done. The primary stakeholders didn't understand why I tackled them so aggressively, but to me they were important. Users weren't happy. Therefore, I wasn't happy. If the application was performing sluggishly, it was a pain to use, and users would be disinclined to use it. For this particular niche, it was vitally important that they use it, because the type of data they were managing was sensitive and needed to be accurate and complete.
Once the changes were completed and promoted to the live servers, users were *much* happier. The perceived changes in application responsiveness were thoroughly welcomed. Pages rendered faster, posted back to the server less frequently, alerted them to mistakes much earlier, and didn't
require as much scrolling. The system is getting much more consistent use, and the number of complaints from the users has significantly decreased, much to my satisifaction.
So speed does matter. The stakeholders might not understand it, but it does matter. It's especially important if the system in question is one where you *need* the users to use it and not have it frustrate their efforts.
I have google suggest (uk version) as my homepage and its lightning fast.
I'm not convinced using ajax in some apps is that good an idea - if you delete 5 emails in hotmail and then close the browser - it still says there are 5 emails unread if you then go back and open it up again.
Gregor Suttie on November 11, 2006 2:25 PMHa. I just clicked on that link to Dare's blog, and it took 22 seconds to fully load on DSL. Scary.
Matt Blodgett on November 11, 2006 3:02 PMScrolling is actually really slow / laborous. 1) You move your mouse to the scroll bar, including aiming at the bar knob. 2) You click and 3) hold down the mouse button. 4) You drag the mouse up or down and 5) release the mouse button. 6) Then you move the pointer back where it was, including aiming. So, unnecessary scrolling should be avoided.
Don on November 11, 2006 4:43 PMDon, do you still have a mouse from the early 90's?
Mark on November 11, 2006 7:13 PMEven if Don has a retarded mouse, he also has a point. Scrolling is definitely an inconvenience and even minor inconveniences can make a large difference.
Eam on November 11, 2006 9:03 PMMark, do you mean that my mouse has only 1 button, the button? I meant by the button the left button, because it is obviously the button you click when dragging a scrollbar knob. If you didn't mean this, but you meant, do I have a mouse that is so hard to use that its like from old days, then I say that no. My mouse is brand new.
Still it is more tedious to operate the scrolling than if you do not have to operate any scrolling. When we are trying to optimize a web page, not needing to scroll is one thing. Ok, it is fine to scroll, when the page is supposed to be large with lots of content. But if the content is not supposed to be large or the window could be bigger to fit the content anyway, or what ever, then unnecessary scrolling just feels so stupid that its getting on nerves. And why frustrate a user, when s/he can move to another web page in a blink of an eye. Or why not listen to an end user, who has to use the software every day.
Don on November 12, 2006 3:34 AMRight, I could of course use my mouse's scrolling wheel, too. Sometimes I use it, but it is not good when the page is really long. And I preferably stretch the page to fit all the content than scroll up and down.
Don on November 12, 2006 3:39 AMUmm, do some of you even know anything about Ajax? Blaming the Ajax "loading..." graphic for slow web sites is like like blaming progress bars for slow computer operations. "I wish they would take out that progress bar which takes so long to complete, it's just so slow."
Ajax will make the web smoother to use and faster, as long as it's used properly. It reduces traffic between the browser and server, processing load on the server, and the amount of refreshing on the browser. It's operations can be asynchronous (in fact they should), meaning that if an element on a web page issues a request to the server, the user can continue using the web page while the page waits for the response from the server.
If a lazy/ignorant programmer writes a system so that it performs a synchronous postback after each field change (usually just for validation purposes, but it can be a very useful technique when used properly) as hinted at by Mike Hofer above, that's hardly the fault of the Ajax protocol.
magnum on November 12, 2006 8:00 AMAdverts - are a major killer.
A simple non-ajax page with google-ads, and a couple of banners of ads will slow down immensely as it links off to other servers etc to generate the info.
Ajax is a slow method bud is versatile for some, but then add cross server advert linking and a couple of flash or macromedia space wasters and load time goes through the roof.
Firefox web browser = speed fix. And try the 'fasterfox' extension for firefox.
karl on November 12, 2006 3:13 PMI don't use FlickR because it's so slow.
A quick test, the "some pictures from the last 7 days" page took 17 seconds to load.
Clicking on an image took 11 seconds before the image was visible, and about 20 before the page finished loading.
I want to flick through online pictures quickly...
sfb on November 12, 2006 7:13 PMThis really interesting from a South African perspective where 10-12 loading times on Google searchs is the norm because of our poor communications in this country.
Developing for the web in South Africa, I think, really pushes the understanding of response time to users.
Andre Odendaal on November 13, 2006 3:17 AMFIrefox isn't a panecea. It has some issues, like refusing to display a page (that's already fully loaded) if links to a connected server have died - I see this happening a lot when it tries to load javascript and css from dead pages retrieved from google cache. You have to wait a minute for the connections to time out before it'll even show the page.
(I remember fondly when it would reflow the page as it loaded the css - I guess that behavior was deemed unacceptably distracting and removed.)
Foxyshadis on November 13, 2006 3:44 AMMy browser home page is set to about:blank, cause even Google is too slow...
Jeremy on November 13, 2006 5:40 AMAm I the only one who just makes his own homepage and sets the browser to the local file? Sure its not dynamic, but if I want news I'll just add a link to the source I might want to read, (or just use my FF RSS).
Twinblade on November 13, 2006 6:58 AMlol @ dial-up rising from the dead. #1-it's not dead. as i'm sure you know, lots of people still use dialup. and #2 high speed internet is supposedly cheaper in other parts of the world. telecom/cable companies will keep broadband prices at a rate where they can keep/increase customers. broadband is really not that expensive for them to provide so they can bring prices down as demand/supply vary. you can get broadband (slow dsl, at least) for about what you pay for dialup ($20-30 depending).
as for page speed, page loading times have been an issue since the internet became open to the average person. it's nothing new, and i don't think it's ever really improved to the point where it would have opportunity to regress again. heh.
page load timing is one reason i almost always have multiple browser tabs open so i can do other things while i wait for content to load.
rach on November 13, 2006 7:54 AMThe beta Yahoo news and the Windows Live services take an absurd amount of time to load, especially when compared to a full featured web-mail app like Gmail. Thankfully, I could still revert my Yahoo mail account back to the old interface.
Neither of these services seem ready for prime time.
PapaBoojum on November 13, 2006 10:45 AMEven gmail is pretty slow to load for me, although a bit faster than the new Yahoo and Hotmail clients. I often get stuck on the "loading.." page for gmail.
Jeff Atwood on November 13, 2006 1:50 PM> Even gmail is pretty slow to load for me, although a bit faster than the new Yahoo and Hotmail clients. I often get stuck on the "loading.." page for gmail.
That's because of one thing...a standard markup language will allows be a bit bloated and not be the best solution for large amounts of data. The software vendor we use for CRM has been pushing a browser based application for years now as the next best thing since sliced bread. But they basically hit a wall were the technology simply cannot support with reasonable speed and efficiency what they need it to. And for their next big release they are moving back to a windows client (.NET Smart Forms).
Tim on November 13, 2006 2:07 PMJust as another example of preferring information when I want it. I recently got a dead tree subscription to my local newspaper because I was tired of having to deal with load times and annoying ads just to read the news. Yes there are multiple papers in this area but all their websites have the same problem.
Paul on November 13, 2006 3:32 PMAJAX *used right* will speed up websites. The core functionality needed to do Ajax stuff really doesn't take long to load upfront. It's footprint should easily compare to other standard web-page stuff, like CSS and graphics. You actually don't need to load anything extra, really.
But, if you are using the web to deliver full-fledged apps, then you will end up loading q lot more. Why? Well - the full GUI is basically running in the browser. It is using low-cost Ajax to communicate with the server - which is fine, but managing the user interface itself is another story. Manipulating the DOM model can be a bit cumbersome, and most developers resolve to a third-party library for this (or make one themselves - to "ease the pain"). Which is very understandable. Also, some apps abstract the DOM model into GUI widgets, which involves quite a bit of DOM, CSS and JS-event handling. This is cool (I think - from a geeky perspective), but the downside is that this means another library.
I wish that XUL (http://www.xulplanet.com/) became a W3C standards recommendation for browsers, which would make it uneccesary to add these libraries and present rich web-apps to users, without the current delay... XUL is already in Mozilla, it is actually the way itself is built. I realize that this is a pipe dream though. It would take *a lot* of Redmond ass-kicking to get the same technology into MSIE...
Ronny on November 14, 2006 2:09 AMSeems like the 20% drop in revenue could be due to the fact that people aren't paging through the results as much. Less impressions = less revenue.
I don't buy into the fact that AJAX makes the web slow. In fact, properly used AJAX is designed to make the web a more responsive place. Just because some people are using it improperly doesn't mean that you can dismiss the whole technology as slow.
Ryan on November 14, 2006 7:50 AM "AJAX *used right* will speed up websites"
"In fact, properly used AJAX is designed to make the web a more responsive place"
Sure, and you can see that multi-billion Yahoo and MS are developing real fast AJAX applications instead of bloating poor end-users with fancy graphics
Second vote for about:blank
Tom Clancy on November 21, 2006 4:26 AMAjax is always a good choice for "web apps" tho, imo. The app loads and then no more need to reload a page after initial start up. ajax also lets a user perform complex multi-step tasks w/o leaving the page. i guess it all depends on your user base. personalized pages are mostly going to be slow loading. i have been working on a personalized home page for some time now that hopefully loads like lightning when i finish it. the most important thing is that the most important part of the page loads first, i.e. the search section then feeds, imo.
toadware,com on June 14, 2007 5:01 PMI simply saved the HTML and images from Google's homepage to my local disk and set my homepage to "file://c:\google\index.html".
It doesn't get much faster than that!
Jamie on January 6, 2009 6:37 AM@jamie - chrome makes the address bar a search bar, I bet I can Ctrl-L faster than you can mouse to the home button ;)
Sascha on January 21, 2009 6:21 PM@Sascha -- alt-home for the win!
Silas on January 21, 2009 7:48 PMwell... call me crazy, but maybe the traffic dropped because w/ 30 results per page, people didn't have to click onto the second or third page link?
Darren Kopp on January 29, 2009 11:08 PM| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |