Core Web Vitals: How to optimize “Interaction to Next Paint” (INP)

Interaction to Next Paint (INP), one of Google's Core Web Vitals, evaluates the overall responsiveness of a web page by quantifying how long a user needs to wait for visual feedback after interacting with it by clicking a button, typing into a form field, or tapping the screen on a mobile device.

Optimizing INP on your key pages (such as the home, About, and Contact pages) and page types (such as blog posts, single product pages, and landing pages) is an essential task in modern web development and search engine optimization (SEO).

This is because, first, Core Web Vitals are part of Google’s Page Experience Report, which means that your aggregated Interaction to Next Paint scores affect your rankings on SERPs (search engine results pages).

Second, since INP is a key aspect of user experience (UX), optimizing it will likely reduce bounce rates and increase conversion rates on your website, as your pages will respond to user interactions faster and more intuitively. This is especially important if you have a highly interactive website or application, such as a single page app (SPA) or eCommerce site.

More on the subject

There’s a lot to learn where Core Web Vitals are concerned. Let us give you a hand ✋

What is Interaction to Next Paint?

Interaction to Next Paint is an industry-standard user experience metric that estimates the real-world interactivity of a web page throughout its lifecycle.

It reports the 98^th percentile of interaction response times on the page. INP captures the worst user experience while filtering out anomalies by excluding the slowest 2% of interactions. In practice, the 98^th percentile means the slowest interaction on most pages, except very busy or interactive ones that process at least 50 interactions per user.

Interaction to Next Paint tracks three types of interactions: clicking, tapping, and key pressing, but excludes hovering and scrolling.

INP is a time value measured in milliseconds. It consists of three components:

Blocking time, during which ongoing processes on the main thread prevent the browser from responding to the user action. Part of this is input delay, which extends from when a user interacts with the page until the browser is able to start processing that interaction. If the main thread is idle, the input delay is minimal; if it’s busy, it lasts until the main thread becomes available.
Processing time, during which the browser executes the event handlers attached to the interaction.
Presentation time, during which the browser renders and paints the visual updates to the page.

The break-up of the Interaction to Next Paint metric, diagram — *Image: INP breakdown from the official documentation*

For a good INP result, the page must provide visual feedback to the user for the slowest interaction(the top 2% excluded) within 200 milliseconds. INP scores are measured for mobile and desktop devices separately: the mobile score affects your rankings in Google’s mobile search while the desktop score impacts your results in Google’s desktop search.

Results are classified on a traffic-light scale where:

Green 🟩 refers to a good INP score (200 milliseconds or less).
Yellow 🟨 means that INP needs improvement (between 200 and 500 milliseconds).
Red 🟥 refers to a poor INP score (500 milliseconds or more).

Interaction to Next Paint, passing and failing thresholds

It’s important to note that while the INP metric reports the 98^th percentile for an individual visit, Google evaluates your site's aggregated INP score at the 75^th percentile of all individual INP scores collected from real users of the Chrome browser over the last 28-day period. In practice, this means that a page will earn a "good" rating for INP in Google’s search engine algorithm if at least 75% of individual page visits to that page have an INP of 200 milliseconds or less.

If no interaction happens on the page, Chrome won't report any INP data for that user.

How to Check Your INP Scores

As Interaction to Next Paint is a field value (measured on real user visits), you won’t find the metric in the Lighthouse report, which is the go-to web performance analysis tool for many developers, available from Chrome DevTools. This is because Lighthouse runs the tests in a simulated environment (i.e., your browsing environment), so it can only show metrics that are observable under lab conditions, such as Largest Contentful Paint (LCP).

While the official INP documentation says that, in theory, INP can be measured in the lab, in practice, simulated INP scores are usually not the most accurate since it’s almost impossible to imitate the unpredictability and high variability of real user interactions in a lab environment.

To see your mobile and desktop INP scores that Google uses in its search engine algorithm, you can use one of the following tools (all get the data from the Chrome User Experience (CrUX) Report that Google collects from real Chrome browser users):

GSC (Google Search Console) – You can see grouped Core Web Vitals data for your own domains, together with some recommendations.
PSI (PageSpeed Insights) – You can run a PSI report on any web page. The results page shows field data from the CrUX Report at the top of the report(this is where you can see the INP scores) and lab data from a Lighthouse test(that PSI runs in the background) at the bottom of the report.
CrUX Dashboard – You can use the default CrUX Dashboard (doesn’t require any configuration) or build a custom one on Looker Studio to see the INP (or any other Web Vital) results of any web page.

In the screenshot below, you can see how the aggregated INP score of Envato Elements’ desktop homepage appears in PageSpeed Insights:

Interaction to Next Pain example in PageSpeed Insights

8 best practices to optimize Interaction to Next Paint

Now, let’s see some actionable best practices that can help you improve Interaction to Next Paint on your website.

1. Reduce unused CSS and JavaScript

When a user interacts with your page, the browser often needs to finish processing pending tasks on the main thread before it can respond to that interaction. If there’s unused CSS or JavaScript on the page, it creates unnecessary work for the main thread, which increases the blocking time component of INP.

To detect unused code on the page, you can use the Coverage tab of Chrome DevTools (accessible from the More tools option of the three-dots menu), which shows the ratio of used and unused bytes in each of your CSS and JavaScript files.

If you click a URL in the Coverage tab, Chrome DevTools opens the file in the Sources tab and highlights unused code in red so that you can identify which parts you can remove or refactor:

Coverage tab in Chrome DevTools showing unused CSS and JavaScript

While you can’t remove all unused code (e.g., if it belongs to a third-party resource, it’s used in another part of your site, or it would take too much work to remove), the overall goal is to reduce it as much as possible.

You can also use a module bundler, such as Webpack, Parcel, or Rollup, to implement code splitting so you can only load the code needed for the current page. Minifying and compressing your code files can further reduce parsing and execution time and main thread work.

2. Reduce the DOM size

A large DOM (Document Object Model) tree impacts all three components of INP in the following ways:

Blocking time: The browser has more work to do before it can start responding to user actions.
Processing time: The browser needs more time to run the callback when there are many HTML elements on the page (e.g., if your event handlers query the DOM using a method such as querySelectorAll()).
Presentation time: It takes more time for the browser to re-paint the screen after an interaction because there are more elements to style and display.

You can improve Interaction to Next Paint by reducing the length and depth of the DOM tree by:

avoiding excessive nesting of HTML elements
using CSS techniques, such as pseudo-elements, for styling instead of adding a new HTML element
removing hidden elements that aren’t used (e.g., deprecated features that were hidden rather than removed, testing code, unused template fragments, etc.)
breaking up long pages into shorter pages
…etc.

3. Avoid rendering HTML in JavaScript

If your page uses JavaScript to create and display content to the screen, interactions become slower than when the browser only needs to process and render static HTML. This is because the browser must run the JavaScript code to generate the DOM (which is otherwise directly defined in the HTML).

If you have a static website or use a content management system such as WordPress, you don’t need to worry about rendering HTML in JavaScript, as most (or frequently all) of your HTML is generated on the server, and the browser receives it as a ready-to-use document.

However, if you have an interactive JavaScript application (e.g., an SPA created with a UI framework such as React, Vue, or Angular), consider using server-side rendering (SSR) rather than processing client-side JavaScript in the browser to generate all HTML on the fly.

Plus, if there are complex JavaScript interactions in your SPA, break them up into smaller steps and provide visual feedback at each stage instead of rebuilding large sections at once in response to user interaction.

4. Analyze Common User Interactions

To optimize Interaction to Next Paint on your website, you need to understand the most common interactions your users typically perform on your key pages — which are different from website to website. In other words, you need to follow the Know Thy Website principle, derived from the ancient Greek maxim.

You can do so by using the Performance tab in Chrome DevTools that Google specifically created to help developers catch web performance issues and analyze Web Vitals, such as Interaction to Next Paint.

First, think about the three types of interactions INP records: clicking, tapping, and key pressing, and create some user flows that typically occur on your key pages or page types (e.g., filling out forms, using navigation, typing into the search bar, etc.) either mentally or by writing them down.

Then:

Open the page you want to analyze in the Google Chrome browser in Incognito mode (which deactivates your browser extensions).
Open Chrome DevTools by pressing the F12 key or right-clicking the page and selecting the Inspect option.
Navigate to the Performance panel.
Click the Record or Record and reload icon at the top of the panel to start recording.
Start to interact with the page by performing some common user actions.
Stop the recording when you performed all the actions you wanted.

For example, the screenshot below shows the recording of a common user flow I carried out on Envato Elements’ homepage — I typed “wordpress templates” into the search bar at the top of the page, then used the up and down keys to navigate through the dynamically loaded results in the dropdown of the search bar:

Performance tab in Chrome DevTools, with the Presentation delay component highlighted

As you can see above, the Performance tab shows the three phases of INP. When I clicked the longest component (i.e., Presentation delay), DevTools highlighted it in the Main section (which represents the main thread) and displayed a super useful call tree and event log that allowed me to analyze which events and calls caused the presentation delay.

After recording a couple of common user flows, you can create a list of the key issues that increase Interaction to Next Paint on your website.

5. Break up long-running scripts

Once you’ve analyzed common user interactions in the Performance tab of Chrome DevTools, focus on fixing the ones that took the most time to finish, as these are the interactions that have the most significant impact on your INP scores.

Optimize these long-running scripts by using one or more of the following techniques:

Look into the call tree in the Performance tab to see which functions are responsible for the long delay.
Check if there are any code redundancies (e.g., unnecessary style calculations, repeated DOM queries, inefficient event listeners, duplicate calculations or data processing, etc.) and remove them.
Chunk long-running processes by using techniques such as the setTimeout() method with small delays or breaking tasks into smaller pieces with async/await functions.
Move CPU-intensive tasks off the main thread by using Web Workers.

6. Make your scripts asynchronous

To optimize Interaction to Next Paint, avoid using synchronous JavaScript wherever possible, as it executes immediately and thus blocks the main thread when users are trying to interact with the page.

Avoid using functions such as alert(), confirm(), and prompt() that stop all JavaScript execution, along with synchronous AJAX requests (which are strongly discouraged in modern web development anyway).

You can also make JavaScript files non-render-blocking by adding the defer or async attribute to the <script> tag:

Use async for scripts that don’t depend on other scripts (e.g., third-party analytics or tracking scripts), so they can load in parallel with the creation of the DOM tree. Note, however, that async scripts execute as soon as they're downloaded, which can interrupt HTML parsing. On the other hand, they can execute before the entire page is parsed, which can be useful for certain tasks such as marketing tracking or frontend performance monitoring.
Use defer for scripts that depend on the DOM or need to run in a specific order, as deferred scripts execute after the browser parses the HTML and creates the DOM tree (but still before the DOMContentLoaded event).

<!-- Load scripts asynchronously -->
<script async src="analytics.js"></script>

<!-- Load scripts after HTML parsing but before DOMContentLoaded -->
<script defer src="app.js"></script>

Note that async and defer scripts still execute on the main thread, similar to synchronous scripts. They improve Interaction to Next Paint by not blocking rendering during download and by executing at more optimal times during page loading.

7. Minimize the impact of third-party scripts

To reduce Interaction to Next Paint on your website, review your third-party scripts and consider removing the ones you don't need that much. Or, you can replace them with more lightweight alternatives.

If you still have third-party scripts on the page, consider self-hosting the critical ones so they can be loaded faster, as the browser doesn’t have to establish a connection to an external server.

You can also preconnect to third-party servers that host your critical scripts using the preconnect resource hint in the following way:

1	<head>
2	<link rel="preconnect" href="https://stackpath.bootstrapcdn.com">
3	</head>

You need to add preconnect to the <head> section of the HTML document. It speeds up the download of resources from a third-party domain by performing the DNS lookup and establishing the TCP/TLS or QUIC connection before the browser would do so by default.

For heavy third-party widgets, you can also consider using a facade — a lightweight placeholder that you load initially and replace with the full widget only when necessary. Open-source facades exist for popular widgets and embeds, such as this Lite YouTube embed by Paul Irish.

8. Avoid layout thrashing

Layout thrashing (a.k.a. forced reflows) happens when you repeatedly read and modify the DOM, which forces the browser to recalculate the layout multiple times, which directly increases the processing and presentation time components of INP.

When writing JavaScript, avoid using properties and methods that force layout recalculation, such as offsetHeight, offsetWidth, offsetTop, getBoundingClientRect(), getComputedStyle(), etc. For a comprehensive list of JavaScript properties and methods that can cause layout thrashing, check out this list on GitHub.

Here’s a very simple example of layout thrashing:

/* Layout thrashing */
const elementWidth = element.offsetWidth; // Read
element.style.width = elementWidth + 20 + "px"; // Write

const elementHeight = element.offsetHeight; // Read (forces reflow)
element.style.height = elementHeight + 20 + "px"; // Write

You can prevent layout thrashing by batching your read and write operations in the following way:

/* Layout batching */
const elementWidth = element.offsetWidth; // Read
const elementHeight = element.offsetHeight; // Read

element.style.width = elementWidth + 20 + "px"; // Write
element.style.height = elementHeight + 20 + "px"; // Write

The Performance panel in Chrome DevTools can help you identify layout thrashing.

If layout thrashing is happening on a page, the Performance panel shows the function calls that caused the forced reflows in the Forced reflows tab:

An example of layout thrashing in the Performance panel of Chrome DevTools

You can avoid layout thrashing by using a library such as FastDOM, which automatically batches read and write operations (the screenshot above was created using FastDOM’s testing page for animations).

Wrapping Up

There are many code optimization techniques that can help you improve Interaction to Next Paint on your site. To make your pages snappy and responsive to user action, remove unused first-party and third-party code, find your specific issues by recording typical user flows in Chrome DevTools, and use JavaScript best practices such as reducing main thread work, minimizing DOM manipulations, making scripts asynchronous, and others.

Since INP optimization isn't a one-time task but an ongoing process, consider integrating it into your everyday development workflow.

Start by identifying your slowest interactions, implement the best practices discussed in this post, and test your key pages regularly to see the improvements and prevent performance degradation.

Using the right techniques, even complex, interaction-heavy websites and single page applications can achieve good INP scores on both desktop and mobile devices.