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?

  • as a side note, here is some literature about why is page speed important: impressivewebs.com/importance-of-website-performance-sources Commented Dec 20, 2011 at 17:15
  • This question was suggested as a duplicate: What original sources have research on how long it takes a visitor to decide whether to stay on the site? But there's a difference between how long it takes a page to load and how long it takes a user to decide whether to stay, so I've reopened the question. Commented Dec 21, 2011 at 13:51
  • 5
    As fast as possible!
    – darryn.ten
    Commented Jun 19, 2012 at 9:19
  • 1
    One thing to note is that the user is often sensitive to responsiveness (how long until something happens), rather than completeness (how long until everything has happened) - loading part of the page and showing a "loading" sign on the rest will often hold the user's attention longer than waiting for the whole page to appear at once, even if the latter is actually faster start to finish.
    – Jon Story
    Commented Oct 12, 2015 at 13:19
  • Interesting article that discusses Google's view on page speed - that it really depends on the use case as well as the user: searchengineland.com/…
    – Michael Lai
    Commented Oct 31, 2019 at 23:41

16 Answers 16


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:

  • In 2006 Google’s tests showed that increasing load time by 0.5 seconds resulted in a 20% drop in traffic.
  • In 2007 Amazon’s tests showed that for every 100ms increase in load time, sales would decrease 1%.
  • 8
    could you provide links to google test and amazon test?
    – Morgan T.
    Commented Nov 7, 2011 at 16:56
  • Amazon can be found via searching "Kohavi and Longbotham 2007 amazon" (w/o quotes). This is the best I could do for Google. Commented Dec 20, 2011 at 15:12
  • 6
    Akamai has everything to gain by making people believe fast is better; meaning they 'sell' fast content delivery, that's how they make money. For that matter, the same applies to Amazon, since they host eCommerce sites; meaning if they're able to make users of there service believe it matters, then Amazon already has the systems to deliver fast. As for Google, the same applies as well, more traffic equals more page/ad views.
    – blunders
    Commented Jun 14, 2012 at 14:45
  • 7
    That doesn't mean it's not true. No one wants their time wasted.
    – aslum
    Commented Jun 18, 2012 at 16:12

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.

  • On mobile data or wifi?
    – darryn.ten
    Commented Jun 19, 2012 at 9:26

In this Google Analytics blog post from this past April, Google shows mean and median site speeds world wide:

enter image description here

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.

  • 2
    That link is particularly useful because it also breaks down mean and median speeds by country and by site vertical. Thank you!
    – kastark
    Commented Jun 18, 2012 at 16:31

I would say 0.5 seconds faster than your competition.

  • 1
    Although a bit snarky - I love this comment! Commented Jun 18, 2012 at 15:52
  • @ChrisKluis It does sound so; my intention was real and serious, though.
    – Kris
    Commented Jun 19, 2012 at 7:32

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:

  • Load the parts of a screen that reveal the general relevance of the content as quickly as possible
  • Paint the structure of the screen to give users quick orientation / context
  • Let users know how to exit the current screen if it's not relevant
  • Give users a quick view of the next best action
  • Prioritize elements on the page based on user goals / use cases.

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.

  • 2
    Very good points, and a nice article too. I think this raises some interesting questions too; such as what type of content should you load first - what content are users happier to wait for and what do they need straight away.
    – JonW
    Commented Jun 18, 2012 at 10:03
  • 1
    In most single-page interfaces that make heavy use of Ajax -- e.g. Gmail, Google search, Gawker sites, Twitter, Github's tree slider, certain areas of Facebook -- the concept of a "page" still seems like a useful metaphor as a unit of navigation, making "page load time" still a relevant performance metric. Infinite scrolling is a notable trend, but not the main use case for SPI's/Ajax-heavy web properties. In SPI's I'd say a "page load" is a UI transition that loads new resources into view and updates the browser address bar, and "page load time" is how long it takes to do that.
    – jqp
    Commented Jun 18, 2012 at 13:10

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.

They say:

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.

  • The creator of the bounty wants to see new answers as the current ones are too old. Citing a study from that same period presumably isn't very useful, in that case :-)
    – Rahul
    Commented Jun 18, 2012 at 15:53
  • Would you be satisfied to find that in 2012, a tenth of a millisecond causes some users to switch? With all due respect, 'as fast as possible' has been the answer since' 2010.
    – Jack Stone
    Commented Jun 18, 2012 at 16:04
  • My gut feeling is that that's true; I was just hoping for some more up-to-date references to confirm (or refute) it. Bear in mind also that the correlation of page load times to conversion is unlikely to be linear, so the exact nature of the correlation is important too.
    – kastark
    Commented Jun 19, 2012 at 15:10

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.

  • Your answer would be better if you mentioned who the "well-respected broadcaster" was and could reference it.
    – Rahul
    Commented Jun 18, 2012 at 15:54
  • Thanks Rahul — I knew it would, but I didn't want to go trampling over the NDA :) Commented Jun 19, 2012 at 9:37

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."

image of an early light pen

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!


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.


2012 from the NY Times

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.