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.
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.
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.
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.
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.
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.
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.