Interaction to Next Paint - Processing Time

Learn how to find and improve INP issues caused by processing time

Arjen Karel Core Web Vitals Consultant
Arjen Karel

Interaction to Next Paint (INP) issues cause by processing time

In our previous article we talked about the interaction to next paint on how to identify interaction to next paint issues. If you would like to read up on the basics this is a great place to start!

In this article I will focus on 'processing time'. How this affects the Interaction To Next Paint issues and then explain how to minimize  processing time to improve the interaction to next paint.!

INP TIP: processng time can be optimized by immediately running important code that precedes the layout update and scheduling all other code

What is processing time?

inp 3 stage processing time highlighted

Input delay refers to the time it takes for the browser to process the associated event callback after a user interacts with a web page (e.g., clicking a button or pressing a key). While there is always some processing time INP issues occur when the event callbacks take up too much processing time.

Processing time and the INP

The Interaction to Newt Paint (INP) can be broken down into 3 sub-part: 'Input Delay', 'Processing Time' and 'Presentation Delay'

Processing TIme might be 'the thing' when you think about optimizing the Interaction To Next Paint. It is the 'job that needs to be done' before the layout can be updated by the browser.

The importance of processing time

Many developers think about improving the INP in terms of optimizing callback function (optimizing the process time) and they are right. But in terms of importance it processing time is not even the most important part to improve but it still, on average makes up about 40% of the total INP time.

inp distribution input delay highlighted

At CoreDash we collect millions of core web vitals data point each hour. Based on that data the Processing time accounts for 40% of the Interaction to Next Paint. And while that is a lot optimizing the processing time alone will most likely not be enough to fix INP issues

What causes high processing time?

Several factors can contribute to high processing time in your web application:

inp processing time clustered
  1. Unneeded code. Old, unused code or code without immediate relevance to the user interaction, can prolong callback execution time.
  2. Un-optimized code. Inefficient code (usually usually loops or inefficient DOM lookups) can make the event callbacks rum slower then it needs to.
  3. Clustered callbacksMultiple event callbacks scheduled close together create a queue. If a callback triggered by the user interaction gets stuck in this queue, the response appears delayed.
  4. Layout trashing: Frequent DOM manipulations that trigger layout recalculations can strain the browser and lead to performance regressions.

Minimize processing time

inp processing time optimized

To minimize input delay we need to ensure that the browser is not performing a (long) tasks right before the user interacts with a page. We can do this by scheduling taks to a more appropriate time, making sure tasks do not run for a long time or preventing interactions while tasks are running.

  1. Remove unused code. The first thing to do is to ensure there is no code running that is not needed. 
  2. Minimize Callback Execution Time: Use a JavaScript profiler to identify bottlenecks in your code and target those areas for optimization. Consider techniques like memoization, pre-calculation, and caching to avoid redundant computations.
  3. Prioritize critical code and schedule other code: When the callback code has been optimized split the code into code that needs to run immediately and code that can be deferred. Take a look at this real-life example:
    inp processing time clustered callbacks react
    In this example Google Tag Manager and Facebook events callback are executed before the (REACT) code that preceded the layout update. The solution would have been to schedule the GTM callbacks when the browser is idle

/* before :: immediately run code  */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',

/* after :: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
}, { timeout: 1000 });

Practical Implications

Let's get to the most important question: 'What does this all mean for my site'. Let's break it down for WordPress & REACT.


WordPress offers very little control when it comes to scripts. Many scripts are added through plugins. Most of the times those scripts will add 'event listeners' to the page that do not do anything except delay the interaction to next paint (INP)


    I help teams pass the Core Web Vitals:

    lighthouse 100 score

    A slow website is likely to miss out on conversions and revenue. Nearly half of internet searchers don't wait three seconds for a page to load before going to another site. Ask yourself: "Is my site fast enough to convert visitors into customers?"

    Interaction to Next Paint - Processing TimeCore Web Vitals Interaction to Next Paint - Processing Time