May 24, 2023

Interaction to Next Paint INP as the next Core Web Vital.

Google just announced that Interaction to Next Paint, or INP, will replace First Input Delay in the Core Web Vitals.

Google just announced that Interaction to Next Paint, or INP, will replace First Input Delay in Core Web Vitals. What does this mean for WordPress sites, but also sites in general, and what can you do now to make sure you're ready for the change?

This article will give you an overview of everything you need to know about this all-important new metric.

What is Interaction to Next Paint (INP)?

Interaction to Next Paint, often abbreviated as INP, represents a step forward in the evolution of web performance metrics. It's a relatively new metric that aims to provide a more accurate and useful measurement of the user experience while interacting with a web page.

At its core, INP focuses on the time it takes for the browser to "paint" or render the next frame after a user has interacted with the page. In practical terms, this means that it measures the time between the moment a user, for example, clicks a button and the moment they see a visible change on the screen as a result of that click.

This might seem like a simple measure, but it actually provides a very meaningful indication of user experience. Imagine, for example, clicking a button on a website. You'd expect some kind of instant feedback to confirm that your click had an effect – perhaps the button changes color or a message appears. But if you don't see any visual response, you might start wondering if your click was registered. After a while, you may even start to get frustrated. That's why INP is so important: It measures how long it takes before you see visual feedback after an interaction, which can be a key indicator of the quality of the user experience on your website.

Also, INP is particularly useful because it takes into account the entire lifecycle of the page, not just the first input. This makes it a more representative measure of user experience than some other metrics, reflecting the fact that users interact with a page in different ways and at different times during their visit. Therefore, optimizing for a low INP can help ensure that your website offers a consistent and responsive user experience from start to finish.

How does INP compare to FID?

Interaction to Next Paint, or INP, is a web performance metric that offers a unique and valuable perspective on the user experience when interacting with a web page. At the heart of its calculation, INP takes into account a larger amount of processing time than other metrics when it measures a page's responsiveness after a user interaction. This means that it is able to provide a more accurate and complete representation of how a user experiences an interactivity delay on a website.

Take, for example, a related metric called First Input Delay, or FID. The FID measures the time between the moment a user interacts with a page element (such as clicking a button or link, or touching an element on a touch device) and the moment the browser is able to respond to that interaction. It's a useful measure, but it's limited because it focuses only on the user's first interaction with the page.

The INP goes further. Not only does it measure the time it takes for the browser to respond to a user interaction, but it extends this measurement to include the time it takes for the browser to "paint" or render the next frame after that interaction. This could be, for example, the time it takes to display a visual response to a user's click or tap.

Also, an important advantage of INP over FID is that INP is measured for the entire duration of a user session, not just the first interaction. This means that INP can provide a more complete and accurate overview of the user experience throughout the entire visit to a page, rather than just a single point in time. This is good because it reflects the reality that the user experience on a website is dynamic and can change over time. Therefore, optimizing for a low INP can help improve the user experience as a whole, rather than just a single moment.

IN

IN P

From Google Documentation reachable at https://web.dev/inp/

Chrome usage data shows that 90% of a user's time on a page is spent after it loads, so accurately measuring responsiveness over the page's lifecycle is important. This is what the INP metric evaluates.

INP reports the worst time or so.

Both FID and INP can only be measured with real users. Total Block Time (TBT) is a lab metric you can track when doing individual tests that can correlate with both FID and INP, but only for events that can occur during page load.

What is a good INP value?

Assigning labels like “good” or “poor” to a responsiveness metric is difficult. On the one hand, you want to encourage development practices that prioritize good responsiveness. On the other hand, you have to take into account that there is a lot of variability in the capabilities of the devices people use to set achievable development expectations.

To ensure you're providing responsive user experiences, a good threshold to measure is the 75th percentile of page loads recorded in the field, split between mobile and desktop:

  • An INP below or at 200 milliseconds it means that your page has good responsiveness.
  • An INP above 200 milliseconds and below or 500 milliseconds it means that the responsiveness of your page needs improvement.
  • An INP greater than 500 milliseconds it means that your page has poor responsiveness.

i-values-of-INP_png

What causes poor INP performance?

Running JavaScript that performs long-running tasks on the main thread is the main cause of INP, or Interaction to Next Paint, problems. To better understand, the main thread is the beating heart of browser processing. When executing a JavaScript task, it cannot simultaneously respond to user input. Therefore, if a JavaScript task is particularly long, it can delay the browser's response to user inputs, affecting the site's responsiveness. This can cause INP delays, as INP measures the time it takes for a change to appear on the screen in response to user input.

To complicate matters further, large render updates can also impact INP. When the browser has to process a large rendering update – which could involve large-scale changes in the view of a page – this can take up time and resources, further lengthening the INP time.

When it comes to WordPress sites, these problems are often caused by WordPress plugins or third-party scripts. These can add complexity and additional workload to the main thread, causing INP to increase.

Also, using a JavaScript framework like Vue or React to render your site's UI can contribute to a higher INP. These frameworks are powerful tools for creating rich and dynamic user interfaces, but they can also place a significant load on the browser, especially if used suboptimally.

Finally, another possible culprit is inefficient JavaScript code within the WordPress theme itself. If your theme's JavaScript code hasn't been written or optimized efficiently, it can cause lags and performance issues that can affect your INP. Therefore, it is always a good idea to review and optimize your theme code to ensure the best possible performance.

How do I measure and improve the INP?

As mentioned earlier, INP is just a field metric. This means that it is only measured for users who interact with your site. You cannot run Lighthouse or WebPageTest on page load to test this metric. Instead, we have to look at real user data, as in Chrome User Experience Report, or CrUX.

You can use the free tool TREO site speed to look at CrUX data for your entire domain. You can also run PageSpeed ​​Insights on the most popular pages and sometimes get page-level INP data if that page gets enough traffic.

Debugging and fixing INP will be more difficult than optimizing for Largest Contentful Paint and Cumulative Layout Shift. However, one step you can take now to make that task easier is to clean up your site.

We have worked with several WordPress merchants to optimize their websites. We've also looked at many other as well as analyzing WordPress sites across the web through CrUX and HTTPArchive. One of the most common problems we see is excessive loading of third-party scripts. This often comes from the WordPress plugins that have been installed. Some of these are no longer used, and some of these you may have thought you removed but the code is still there.

How do you find some of the worst offenders?

Identifying those responsible for a high INP (Interaction to Next Paint) may require in-depth analysis of your website's behavior, from JavaScript loading to page execution and rendering. Here are some key steps to follow:

  1. Use browser developer tools: Tools like Chrome's Performance Analyzer can help pinpoint long-running JavaScript activity that could be causing INP issues. This tool provides a detailed processing time plot for every JavaScript activity during a session, allowing you to identify any activity that is taking longer than expected.
  2. Analyze the use of JavaScript: High INP can be caused by heavy or inefficient JavaScript scripts. This could include excessive use of third-party scripts, scripts that require a lot of processing, or scripts that block page rendering. A tool like Lighthouse can provide insight into the use of JavaScript on your site and suggest ways to optimize it.
  3. Monitor main thread activity: High INP can be caused by activities that block the main thread, such as long-running JavaScript processing or large rendering updates. Tools like Lighthouse and Chrome's performance analyzer can provide insight into main thread activity.
  4. Analyze resource usage: High INP can also be caused by ineffective resource usage, such as excessive resource loading or large resource usage. Tools like Lighthouse and PageSpeed ​​Insights can provide a detailed analysis of resource usage and suggest ways to optimize it.
  5. Analyze network usage: A high INP can be caused by network issues, such as high latency or slow loading of resources. Tools like the Network pane of the Chrome developer tools can provide a detailed analysis of network activity and help identify any problems.

INP debugging

Debugging Interaction to Next Paint (INP) is more of a challenge than First Input Delay (FID) because INP affects the entire cycle of user interaction with the site, not just the first input. In other words, while FID focuses on the delay between the user's first input (such as a click or tap) and the browser's response, INP measures the time between a user input and the moment the browser displays the change related to that input. This means that INP takes into account all user interactions during the session, making it a more complex and comprehensive indicator of user experience.

Tackling INP debugging requires a detailed understanding of browser operation and JavaScript performance. Chrome's developer tools, especially the performance analyzer, can provide valuable insight into how INP is performing during a session. These tools can help identify lengthy scripting tasks or large rendering updates that could adversely affect INP.

The Chrome team has released a comprehensive set of documentation to assist in the development and optimization of INP. These articles cover various aspects of the INP metric, including how it is calculated, how it can be monitored and measured, and how it compares to other government metrics. Core Web Vitals. The documentation also provides practical advice on how to optimize INP, how to minimize JavaScript processing time, efficiently manage resources, and optimize browser rendering.

It is important to note that optimizing INP should go hand in hand with optimizing other performance metrics. The goal should be to provide a smooth and responsive user experience, and INP optimization can be a key element in achieving this.

Conclusions

INP which replaces FID in the Core Web Vitals that's great news. It will better center the user experience on responsiveness and interactivity in the metrics. User experience is the key to higher conversions, and this change will also align search engine rankings with that user experience.

Start optimizing for Interaction to Next Paint now. Both to prepare you for the change and to improve the experience of customers who visit your site today. In the coming months, we'll be releasing more learning content to help merchants, theme developers, and app developers in the WordPress ecosystem help with your unique needs.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds owns the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Facebook, Inc. owns the rights to Facebook®; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV This site is not affiliated, sponsored, or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a registered trademark at European level by MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top