search

WICG / layout-instability

A proposal for a Layout Instability specification
https://wicg.github.io/layout-instability/
Other
159 stars 27 forks source link

HadRecentInput and Animation Frames: shifts painted together, should be ignored together. #123

Open mmocny opened 2 months ago

mmocny commented 2 months ago

TL;DR: Consider changing to ignoring the "whole animation frame" worth of shifts as a unit, since animation frame visually appear as a single paint for the user.

After an Interaction with the page, the next 500ms is given an exclusion window, such that any reported shifts are marked as has_recent_input: true and will not be added to the CLS score for the page.

However, Layout Instability is a user experience diagnostic as much as it is a performance diagnostic. And Layout isn't actually visually affecting the user until after the next paint (i.e update-the-rendering steps are complete).

The net effect is that, 500ms after an interaction with the page is processed, we switch from treating layout as has_recent_input in the middle of a random animation frame, and, any layout that is forced to compute eagerly within that frame might get ignored, yet any layout that is lazily computed at the end of that frame might get counted towards CLS. This feels inconsistent and not meeting UX expectations (and in a tiny way, potentially even promoting bad practices).

mmocny commented 2 months ago

One counterpoint for consideration:

If you have a single very long animation frame, say one which takes more than 500ms, you might already have a significant problem with responsiveness and already score poorly on INP.

But if the page layout shifts inside the literal same animation frame as an interaction happens, what should we do?

Today we might report the page as having a poor INP and high CLS, even when the shift is a direct and expected, caused immediately by the interaction. While the shift might be quite delayed and potentially a poor experience, it is not likely to be unexpected.

On the other hand, if the long delay means that the user thinks the interaction is broken, and interacts again ("rage clicks"), then you might have compounding problems if the second interaction actually targets a different layout the second time (once the long layout is actually painted).

It's not clear if these types of issues are better reported as just INP or also CLS, and feels potentially subjective.

mmocny commented 1 month ago

One more consideration:

Any layout shifts that happen Before the input arrives, even if they are in the same animation frame, might end up affecting Hit Test targets. Hit Testing itself forces layout, so, interactions are often themselves the cause of mid-animation-frame shifts.

Should ignore all shifts in any animation frame, but still only those that come after the interaction.