← Core Web Vitals

The 1946 experiment that defined the INP threshold

Google did not pick 200ms because it sounded reasonable. The number traces back to a Belgian psychologist, two moving shapes, and a finding about how the human brain perceives causality.

The experiment

In 1946, Albert Michotte published La perception de la causalité. He was trying to answer a question philosophers had argued about for centuries. Hume said causality cannot be perceived directly. We see one event, then another, and infer the connection. Michotte thought Hume was wrong.

To test it, he showed people two moving shapes on a screen. Object A moves toward Object B. The moment A touches B, A stops and B starts moving away.

Then he varied one thing. The delay between contact and B starting to move. Drag the slider below and hit Play.

What he found

The result was reproducible across hundreds of observers. The boundary was sharp.

Michotte called the first case the launching effect. People did not infer causality. They saw it, the same way they see colour or motion. Above 200ms the perception collapsed. The two shapes became two unrelated events that happened near each other.

The chain to INP

Fast forward 22 years. In 1968, Robert Miller at IBM published Response time in man-computer conversational transactions. Miller cites Michotte. He defines a 100ms threshold for what he calls "response to control activation." The delay between pressing a key and visual feedback should be no more than 0.1 to 0.2 seconds, he writes. Otherwise the user stops feeling like the press caused the response.

In 1993, Jakob Nielsen wrote Response Times: The 3 Important Limits, the most cited piece of HCI writing on the web. Nielsen cites Miller. 0.1 second is the limit for having the user feel that the system is reacting instantaneously.

In 2014, Kaaresoja and others tested it on touchscreens specifically. Same finding. When the delay between tapping a virtual button and visual feedback was 85ms or less, participants reported the feedback appeared simultaneous with the tap 75% of the time. Above 100ms, perceived quality dropped. Above 300ms, it was very low.

Then in 2022, Google's Chrome team published the threshold reasoning for Core Web Vitals. From their documentation:

Research is reasonably consistent in concluding that delays in visual feedback of up to around 100 ms are perceived as being caused by an associated source, such as a user input. This suggests that an ideal Interaction to Next Paint "good" threshold would be close to this.

They wanted 100ms. They settled on 200ms because CrUX field data showed 100ms was unachievable on lower-end mobile devices. Only 12% of mobile origins met it. At 200ms, 56% did. The threshold had to be reachable to be useful.

500ms became the "poor" threshold for the same reason. The research said 300ms. The achievability data said 500ms.

Why this matters

The INP score is not a synthetic Google metric. It is a measurement of whether your users still believe their finger is connected to your interface. The same perceptual machinery Michotte was probing in 1946 with two squares on a screen is running every time someone taps a button on your site.

Tap. Wait. If the screen responds in under 100ms, the brain stitches the two events together. The tap caused the response. Above 200ms, they feel like separate things. The user wonders if the tap registered. They tap again. They lose trust in the interface.

The thresholds Google chose are a compromise between what the brain wants and what mobile hardware can deliver. The lower bound is the perceptual limit. The upper bound is the limit of what feels broken.

Optimising INP is not about hitting a Google number. It is about staying inside the window where the human visual system still treats your interface as a causal agent.