5 ms·

I'm not sure why you trust Google Web "Fundamentals" that 0-100ms is perceived as instant. The upper bound is perceptibly laggy. I have no idea where Google to

I'm not sure why you trust Google Web "Fundamentals" that 0-100ms is perceived as instant. The upper bound is perceptibly laggy. I have no idea where Google took their numbers from. FID of 100 ms is already bad as you have to add network latencies on top of it. To put things into perspective, it's more than the time it takes to fully boot embedded Linux as coreboot from not too fast flash or start up Commodore 64 with a good extension cartridge. The browsers are terribly slow.

treerock 8y ago
r.e. the 100ms, some references are given on this stackoverflow question. https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay#2547903 https://stackoverflow.com/questions/536300/what-is-the-short...
- Xichom2k 8y ago
  I don't think scroll gestures or incrementally-loaded content with layout reflows were a thing back then, so that might need re-evaluating.
  - AstralStorm 8y ago
    I'm pretty sure layout reflows were considered, as HTML rendering itself is incremental in almost all sensible browsers. (Thus the ideas of embedding CSS and JS in localized pieces where applicable.) Scroll gestures were not a thing typically, you just did a full request.
    - Xichom2k 8y ago
      Sure, it's incremental, but static site layouts, especially the old float-based ones will have had their headers and sidebars loaded from the start and the main content would not jump around. Modern pages with ads and widgets popping in potentially anywhere main remain unusable and unreadable because the main content keeps jumping around.
- jcelerier 8y ago
  > ...a team of neuroscientists from MIT has found that the human brain can process entire images that the eye sees for as little as 13 milliseconds...That speed is far faster than the 100 milliseconds suggested by previous studies...
  - teej 8y ago
    This is easy to internalize when you remember that humans can tell the difference between 30fps and 60fps which is one frame every ~33ms vs every ~17ms
    - mrob 8y ago
      Humans can tell the difference between 1000fps and 2000fps too (with a test signal of a point light source flickering at >500Hz, and viewed with rapid eye movement to produce the phantom array effect. Note that temporal anti-aliasing is needed to avoid cheating with easily visible beat patterns.) This doesn't mean we can process an image in 0.5ms.
    - extrapickles 8y ago
      You can tell the difference between 144hz and 60hz, especially if user input is involved (eg: using mouse to look around). The resolution of human skill depends heavily on the exact scenario as the body is complex. Even with eyes you have high density in the center of vision, low density outside, and they have different light sensitivities which makes them hard hard to model. To further complicate matters is the brain that does further processing that can result in hyperacuity. A good example of hyperacuity is in reading Vernier scales where you can see differences much below the angular resolution of the eye.
davemp 8y ago
The rule of thumb I've seen used in the embedded world is 50ms latency for user input and I found that it's still noticeable vs say 25ms.
- taneq 8y ago
  Getting offtopic here but arguably the best thing about the growing prevalence of VR is that it's forcing everyone to focus on maximum latency rather than frame throughput, and so that godawful stutter is finally being exorcised from our rendering stacks.
tbrock 8y ago
I’ve always believed that the 100ms figure includes network round trip time.
espeed 8y ago
> I'm not sure why you trust Google Web "Fundamentals" that 0-100ms is perceived as instant. Those numbers go back to the studies Jakob Nielsen did at the Sun Microsystems usability lab and the results posted in his oft cited AlertBox articles from 1993 and 1997... https://www.nngroup.com/articles/website-response-times/ https://www.nngroup.com/articles/website-response-times/
- dragonwriter 8y ago
  > Those numbers go back to the studies Jakob Nielsen did at the Sun Microsystems usability lab and the results posted in his oft cited AlertBox articles from 1993 and 1997... Actually, Nielsen indicates that had already been a consistent finding for ~30 years at that point, citing “Response time in man-computer conversational transactions” (Miller, 1968) [0] as the original source. [0] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Response+time+in+man-computer+conversational+transactions.&btnG=#d=gs_qabs&p=&u=%23p%3DwHCq1AiNo9UJ https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Resp...
bluquark 8y ago
100ms is slightly arbitrary, but the real point of saying "100ms" is that it's lower than the multiple seconds typically required for page load, and higher than the 16ms required for smooth animation. An appropriate target for input response time (the "R" in RAIL) is somewhere in between those two. If 100ms strikes you as too high, then by all means target a lower number like 50ms. But it's still not a disaster if your 95th percentile is 100ms. Also, if your A time is above 16ms or your L time is above 5 seconds, your limited development time might be better spent improving those rather than bringing R down even further.

treerock 8y ago

r.e. the 100ms, some references are given on this stackoverflow question. https://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay#2547903 https://stackoverflow.com/questions/536300/what-is-the-short...

Xichom2k 8y ago
I don't think scroll gestures or incrementally-loaded content with layout reflows were a thing back then, so that might need re-evaluating.
- AstralStorm 8y ago
  I'm pretty sure layout reflows were considered, as HTML rendering itself is incremental in almost all sensible browsers. (Thus the ideas of embedding CSS and JS in localized pieces where applicable.) Scroll gestures were not a thing typically, you just did a full request.
  - Xichom2k 8y ago
    Sure, it's incremental, but static site layouts, especially the old float-based ones will have had their headers and sidebars loaded from the start and the main content would not jump around. Modern pages with ads and widgets popping in potentially anywhere main remain unusable and unreadable because the main content keeps jumping around.
jcelerier 8y ago
> ...a team of neuroscientists from MIT has found that the human brain can process entire images that the eye sees for as little as 13 milliseconds...That speed is far faster than the 100 milliseconds suggested by previous studies...
- teej 8y ago
  This is easy to internalize when you remember that humans can tell the difference between 30fps and 60fps which is one frame every ~33ms vs every ~17ms
  - mrob 8y ago
    Humans can tell the difference between 1000fps and 2000fps too (with a test signal of a point light source flickering at >500Hz, and viewed with rapid eye movement to produce the phantom array effect. Note that temporal anti-aliasing is needed to avoid cheating with easily visible beat patterns.) This doesn't mean we can process an image in 0.5ms.
  - extrapickles 8y ago
    You can tell the difference between 144hz and 60hz, especially if user input is involved (eg: using mouse to look around). The resolution of human skill depends heavily on the exact scenario as the body is complex. Even with eyes you have high density in the center of vision, low density outside, and they have different light sensitivities which makes them hard hard to model. To further complicate matters is the brain that does further processing that can result in hyperacuity. A good example of hyperacuity is in reading Vernier scales where you can see differences much below the angular resolution of the eye.

davemp 8y ago

The rule of thumb I've seen used in the embedded world is 50ms latency for user input and I found that it's still noticeable vs say 25ms.

taneq 8y ago
Getting offtopic here but arguably the best thing about the growing prevalence of VR is that it's forcing everyone to focus on maximum latency rather than frame throughput, and so that godawful stutter is finally being exorcised from our rendering stacks.

tbrock 8y ago

I’ve always believed that the 100ms figure includes network round trip time.

espeed 8y ago

> I'm not sure why you trust Google Web "Fundamentals" that 0-100ms is perceived as instant. Those numbers go back to the studies Jakob Nielsen did at the Sun Microsystems usability lab and the results posted in his oft cited AlertBox articles from 1993 and 1997... https://www.nngroup.com/articles/website-response-times/ https://www.nngroup.com/articles/website-response-times/

dragonwriter 8y ago
> Those numbers go back to the studies Jakob Nielsen did at the Sun Microsystems usability lab and the results posted in his oft cited AlertBox articles from 1993 and 1997... Actually, Nielsen indicates that had already been a consistent finding for ~30 years at that point, citing “Response time in man-computer conversational transactions” (Miller, 1968) [0] as the original source. [0] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Response+time+in+man-computer+conversational+transactions.&btnG=#d=gs_qabs&p=&u=%23p%3DwHCq1AiNo9UJ https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Resp...

bluquark 8y ago

100ms is slightly arbitrary, but the real point of saying "100ms" is that it's lower than the multiple seconds typically required for page load, and higher than the 16ms required for smooth animation. An appropriate target for input response time (the "R" in RAIL) is somewhere in between those two. If 100ms strikes you as too high, then by all means target a lower number like 50ms. But it's still not a disaster if your 95th percentile is 100ms. Also, if your A time is above 16ms or your L time is above 5 seconds, your limited development time might be better spent improving those rather than bringing R down even further.