Back in 1997 Jacob Nielsen was suggesting:
Currently, the minimum goal for response times should therefore be to get pages to users in no more than ten seconds
Obviously expectations have sped up a fair bit since then.
How many seconds do we think is reasonable nowadays?
The latest research I know of suggests 2 seconds as the new benchmark.
Personally, I don't think it's quite that black and white - the faster your page loads, the better. Some stats to support this:
It routinely takes more than 10 seconds to load a webpage on my iPhone. And I wait for it. So does everyone else with a smartphone, a shockingly large number of web users these days.
Page load times matter, but putting a # of seconds on it is missing the point. If it's the timesheet software I have to use to get paid, I'll wait a minute for it to load! If it's a fluff piece about how excess blogging will cause mild tingling in the soles of one's feet, a second might be too much.
Make your page as efficient as possible, and test it on the machines you are targeting. If you don't care about dial-up folks in West Nowheresville? Don't target them--they're used to everything taking two minutes.
In this Google Analytics blog post from this past April, Google shows mean and median site speeds world wide:
Important and of note here is that this is 2012, and site loading speed on mobile is a critical factor in measuring the responsiveness of your site.
Based on these worldwide results, it would probably be advisable to target your website to be faster than the average speed, which from Google's data appears to be around 7 seconds on desktops and 10 seconds on mobile. So try and get below that.
Optimising for speed also has very different impacts on your development process compared to several years ago. With the advent of techniques like responsive design where you often include the same resources for different media, you need to think differently about how you prepare and deliver assets depending on which device is accessing your content and what bandwidth is available. Employing minification, gzip, and content delivery networks all contribute to this goal.
I would say 0.5 seconds faster than your competition.
Keep in mind that there are still plenty of people around the world with dialup connection speeds (and, in the case of sites hosted on a single server w/o edge caching being visited by geographically distant visitors, network latency factors in) so it's still really a matter of whether you're catering to broadband users or trying to please everyone everywhere.
I recall the Google Page Speed tool complaining about pages which required more than three seconds to download on a broadband connection - I would recommend you check out the tool for your own testing, if you haven't already.
There's really no excuse to force broadband users to wait more than two or three seconds to begin seeing content or a "loading" dialog and, given the availability of the aforementioned optimization tool, it is relatively painless to make the necessary changes.
I think the problem with this question lies partly with the trend toward shorter load times, and partly with the dissolution of the concept of "a page". What does "page load time" mean in a world of mash-ups, ajax, and single-page web applications?
The answer is not going to come in terms of "how many milliseconds or seconds" but in terms of "what is most pertinent and relevant to the current user at the current moment". Take Google's image search as an example. A search result page never actually "loads" ... more images are pulled into the browser as you continue to review them and scroll.
This was a topic of a recent blog post of mine. Basically, the answer arrived at is less about absolute rules and more about heuristics of what is important to a user:
In my work, I design pages to load static HTML (distributed globally using a CDN), optimize for speed the core items that focus on the above goals as fast as possible. Of secondary concern are images, graphics, details, advertisements, and more. You can load the gist of a page extremely quickly before loading the rest of the page.
As fast as you possibly can :-)
People find again and again the faster the response time the better the conversion rates you get. You'll even get better rankings in Google! See http://www.useit.com/alertbox/response-times.html and http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html/ for example.
Despite Jakob Nielsen's insisting on doing things like this there is no specific answer that you can give to this.
But speed is an important part of the user experience and one which is often lost somewhere between UX, design and engineering.
One of the best resources I have found on the subject is Stoyan Stefanov's (ex-Yahoo currently Facebook engineer and creator of the Yslow! plugin) Book of Speed. Especially the first chapter has some nice case studies of how performance affects all aspects of the user experience.
Depending on your target groups and the performance of the systems you are working with you can set ambitious targets. I think the point is that it's maybe worth dedicating a lot of engineering time to improving performance and not blowing it all on snazzy ajax front-end features. But there's no set rule of thumb.
There is a lot of potential for being innovative in the way the system handles load times. I just recently saw a presentation from an Instagram engineer where he talks about system speed vs the perceived speed to the user. Maybe the user doesn't need to see the actual uploading happening, but she can just start it and then be informed later if it has failed. When you press a button you can maybe let the state be activated right away even if there's still some work going on in the back end.
Here is "OFFICIAL GOOGLE WEBMASTER" of - April 2010, which gives a link to internal studies where this document was definitive on "Speed Matters".
The answer is: FRACTIONS OF SECONDS, (MILLISECONDS), MATTER TO CUSTOMERS, OR THEY WILL SWITCH. Referenced numbers are as low as a quarter of a second or 250 milliseconds.
Google discovered that a change of loading a 10-result page in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006). Google Search found that a 400 millisecond delay resulted in a -0.59% change in searches/user. What’s more, even after the delay was removed, these users still had -0.21% fewer searches, indicating that a slower user experience affects long term behavior. Google found that an extra 500 millisecond in loading time resulted in 20% drop in traffic.
I agree with the majority of the points that have been made here, but we can also look at the problem from a different angle.
Real speed ≠ Perceived speed
It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.
Extract from The Truth About Download Time, by by Christine Perfetti and Lori Landesman (2001).
I've heard a representative of a well-respected broadcaster say that they currently aim to serve all pages within 0.5 seconds, but were hoping to get it down to 0.25 seconds. This is an organisation with considerable resources. Apologies for not naming the broadcaster, but I'm not sure how much of the meeting I was in at the time was NDA'd or whether this target would be common knowledge outside the organisation.
I agree with Schroedingers Cat that answers to this have to be more nuanced. For instance, I can imagine that an organisation might commit to having 90% of pages load within x seconds when tested on a variety of machines running different browsers over different connections — because it's just not realistic to expect that every page will load on time every time. Stuff happens; the Internets get the hiccups now and again.
I am pretty sure that Bob Spence's team at Imperial College, London were the first to investigate System response time in interactive software in 1978 (not sure I had even touched a computer by then). He had designed a very early interactive graphical tool for circuit design using a lightpen. He found that:
"A System Repsonse time of 1.49 sec was found to degrade performance by about 50%, measured by problem solution time, compared with that found for 0.16 and 0.72 seconds."
Obviously waiting for a web page to load on a mobile is a very different context. However we are doing more and more work in the cloud ... slow update would equally distract the user form the task at hand. I would say that "as soon as possible" should be aim. And since according to Bob's data around a second is a minimum to prevent disruption in problem-solving, then his results would still hold today despite the vast differences in context!
http://dl.acm.org/citation.cfm?id=807378
You can see a video of the system here: MINNIE (it is the second video) http://www2.imperial.ac.uk/blog/videoarchive/2010/01/01/research-and-innovation-bob-spence/
I think there have to be more nuanced answers than x seconds. I have just written an intranet application where I have put a limit of 5 secs, and a goal of 1 sec. In this specific environment, the limits are more variable, as long as the busiest pages are quick - closer to the 1 sec. And there are more important demands than just page load times.
For an e-commerce type site, when I was producing them, we aimed at 1 second for the home page, 1-2 seconds for the ( cached ) catalogue pages, and only exceeded this for the basket process, which was often not timed, but would be up to 5-10 seconds. All of this based on a company network and internet connection.
The problem with arguing for "as fast as possible" is that you need to balance this against other factors - the cost of development, the timeliness of the data. Producing a page in .1 seconds that has out of date data is worse than producing a page in 2 seconds that is up to date usually. And is it worth the cost of improving from 1 second to 0.95 seconds?
And, as others have pointed out, you really need to compare sites, not produce absolute values, or produce values specifying the infrastructure. 1 second on a high-end broadband connection is not the same as 1 second on dial up.
Page load times depend on the context of what page that is being loaded. To generalize one load time across the entire visitor experience is unrealistic. When a visitor lands on the front page of a major news portal it can be expected to take longer to load, then say loading a particular news article.
This relates to the expected value for waiting in the visitors mind. For a news portal's home page it's expected there will be more content, and headlines for the visitor to review.
Again, for a blog the load time might not be very important to a visitor who is landing to read one article, compared to a visitor who is browsing multiple articles. If the blog takes a while to load each page, then the visitor is encouraged by this experience to leave. Where as, the visitor landing from a search term to read a "how to" and plans on leaving. Load times aren't that important.
So 2 seconds load time for a home page might be fine, but not good for an article. You need to figure out the visitors experience you want them to have, and set load time goals based upon that desired experience. To generalize load times across the entire Internet isn't really practical because of the wide range of technology being used to host websites.
Jacob Nielsen wrote a good article Website Response Times about the response time and perception.
• 0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer. This level of responsiveness is essential to support the feeling of direct manipulation (direct manipulation is one of the key GUI techniques to increase user engagement and control — for more about it, see our Principles of Interface Design seminar).
• 1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.
• 10 seconds keeps the user's attention. From 1–10 seconds, users definitely feel at the mercy of the computer and wish it was faster, but they can handle it. After 10 seconds, they start thinking about other things, making it harder to get their brains back on track once the computer finally does respond.
These days, even 400 milliseconds — literally the blink of an eye — is too long, as Google engineers have discovered.
To test page load speeds and optimize settings for best performance, you can visit Google Page Speed.
