Tweaks INP doc intro copy.

[malchata]

Changes proposed in this pull request:

• @tunetheweb had a great point that the initial language in the INP doc does not focus on the fact that the INP metric's intent is to assess how long interactions may block the next paint. This PR tweaks the INP doc intro to reflect this.

cc: @mmocny @anniesullie

[netlify]

✅ Deploy Preview for web-dev-staging ready!

Name	Link
🔨 Latest commit	b6196b6
🔍 Latest deploy log	https://app.netlify.com/sites/web-dev-staging/deploys/6329bfbbac0a03000862a00a
😎 Deploy Preview	https://deploy-preview-8686--web-dev-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[anniesullie]

Change looks good to me!

[mmocny]

Looks good to me!

[verlok]

Good tweak, but the fact that it’s still talking about “visual feedback”, while there might not be any visual feedback at all, is still confusing me and others.

I might want to try proof reading and opening a PR if I find a simpler way to say it’s just about computation in the main thread, and the paint is only potential.

[malchata]

Definitely want to help as much as I can to alleviate any confusion. This is a tough metric, and I think we want to focus on the idea that while an interaction that may not produce a visual update may log an entry in the event timing API that counts towards INP, we want to encourage developers to present visual feedback for interactions to promote good responsiveness.

Adding @mmocny to this thread to get his thoughts on the current phrasing that @tunetheweb has proposed here.

[mmocny]

I'm not sure I have a perfect answer on how to word this in a way that is most intuitive.

Here is how it actually works in Chromium:

• We measure until the end of all js processing work for any user input.
• If there is no known visual update to the page, and so if there is no known rendering opportunity coming up, we consider the interaction to be completed and mark duration there.
• Otherwise, we continue to wait for the next rendering opportunity.
• Then, if that rendering opportunity actually ends up with some visual update, wait for presentation that animation frame.

(We're also continually improving on each of these e.g. "no known rendering opportunity coming up" is complicated).

So in that sense, yes it's true that we may or may not actually measure all the way to "visual feedback".

But another way to consider that scenario is that sometimes the Next Paint of that Interaction is visually the same as the current Paint, and so the update is simply instantaneous.

In other words-- "Next Paint" doesn't mean "Next time you happen to Paint" but rather "The paint you ask for is shown to user".

I also wouldn't say that we explicitly promote visual feedback for everything-- that of course depends on a lot of factors. But if anything on the page does decide to provide visual feedback -- and many interactive DOM Elements do by default -- you should make sure it actually appears within a reasonably latency! Its surprisingly common for a visual update to be applied, but then prevented from actually rendering somehow.

[anniesullie]

For the previous set of responsiveness blog posts, we had some similar issues where we had some deep details which are interesting and important to a small set of people. We used a box (an <aside> maybe? a <details>?) that was collapsed by default but people really interested in the topic could expand it if they want. Maybe something like that would help here?

[tunetheweb]

We measure until the end of all js processing work for any user input.

I think that's easily read as including any async callbacks.

In other words-- "Next Paint" doesn't mean "Next time you happen to Paint" but rather "The paint you ask for is shown to user".

This confuses me. I understood it as "the next opportunity you can paint".

I also wouldn't say that we explicitly promote visual feedback for everything-- that of course depends on a lot of factors.

While there's always counter examples, I think in most cases an interaction should ideally have some sort of paint happen ing. Either the completed paint ("Item has been added to basket!"), or a holding paint ("Adding item to basket..."). Of course we can't guarantee developers do that, so understand why INP doesn't really measure that (hence why I see it as "Interaction until next ability to paint is complete"), but I think if we're giving guidance it should be along the lines of "it is important to give quick feedback for an interaction, especially for variable or longer-running interactions that may depend on external factors like network calls." Or something pithier!

I'm biased of course, but think my Twitter thread, which I posted as a result of the issues @verlok raised is a good way of describing it. Even if I got a couple of bits of terminology wrong cause I didn't run it by you all first :-)

[mmocny]

I think that's easily read as including any async callbacks.

Fair enough, I was being lazy. It should of course refer to processing of just the event handlers, rather than actually "all work".

(Though even that isn't quite perfect, because we wait until all event handlers dispatch, which can go beyond just typical microtask boundaries, and we'll wait for requestAnimationFrame callbacks, even if there ends up no visual update in them, etc.)

This confuses me. I understood it as "the next opportunity you can paint".

I think this is roughly the right mental model as per the goal of the metric, but unfortunately:

1. the way rendering is implemented means you cannot necessarily know the next "potential" rendering opportunity unless you actually schedule one. We try not to schedule rendering work unless there's reason to. Asking to schedule a rendering opportunity that is otherwise not needed just to know it was possible may have performance implications (or not, but we don't try to do it today).
2. even if we could, it's not clear to me that it is worth measuring that time if there ends up not being a visual update. Say there is some issue with rendering pipeline such that the next rendering opportunity is a bit delayed-- but there is no update anyway-- did it matter to the user?

an interaction should ideally have some sort of paint happening

Agreed, but remember that we measure all parts of the interaction: DOWN, UP, Synthetic event, etc. And there are many many other event types reported to Event Timing that aren't necessarily considered interactions.

Must all of those parts necessarily have visual feedback?

E.g. Buttons do update look when pressed DOWN and then do bounce UP but don't update when click fires.
E.g. Clicking an Image to zoom in maybe only provides a visual update when pointer is released.

I think if we're giving guidance it should be along the lines of

I like those suggestions.

[tunetheweb]

Must all of those parts necessarily have visual feedback?

Nope. This again me as a user being hand-wavy with my definition of "interaction" compared to you, with actual real detailed knowledge, pointing out why life is a bit more complicated than a high level view suggests ;-)

And it's also not a "must" that every interaction (again, in the high-level sense, rather than each component part like DOWN, UP...etc.) has a visual feedback, but in general it's a good idea that most do.

[rachelandrew]

For the previous set of responsiveness blog posts, we had some similar issues where we had some deep details which are interesting and important to a small set of people. We used a box (an

maybe? a

?) that was collapsed by default but people really interested in the topic could expand it if they want. Maybe something like that would help here?

Just as a drive by comment, I keep seeing situations where readers have obviously completely missed the content of those collapsed boxes. I don't think they are a great solution inside content because of this. I'd generally prefer just using the aside component to indicate that it is extra info, but keep it visible on the page.