Make Uxify one of your go-to sources on Google
Add Uxify on Google
What is Interaction Latency?
Interaction latency is the time between a visitor doing something on your page (a click, a tap, a key press) and the browser painting the next frame that shows a response. The size picker opens. The cart badge ticks from 1 to 2. The letter they typed shows up in the search box. That gap, measured in milliseconds, is the latency.
Google splits every interaction into three parts. Input delay is the wait before the browser even starts handling the click, usually because the main thread is stuck on something else. Processing duration is how long your event handlers take to run. Presentation delay is the time the browser needs to work out the new layout and actually draw it. Add them up and you get the latency for that one interaction.
Here’s how it plays out on a product page. A shopper on a mid-range Android phone taps a color swatch, but a review widget is halfway through a long task, so her tap sits in the queue for 180 ms. Then the swatch handler spends 60 ms swapping images and prices, and drawing the updated gallery takes another 40. Total: 280 ms. To her, the swatch just felt sticky.
Only clicks, taps and key presses count. Scrolling, hovering and zooming aren’t measured as interactions.
What this means for revenue
People don’t experience speed as one number. They feel it in moments, and the moments right after a tap are the ones closest to the money: add to cart, pick a size, apply a discount code, hit “Pay now.” When those lag, the page feels broken even though everything loaded fine, so shoppers tap again, accidentally add two of something, or decide the store seems a bit off and close the tab before checkout. You’ll often see it in your data as rage clicks and other frustration signals.
It also feeds straight into Interaction to Next Paint (INP), the Core Web Vitals metric for responsiveness. INP is roughly the slowest interaction latency in a visit (busy pages get one highest interaction ignored for every 50), reported at the 75th percentile across visits. Google rates INP as good at 200 ms or less and poor above 500 ms. One sluggish mega menu on mobile can sink the score for the whole template.
Usually it’s a handful of interactions and a handful of scripts doing the damage. Find those and most of the problem goes with them.
How Uxify helps
Reality measures INP from real visitors on every pageview, broken down by page and device, so you can see where taps are actually slow instead of guessing from a lab test. Ask Uxi can dig into the INP breakdown with you and suggest where to start. INProve cuts latency directly: it frees up the main thread right before an interaction and reschedules heavy scripts, so the click gets handled first, with no code changes. And Vita watches your Core Web Vitals and flags regressions, which is handy after a theme update or a new app install.
Interaction Latency FAQs
What’s the difference between interaction latency and INP?
One is a single measurement, the other is a summary. INP is a page-level score built from every interaction latency in a visit: the browser times each click, tap and key press and reports (roughly) the slowest. So a page can feel quick almost all the time and still have a poor INP if one interaction consistently drags.
What’s a good interaction latency?
Keep every interaction at or under 200 ms, since that’s where a good INP starts. Past 500 ms you’re in poor territory.
How do I measure interaction latency?
For debugging, record yourself clicking around in the Performance panel of Chrome DevTools, which shows each interaction and how long it took. Just remember your laptop is faster than your customers’ phones (more on that in lab data vs. field data). For real visitors, browsers report it through the Event Timing API, which Safari picked up in version 26.2. Uxify also maintains an open-source polyfill for browsers that don’t report interaction delays natively, and Reality collects all of it for you.
How do I reduce interaction latency?
Start by finding which of the three parts is biggest, because each has a different fix. A long input delay usually means other JavaScript is hogging the main thread, so break it up, defer it or drop it. Slow processing means your own handlers try to do everything at once; show the visual change first and push the rest to later. A big presentation delay points to a huge DOM or expensive layout work. Our INP optimization guide goes deeper, and for third-party scripts you can’t touch, INProve handles the rescheduling.