Considering not penalize pages with loading modal above?

[Admin, Arealme]

Dear Web Vital team staff:

Here is a suggestion by me, it's from https://github.com/GoogleChrome/web-vitals/issues/170 and I was told to send it to the email address:

Sometimes I HAVE to rearrange the DOM nodes a few seconds later after the user's input.

For instance, using HTML2Canvas to create a local screenshot but with some updates to the DOM nodes (before taking the screenshot), while the updates are affected by some network response after the user's click action.

Here are the steps:

1. A user clicks the submit button.
2. A request is sent to remote, containing some information about the user.
3. The server calculates some results and tells the client to resize some div#result's height from 200px to 500px - Please note that the client doesn't know whether it's 500 or 600 or 700 before having the response.
4. The client renders the div#result with HTML2Canvas.

During the process, it would bring a huge CLS because the time difference between user inputs at No.1 and server result No.3 might be very long (much longer than 500ms). And it's very unfriendly to ask the user to do some action again after No.3

So what I am doing is to put a loading modal on the screen:

However, this doesn't change the CLS penalization.

Is there any way the CLS detection could pardon this situation?

[Kostiantyn Kolesnichenko]

I also second this.

There are situations when the change must come well after the supposed 0.5s after initial user's input. 

And to make it expected by the user, web-site shows a loading spinner the entire time up until the network response is there and it becomes clear what has to be drawn on the screen.

I might suggest CLS should take the presence of "aria-busy" attribute on the page into account? And start counting those 0.5s AFTER the loading indicator has disappeared from the screen.

I understand that this suggestion could be potentially abused, but I just have no better idea for now. Maybe someone has.

четвер, 5 серпня 2021 р. о 07:18:54 UTC+3 Admin, Arealme пише:

[Michal Mocny]

This feedback seems reasonable to me.  I see you filed this issue which was closed, because this should really be a spec issue first.  If you have the time, may I ask you to file an issue there for discussion?

I think some related questions from the past are:

• Animations implemented with layout properties.  These might not look like shifts to users, but can negatively affect performance in other ways.  More performance alternatives tend to exist.
• Layout shifts for obscured, or off-screen content.  Again, these might not look like shifts for users, but can negatively affect performance in other ways.

I think this issue is somewhat unique in that the shift is caused by an interaction, which just happens to take more than 500ms (and apparently a skeleton placeholder UI is not possible), and is also obscured by other content.  These detail might give us unique possibilities for a solution in the future, but are worth discussing in the spec issue tracker.

Thanks for raising this.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/d538c057-ee5f-43b3-95c3-181b299f1a16n%40googlegroups.com.