2

I would like to set performance requirements for web application. I am interested in performance from user experience view so I plan to measure time from request is sent until onLoad event is fired in the browser. I am aware that each application is different and performance requirements might differ as well. Still it will be good to have some guideline values that can help assess performance and set up targets. Does any of you have some stats/report that present average/max page load times for recent web application or some studies that can help in setting up performance targets?

  • 2
    I'm voting to close this question as off-topic because more about the user experience instead of testing performance. Possible duplicate of ux.stackexchange.com/questions/71939/… – Niels van Reijmersdal Oct 23 '15 at 12:00
  • 2
    Voting to leave open, as QA professionals are often asked to come up with performance requirements, especially in small offices or startups. Reporting on performance is often a significant part of a QA professional's job in these situations. – Ethel Evans Oct 23 '15 at 21:26
  • Take a look at stevesouders.com it might provide what you need. – Joe Strazzere Nov 23 '15 at 17:43
  • Thanks for pointing this out. I have already found some kind of answer when watching youtube.com/watch?v=f5_iAzS3WMQ – Jacek Nov 24 '15 at 19:35
1

To be precise and very specific there are no certain guidelines and benchmark defined for the web application related to their Performance. This is a thing which comes to mind of every QA, but unfortunately there are no worldwide or Organization wise accepted standards for the Response Time. It depends upon a number of factor including (but not limited to) Quality of Code, Server Configuration, Complexity of Application and code, Expected/Actual User Load, Time when user hit the server, Bandwidth etc.

But as per the book "The Art of Application Performance Testing" by "Ian Molyneaux", there is something mentioned about what you are looking for (Note: This is should not be taken as Line drawn over stone)


The following list summarizes research conducted in the late 1980s (Martin 1988) that attempted to map user productivity to response time. The original research was based largely on green-screen text applications, but its conclusions are probably still relevant.

Greater than 15 seconds This rules out conversational interaction. For certain types of applications, certain types of users may be content to sit at a terminal for more than 15 seconds waiting for the answer to a single simple inquiry. However, to the busy call-center operator or futures trader, delays of more than 15 seconds may seem intolerable. If such delays can occur, the system should be designed so that the user can turn to other activities and request the response at some later time.

Greater than 4 seconds These delays are generally too long for a conversation requiring the end-user to retain information in short-term memory (end-user’s memory, not the computer’s!). Such delays would inhibit problem-solving activity and frustrate data entry. However, after the completion of a transaction, delays of 4 to 15 seconds can be tolerated.

2 to 4 seconds A delay longer than 2 seconds can be inhibiting to operations that demand a high level of concentration. A wait of 2 to 4 seconds at a terminal can seem surprisingly long when the user is absorbed and emotionally committed to completing the task at hand. Again, a delay in this range may be acceptable after a minor closure. It may be acceptable to make a purchaser wait 2 to 4 seconds after typing in her address and credit card number, but not at an earlier stage when she is comparing various product features.

Less than 2 seconds When the application user has to remember information throughout several responses, the response time must be short. The more detailed the information to be remembered, the greater the need for responses of less than 2 seconds. Thus, for complex activities such as browsing camera products that vary along multiple dimensions, 2 seconds represents an important response-time limit.


Also, before mentioning the above content writer himself has marked.

By the way, if you were hoping I could point you to a generic industry standard for good and bad performance, you’re out of luck because no such guide exists. There have been various informal attempts to define a standard, particularly for browser-based applications.


So, just go through these lines and then discuss the same with the client/higher management and then decide your benchmark based on your study, User Load, Application framework, Future scope of application etc. For instance you can take reference of a similar application which is currently live in market.

Remember, these are the goals/benchmark which you have to define, but they are always negotiable depending upon conditions.

0

A number of tools which can help:

  • Wireshark - network sniffer, allows to inspect network packets
  • YSlow - page load analyser which has some useful built-in presets you can use as a baseline. Also it can provide some recommendations on how page load speed could be improved.
  • A load testing tool to check how does you application behave under the load. The best of free and open-source are:

See Open Source Load Testing Tools: Which One Should You Use? article which highlights the main features of the aforementioned tools, has sample test with load reports and comparison matrix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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