Make Uxify one of your go-to sources on Google
Add Uxify on Google
What is Input Delay?
Input delay is the time between a visitor clicking, tapping or pressing a key and the browser actually starting to run the code that responds to it. Nothing is broken during that gap. The browser just hasn’t gotten to the tap yet.
It happens because the browser does almost all of its work on one main thread, one job at a time (that’s the event loop). If a long task is running when the shopper taps, the tap waits in line until it finishes, whether that’s a review widget drawing stars or a theme script still booting up.
Picture someone on an older iPhone tapping “Size M” while the product page is still hydrating. The main thread is tied up for another 300 ms, then the size handler runs in a few milliseconds. The code was fast. The wait wasn’t.
It’s the first of the three parts of interaction latency, followed by processing duration and presentation delay.
What this means for revenue
What makes it sneaky is that it usually has nothing to do with the button the shopper pressed. Your add-to-cart handler can be perfectly lean and the tap still feels dead, because something unrelated was hogging the thread. Shoppers can’t see that. They tap again, sometimes end up with two of the same item, and some quietly close the tab, which is how it shows up as rage clicks in your data.
It bites hardest right after load, when scripts are still starting up and eager shoppers are already tapping, and on mid-range Android phones.
It also counts toward Interaction to Next Paint (INP), the Core Web Vitals metric for responsiveness. Google rates INP as good at 200 ms or less, so a tap that sits in the queue for 150 ms has spent most of its budget before your code even starts.
How Uxify helps
Reality measures INP from real visitors on every pageview, split by page and device, so you can see which templates feel sluggish. Ask Uxi can walk through the INP breakdown with you and point out when waiting, not your own handlers, is eating the time. INProve goes after input delay directly: it frees up the main thread right before an interaction and reschedules heavy scripts, so the tap gets handled first, with no code changes.
Input Delay FAQs
What’s a good input delay?
Google doesn’t set a threshold for it on its own. The whole interaction needs to fit inside 200 ms for a good INP, so you want the wait to be a small slice of that, ideally close to zero.
Is input delay the same as First Input Delay (FID)?
Related, but no. FID was the old Core Web Vitals metric for responsiveness, and it only measured input delay on the very first interaction. Google replaced it with INP in March 2024, which looks at every interaction and times the whole thing until the screen updates.
How do I reduce input delay?
Find what’s keeping the main thread busy. Record yourself tapping around in the Performance panel of Chrome DevTools and look for long tasks sitting right before your interactions, usually third-party tags, chat widgets or heavy theme scripts. Break them up, defer them or drop them. Your laptop hides a lot of this, so check field data from real phones too, and see our INP optimization guide for the developer side.