[haburka]

This may be controversial but I think this has the potential to be a brilliant metric because it measures some part of web UX that’s often neglected. It’s time consuming to make every single interaction display some sort of loading message but it really helps make the site feel responsive.

As long as they avoid the pattern of adding a global loading spinner that covers the whole screen. That’s just the worst possible loading screen. I suppose it would still pass this metric.

Also I’m not sure if I totally understand the metric - I think it’s simply when the next frame is rendered post interaction, which should easily be under 200ms unless you’re

1. doing some insane amount of client side computation

2. talking over the network far away from your service or your API call is slow / massive

and both of these are mitigated by having any loading indication so I don’t understand how this metric will be difficult to fix.

[wielebny]

> This may be controversial but I think this has the potential to be a brilliant metric because it measures some part of web UX that’s often neglected.

It also seems to be a metric that is very easily gamed.

If all that matters is instant feedback, then just draw that loader as soon as user clicks add to cart, do not wait for the request to start. It does not matter that it will take X or Y seconds.

[iamakulov]

> It also seems to be a metric that is very easily gamed.

Fun fact: the current JS-specific metric (which is being fazed out) is First Input Delay, and it was explicitly designed to avoid this gaming:

> FID only measures the "delay" in event processing. It does not measure the event processing time itself nor the time it takes the browser to update the UI after running event handlers. While this time does affect the user experience, including it as part of FID would incentivize developers to respond to events asynchronously—which would improve the metric but likely make the experience worse. > - https://web.dev/fid/

I wonder why they decided to reconsider this trade-off when designing INP.

[crazygringo]

But what you're describing as "gaming" is precisely the behavior this is supposed to incentivize.

Of course you should be setting a visual "in progress" state before you send out a request. And yes that's supposed to be instantaneous, not measured in "X or Y seconds". That's the entire point, to acknowledge that the user did something so they know they clicked in the right place, that another app hadn't stolen keyboard focus, etc.

[mdhb]

You will be pleased to know that isn’t actually the case and it’s instead an example of a single metric taken from a larger suite of metrics known collectively as core web vitals which is what is actually used https://web.dev/vitals/

[comex]

You’d need some pretty inefficient code for there to be a delay between the user clicking a button and even starting a request…

But even in that case, instant feedback is probably better for the user. It lets them know the website isn’t broken and they don’t need to click again, and it also makes the experience feel snappier.

[minorninth]

Honestly, displaying a loader as soon as I click add to cart would be an improvement on many sites. I'd welcome it.

A site that genuinely responds quickly is best. But for a slow site, I'd always prefer one that at least gives me instant feedback that I clicked something over one that doesn't.

[modeless]

> when the next frame is rendered post interaction, which should easily be under 200ms unless

Have you used doordash.com? I don't know how they do it, but they manage to exceed 200ms on every single click, easily. And they're not alone.