I think this article by Jakob Nielsen can give you a hint:
Update added 2014: I keep getting questions like this, so I decided to answer it here.
Q: "You mention many times that response time is important, and there are tons of tools to measure response time, but what is an acceptable web based application's response time? What is a user's tolerance, not for a shopping experience, but for an interactive application?"
A: I wish we could eradicate the term "web-based application" because it distracts from the real issue, which is one of application UI design (we have several full-day courses on this topic). We don't have special guidelines for applications implemented in C++ relative to apps implemented in JavaScript. The fundamental usability recommendations are the same, no matter the implementation, since we are discussing user experience, not coding.
Therefore, the response time guidelines for web-based applications are the same as for all other applications. These guidelines have been the same for 46 years now, so they are also not likely to change with whatever implementation technology comes next.
0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column — if so, users would feel that they are sorting the table. (As opposed to feeling that they are ordering the computer to do the sorting for them.)
1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.
The quicker the better I would say but in my opinion there's something different between waiting for a website to load on a mobile device and waiting for it on my (faster) pc at home.
We are not yet used to a very fast connection on our mobile phones I think.
I traveled in a train with some friends two days ago and we started to look for an answer on google. The speed was so slow that we continued talking for at least 30 seconds while waiting for the page to load and well.. it wasn't a problem at all. The point is that I wouldn't use my smartphone for spending hours of research but more often for browsing while I'm sitting in the bus or something like that where it is no problem to wait some seconds for a page to load.
The moment I realize that it is not my connection that makes the page load long but e.g. some big images on this website I stop it and start looking for another search result.
