INP stands for Interaction to Next Paint. It measures the time between a user interaction, like a click, and when something happens on the page, such as rendering or painting. A shorter INP means a faster and more responsive site.
Late last year I found out that the INP value for Brush Ninja was over 200ms. This was bad news because Google considers anything over 200ms as poor performance. I needed to fix this to improve the user experience and maintain my site’s search ranking.
The Issue with Brush Ninja
Brush Ninja is a collection of JavaScript apps that run in the web browser. Given this setup, having issues with Google’s INP was almost expected. Late last year, I noticed a report in Google Search Console mentioning that my INP time was longer than 200ms. To put this into perspective:
- Less than 200ms: Performant
- Between 200ms and 500ms: Poor
- More than 500ms: Bad
Unfortunately, INP scores are assigned to groups of pages rather than individual ones, making it tricky to pinpoint the exact cause of delays.
Finding the Culprit
Unlike a lot of website metrics such as file size or page load time, INP is harder to track. It needs real user interactions to measure (referred to as RUM - Real User Monitoring), which can be challenging to measure.
Google offers a free script called web-vitals.js that tracks various performance metrics and stores data in Google Analytics. However, it doesn’t specify which event causes slowdowns and the data is hard to read.
I spent countless hours optimizing interactions on the Brush Ninja animation maker to make things faster for users. While this was beneficial overall, it didn’t solve the INP issue. Then I discovered a Web Vitals Chrome Extension by Google that logs different speeds when metrics perform poorly. By turning on console logs and clicking around my site, I could locate the flaws.
The Solution
For Brush Ninja, I suspected the animation maker was causing problems. Even with the extension’s help, finding the culprit took some time. Eventually, I realized that using a confirm dialog paused interactions. Although the confirm box appears instantly, it doesn’t trigger a paint until you click it. If you take 5 seconds to respond, that’s counted as a 5-second delay!
To fix this, I replaced the confirm box with a JavaScript modal. Now, I’ve submitted a fix and am waiting for about 28 days for Google to test the site and update the stored metrics. Fingers crossed this is it!
Fixing my website’s INP issue wasn’t easy but understanding what causes delays helped me address them effectively. If you’re facing similar problems, try using tools like web-vitals.js and Google’s Chrome Extension to diagnose performance issues.
Was it good/ useful/ a load of old rubbish? Let me know on Mastodon, or BlueSky (or Twitter X if you must).
Link to this page
Thanks for reading. I'd really appreciate it if you'd link to this page if you mention it in your newsletter or on your blog.