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.
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=Resp...
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.
https://stackoverflow.com/questions/536300/what-is-the-short...
(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.
Modern pages with ads and widgets popping in potentially anywhere main remain unusable and unreadable because the main content keeps jumping around.
A good example of hyperacuity is in reading Vernier scales where you can see differences much below the angular resolution of the eye.