Task-based Latency Tolerance for Web Browsing and Applications

Some research for client work prompted me to write this up and I wanted to share it.

Modern web browsing incorporates at least two distinct interaction paradigms, information-seeking browsing and navigation, (where the dominant interface element is the text or image link) and interactions where the user is performing a specific action via a web application (where the dominant interface elements resemble desktop applications, buttons, drop-down boxes and the like).
User latency tolerance and quality of service perception based on that latency varies greatly between the two types of functionality. Research indicates user tolerance is based on ?conceptual models of how the system works? and many users expect that merely requesting a possibly cached page or otherwise static content though navigational link-clicking (or using their browser?s back button) will yield sub-second response times. Additional delays in these types of actions will reduce the user?s quality of service perception.
On the other hand, research also indicates that if users ?see a glimpse of what seems like a web-application they make assumptions that make you think they are treating your web-app like a desktop app. This means that more traditional user-interface response guidelines apply. For decades studies have shown that ten seconds is ?about the limit for keeping the user?s attention focused on the dialogue… so they should be given feedback indicating when the computer expects to be done.? This feed back is ideally presented by warning the user before the action is taken, by showing a percent-done indicator during the waiting time and giving the user a way to escape the delay, such as a cancel button. Data also indicates that users are less tolerant of longer latencies later in their interaction sessions.