Interaction to Next Paint (INP) എന്നത് ഒരു വെബ്സൈറ്റിന്റെ പ്രതികരണശേഷി അളക്കുന്ന പുതിയ Core Web Vital ആണ്. മെല്ലെയുള്ള ഫോണുകളിലും നെറ്റ്വർക്കുകളിലും ഇത് എങ്ങനെ പരിഹരിക്കാം എന്ന് ഈ ലേഖനം വിശദീകരിക്കുന്നു.
First Input Delay measured one moment: the gap before the browser could even begin responding to a user's first click. Interaction to Next Paint measures something harder to fake — the responsiveness of every meaningful interaction across the entire visit, reported as the slowest (or near-slowest) one. A site can pass FID comfortably while still feeling sluggish on every tap after the first, which is exactly why INP replaced it as a Core Web Vital. Most Indian sites, tested largely on mid-range Android devices over inconsistent 4G, have never actually profiled this properly, and it shows in the field data.
What INP Actually Measures
INP measures the full duration of an interaction — click, tap, or key press — from the input itself to the moment the browser paints the next visual update reflecting that interaction. It captures three phases: input delay (time before the event handler even starts, usually because the main thread is busy with something else), processing time (how long your code takes to run in response), and presentation delay (time to actually paint the result). A poor INP score can come from any one of these three, and they require completely different fixes, which is why guessing without profiling wastes time.
Google scores INP as good under 200ms, needs improvement up to 500ms, and poor beyond that, measured at roughly the 75th percentile of real user interactions — meaning a handful of fast clicks on a fast device will not save a page whose typical interaction, on a typical mid-range phone, is genuinely sluggish.
Finding the Actual Culprit Before You Fix Anything
The Chrome DevTools Performance panel, recorded while manually interacting with the page, breaks a slow interaction down into its input delay, processing, and presentation segments directly on the flame chart. Field data in the Chrome User Experience Report and Search Console's Core Web Vitals report show what real users on real devices actually experience, which is frequently much worse than what a fast development machine shows. The combination matters: lab tools tell you where the time goes, field data tells you whether it is actually a problem for your real audience.
The most common root cause on Indian sites specifically is long JavaScript tasks blocking the main thread at the moment of interaction — third-party scripts (chat widgets, analytics, ad tags) firing heavy work in response to a click, or a large bundle still being parsed and executed when the user's first tap arrives on a mid-range device with meaningfully less CPU headroom than the developer's laptop.
Fixing Input Delay: Get the Main Thread Free
- Break up long tasks. Any JavaScript task running longer than 50ms blocks input processing for the rest of its duration. Splitting large synchronous work into smaller chunks using
scheduler.yield()orsetTimeout-based chunking lets the browser process a pending interaction between chunks instead of after all of them. - Defer non-critical third-party scripts until after the page is interactive, and audit exactly what each one executes on load — a surprising number run expensive setup code immediately regardless of whether the widget is ever used.
- Reduce total JavaScript execution on page load through code splitting, so less competing work is queued when the user's first interaction actually arrives.
Fixing Processing Time: Make Handlers Actually Fast
- Move expensive computation off the main thread into a Web Worker wherever the work does not need direct DOM access — data transformation, sorting large lists, image processing.
- Avoid layout thrashing inside event handlers by batching DOM reads and writes rather than interleaving them, which forces the browser into repeated, expensive synchronous layout recalculation.
- Debounce, but do not over-debounce, high-frequency handlers like scroll or input listeners, since debouncing too aggressively can itself introduce perceptible interaction lag.
Fixing Presentation Delay: Cheaper Paints
- Avoid large DOM updates on interaction where a smaller, targeted update would do — replacing an entire list when only one row changed forces far more rendering work than necessary.
- Use CSS containment (
content-visibility,contain) on complex components so a change in one area does not force the browser to recalculate layout for unrelated parts of the page. - Prefer CSS transitions over JavaScript-driven animation for visual feedback tied to an interaction, since the former can run on the compositor thread without blocking on the main thread's availability.
What Matters Specifically for Mid-Range Devices and Indian Networks
Field INP data for an Indian audience is typically dominated by mid-range Android devices, which have meaningfully less CPU headroom than the flagship phones and development laptops most testing happens on. Test on an actual mid-range device, or use Chrome DevTools' CPU throttling set to at least a 4x slowdown, rather than trusting results from fast hardware. Network conditions matter less directly for INP than for loading metrics, but slow networks compound the problem indirectly: a page still fetching and parsing JavaScript when the user's first tap arrives will show poor INP purely from that competing work, even though the metric is not a network metric itself.
Frequently Asked Questions
What is a good INP score and how is it different from FID?
Google considers INP good under 200 milliseconds, needing improvement up to 500 milliseconds, and poor beyond that. Unlike First Input Delay, which only measured the very first interaction on a page, INP measures responsiveness across the entire session and reports roughly the worst typical interaction, which makes it a much harder metric to pass by accident.
Why does my site have poor INP even though it loads fast?
Load speed and interaction responsiveness are measured by different metrics for a reason: a page can finish loading quickly and still have JavaScript tasks that block the main thread whenever a user actually clicks something, often caused by third-party scripts, heavy event handlers, or large synchronous DOM updates triggered by the interaction itself.
Do third-party scripts like chat widgets and analytics really affect INP that much?
Often significantly, yes. Many third-party scripts execute setup work immediately on load and additional work on user interaction, competing for main thread time exactly when a real user is trying to click something. Auditing what each third-party script actually executes, and deferring anything not immediately necessary, is frequently the single highest-return INP fix on a typical marketing site.
Should I test INP on my development laptop or a real phone?
A real mid-range phone, or CPU-throttled DevTools set to at least 4x slowdown, is essential. Development machines and flagship phones have enough CPU headroom to mask problems that are clearly visible to the mid-range Android devices that make up most of a typical Indian audience, which is also what Google's field data is measuring.
Can I fix INP without a major rewrite?
In most cases yes. Deferring unnecessary third-party scripts, breaking up long JavaScript tasks, and batching DOM updates inside event handlers are all targeted, incremental fixes that do not require restructuring the application, and they typically address the majority of INP problems found in a proper profiling session.