The response time here is terminal/UI response to user inputs, not, say, HFT, though that might make for an interesting side discussion.<p>There's a related set of discussions on Jakob Nielsen's Site Formerly Known as UseIT (now the vastly less memorable "nngroup.com"): "Response Times: The 3 Important Limits": <a href="https://www.nngroup.com/articles/response-times-3-important-limits/" rel="nofollow">https://www.nngroup.com/articles/response-times-3-important-...</a><p>TL;DR: the limits are 0.1s, 1s, and 10s.<p>Nielsen also notes that response can be too fast: <a href="https://www.nngroup.com/articles/too-fast-ux/" rel="nofollow">https://www.nngroup.com/articles/too-fast-ux/</a><p>A classic current example is of redrawn Web or application dialogs, in which the element under a pointer (mouse, finger, stylus) changes <i>as the user is attempting to click it</i>. An elegant solution I've seen suggested: that the UI register the click <i>on the UI element which had occupied the spot 300ms PRIOR to the click.</i><p>(Redrawn elements are a particular problem for visually, motor-control, or cognitively disabled users -- the changes are too fast and confusing to keep track of.)<p>Website response times: <a href="https://www.nngroup.com/articles/website-response-times/" rel="nofollow">https://www.nngroup.com/articles/website-response-times/</a><p>Time scales in user experience: <a href="https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/" rel="nofollow">https://www.nngroup.com/articles/powers-of-10-time-scales-in...</a><p>From 0.1s to 100 years.