Interaction to Next Paint, or INP, is a Core Web Vitals metric that measures how quickly a page responds to user interactions like clicks, taps, and key presses. It records the worst interaction latency across a visit. A good INP is 200 milliseconds or less; anything over 500 milliseconds is rated poor.
INP replaced First Input Delay as a Core Web Vitals metric in March 2024. The shift matters because First Input Delay only measured the delay before the first interaction started processing. INP measures the full responsiveness of every interaction, from the moment a user acts to the moment the screen visibly updates.
This guide explains exactly what INP measures, what counts as good, why pages fail it, and how to fix it, with specific attention to how the metric behaves on Framer-built sites.
Key takeaways
- INP measures the latency of user interactions and reports the worst one during a page visit.
- The thresholds are 200 milliseconds or less for good, 200 to 500 milliseconds for needs improvement, and over 500 milliseconds for poor.
- The biggest cause of poor INP is long JavaScript tasks that block the main thread when a user interacts.
- INP became an official Core Web Vitals metric in March 2024, replacing First Input Delay.
- Framer sites tend to perform well on INP because of code splitting and optimized runtime, but heavy third-party scripts can still hurt the score.
What INP Actually Measures
INP measures interaction latency, which is the time from when a user starts an interaction to when the browser paints the next frame that reflects a visible response. Every click, tap, and keyboard input is an interaction, and each one has a measured latency.
An interaction’s latency breaks into three parts: input delay, processing time, and presentation delay. Input delay is the wait before event handlers can run, usually because the main thread is busy. Processing time is how long the event handlers themselves take. Presentation delay is the time to render and paint the resulting visual change.
Why the worst interaction is reported
Rather than averaging, INP reports close to the worst interaction on the page, because a single slow response is what users actually remember and complain about. On pages with many interactions, the metric ignores a small number of extreme outliers, but the principle holds: your slowest meaningful interaction defines your score.
INP Thresholds and How They Compare to Other Vitals
Google publishes clear INP thresholds, measured at the 75th percentile of page loads across both mobile and desktop. The table below shows where each rating sits and how INP fits alongside the other two Core Web Vitals.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| INP (Interaction to Next Paint) | Responsiveness to interactions | 200 ms or less | Over 500 ms |
| LCP (Largest Contentful Paint) | Loading of the main content | 2.5 s or less | Over 4.0 s |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less | Over 0.25 |
INP sits in the responsiveness slot. Loading speed is measured by Largest Contentful Paint, and the earliest render is tracked by First Contentful Paint. For context on the loading side of the picture, the Largest Contentful Paint guide and the First Contentful Paint guide cover those metrics in full.
Why Pages Fail INP
Poor INP almost always comes down to the main thread being too busy to respond when the user acts. The browser runs JavaScript on a single main thread, and while a long task is running, every interaction waits. The user clicks, and nothing happens until the task finishes.
The common culprits
- Long JavaScript tasks: Any task over 50 milliseconds blocks responsiveness. Large bundles, heavy event handlers, and unoptimized loops are the usual sources.
- Excessive third-party scripts: Analytics, chat widgets, A/B testing tools, and ad scripts all compete for the main thread and frequently run long tasks.
- Heavy event handlers: A click handler that recalculates layout, fetches data synchronously, or updates a large amount of the page in one go pushes processing time up.
- Large rendering work: Updating many DOM elements at once increases presentation delay, especially on mid-range mobile devices.
How to Improve INP
Fixing INP is about giving the main thread room to respond. The work falls into a clear sequence.
- Break up long tasks. Split heavy work into smaller chunks and yield to the main thread between them so the browser can handle interactions. Yielding with a short timeout or a scheduler API lets a pending click run.
- Defer non-urgent work. Move work that does not need to happen immediately out of the interaction’s critical path. Update the visible UI first, then do background processing afterward.
- Audit third-party scripts. Remove any tag you cannot justify, load the rest as late as possible, and prefer scripts that run off the main thread.
- Reduce JavaScript shipped. Smaller bundles mean less parsing and execution. Code splitting sends only the code a page needs.
- Simplify interaction handlers. Keep the synchronous part of an event handler as small as possible, and avoid forcing layout recalculation inside it.
Measuring INP correctly
INP is a field metric, which means it reflects real users. Lab tools like Lighthouse and PageSpeed Insights estimate it, but the authoritative source is field data from the Chrome User Experience Report. Use the web-vitals JavaScript library or PageSpeed Insights field data to see your real INP, and use lab tools to reproduce and debug specific slow interactions.
How Framer Handles INP
Framer-built sites start with structural advantages for INP. The platform ships optimized, code-split JavaScript, so pages download and parse less code than a typical heavy template would. Interactions and animations are tuned to run efficiently, which keeps processing and presentation time low.
That said, no platform makes INP automatic. The most common way a Framer site loses points is by loading too many third-party scripts through custom code embeds. A chat widget, three analytics tools, and a popup script will block the main thread regardless of how well the underlying site is built. The fix is discipline about what you embed.
Practical Framer steps
Inside Framer, audit your site settings and custom code. Open the site settings, review every script in the head and body custom code fields, and remove anything redundant. Where a third-party tool offers an asynchronous or deferred loading option, use it. Keep interactive components lean, and avoid stacking many simultaneous scroll-linked animations on a single view, since they all compete for frame time. The same care that produces a fast, modern build for an AI company website design applies here: a clean, lightweight page responds quickly.
A Realistic INP Improvement Workflow
Treating INP as a one-time fix rarely works, because the metric drifts as a site adds features. A repeatable workflow keeps it under control. Start by pulling field data to confirm there is a real problem, then reproduce the worst interactions in a lab tool, then fix the specific tasks that block them, and finally re-measure in the field after the change has been live long enough to gather fresh data.
Step one: confirm the problem with field data
Open PageSpeed Insights and enter the page URL. If the page has enough traffic, the report shows real-user INP from the Chrome User Experience Report. This number, not the lab estimate, is what Google uses to rate the page. If the field INP is already under 200 milliseconds, your effort is better spent elsewhere. If it is over 200, note which device category, mobile or desktop, is worse, since mobile is usually the bottleneck.
Step two: reproduce the slow interaction
Open the page in Chrome, launch the performance panel in developer tools, and start a recording. Then perform the interactions a real user would: open the menu, click the primary button, submit a form. Stop the recording and look for long tasks, which the panel flags in red. The interaction that produces the longest blocking task is almost always the one dragging your INP down.
Step three: fix the blocking task
Once you know which task is slow, the fix follows from its cause. If a third-party script is responsible, defer or remove it. If your own handler is heavy, split the work and yield to the main thread between chunks so a pending interaction can run. If the rendering update is large, reduce the number of elements changed in a single frame. Make one change at a time so you can attribute the improvement to a specific fix.
Step four: re-measure in the field
Field data updates over a rolling window, so an improvement will not show up instantly. Deploy the fix, then check back over the following weeks as fresh real-user data accumulates. Lab tools can confirm the interaction got faster immediately, but only field data confirms the rating changed for your actual visitors.
How INP Fits Into the Broader Build Decision
INP is one reason teams increasingly favor platforms that ship lean, optimized code by default rather than heavy templates loaded with plugins. Every plugin, page builder add-on, and bolted-on script adds main-thread work, and that work is exactly what INP punishes. A site assembled from a stack of generic components often carries far more JavaScript than its features justify.
This is one of the practical arguments for building on a modern visual platform. When the underlying runtime is efficient and the code is split per page, you start from a strong INP baseline and only have to guard against the scripts you add yourself. Comparing builders on responsiveness is worth doing, and reviews like the Framer AI review and the overview of the Framer AI website builder show how an optimized foundation translates into faster, more responsive pages in practice.
INP and Conversion
Responsiveness affects revenue as much as it affects SEO. A page that hesitates when a user taps a button feels broken, and that feeling costs conversions. The interactions that matter most for INP are often the ones tied directly to revenue: adding to a cart, submitting a form, opening a menu, or clicking a primary call to action.
Because the highest-stakes interactions are usually your conversion points, INP optimization and conversion optimization overlap. A fast, immediate response on a primary button reinforces trust at the exact moment of decision, which is why a well-built call to action should always be paired with a responsive page underneath it.
Frequently Asked Questions
What is a good INP score?
A good INP score is 200 milliseconds or less, measured at the 75th percentile of real user visits. Between 200 and 500 milliseconds is rated as needs improvement, and anything over 500 milliseconds is rated poor. Lower is better, since the metric reflects how quickly the page responds to a user’s actions.
How is INP different from First Input Delay?
First Input Delay only measured the delay before the first interaction on a page began processing. INP measures the full latency of interactions throughout the entire visit, including processing and rendering time, and reports close to the worst one. INP gives a far more complete picture of real responsiveness, which is why it replaced First Input Delay in March 2024.
Do Framer websites have good INP scores?
Framer websites generally perform well on INP because the platform ships code-split, optimized JavaScript and tunes its interactions for efficiency. The main risk to a Framer site’s INP is loading heavy third-party scripts through custom code embeds. Keeping those scripts minimal and deferred preserves the strong baseline the platform provides.
If your current site feels sluggish when visitors interact with it, Framer Websites can rebuild it on a fast, responsive foundation that scores well on Core Web Vitals. Reach out through our contact page to talk through your project.