Everything You Need To Know

The SEO field has no shortage of acronyms.

From SEO, to FID, to FCP (First Contentful Paint), to INP – these are some of the more common acronyms you will run into when it comes to page speed.

Google is currently in the process of changing Core Web Vitals.

It has added two new metrics to the mix: INP (Interaction To Next Paint) and TTFB (Time to First Byte).

INP refers to how the page responds to specific user interactions that are programmed into the overall INP metric measured by Google Chrome’s lab data and field data.

TTFB measures the length of time that it takes for the first byte to be transferred by the server.

TTFB has long been suspected as a driver of significant performance gains, which means that it’s a priority that SEO professionals should be optimizing as part of their SEO process.

Google only recently decided to implement TTFB as a new metric so that SEO pros can measure how their site performs at the server level.

For the purposes of this discussion, we will be sticking with INP this round.

What, Exactly, Is INP?

INP is a new Core Web Vitals metric designed to provide a representation of the overall interaction delay of a page.

It does this by working from a sample of the single longest interactions that happen when a user visits the page.

If a page has less than 50 total interactions, INP takes into consideration the interaction that has the absolute worst delay.

The measurement of INP is a representation of how long a user has to take in order to interact with the entire page.

This is a direct contrast to FID (First Input Delay).

FID simply measures only the first response of interaction by a particular user.

Here on SEJ, we reported that PageSpeed Insights added this new speed metric to the Google Lighthouse Chrome extension.

The Mechanics Of INP

JavaScript is typically the primary signal of any interaction made on a page.

Other types of interactivity do exist, including radio buttons, check boxes, the HTML <details> element, and several others.

INP, however, is concerned with the following types of interactions:

• Any mouse click of an interactive element.
• Any tap of an interactive element on any device that includes a touchscreen.
• The press of a key on a physical or onscreen keyboard.

There is more than one event that could be considered an interaction.

Keydown and keyup, for example, are both parts of a keystroke.

Any tap interaction could also include pointerup and pointerdown events.

These are all considered “logical user interactions.”

What Are The Parts Of INP?

Each interaction has a few phases: presentation time, processing time, and input delay.

The callback of associated events contains the total time involved for all three phases to execute.

The longest duration of a logical user interaction is what will be recorded.

What Is A Good INP Value?

Google’s web.dev documentation explains that a good INP value is around 200 milliseconds or less.

It says the following:

An INP below or at 200 milliseconds means that your page has good responsiveness.

An INP above 200 milliseconds and below or at 500 milliseconds means that your page’s responsiveness needs improvement.

An INP above 500 milliseconds means that your page has poor responsiveness.

Advertisement

Google also notes that INP is still experimental and that the guidance it recommends regarding this metric is likely to change.

How Is INP Different From First Input Delay?

The main difference between INP and FID is that FID considers only the first interaction on the page.

INP takes into consideration all page interactions.

FID measures the input delay metric only and doesn’t consider event handlers, and how long they take to process.

It also does not consider any delays in presenting the next frame of the interaction.

How To Identify INP Issues On Your Website

In order to find INP issues on a website, we must first consider the differences between lab data and field data.

The only way to find realistic data on what your users are experiencing is to utilize data from the field.

Lab tools are items that are not going to fully interact with the page, and thus usually need manual input while measuring tasks are being performed.

Otherwise, using an automation tool such as Puppeteer can help you script manual interactions as they occur while you are utilizing lab tools for testing purposes.

About Lab Data

In the context of this kind of testing, lab data is a metric that’s determined through controlling page load using a predefined set of conditions, usually tailored to device and network.

Because these conditions are in a controlled environment, they are known as a lab environment, and this is where the term “lab data” comes from.

About Field Data

Field data, also known as RUM (Real User Monitoring) data, is obtained by monitoring users on a page.

It measures the performance metrics of individual performances, often providing insight into these certain performance metrics.

Field data is based on real user visits – so this is something where your website may be represented on actual devices, user geographic locations, as well as network conditions of that device.

Putting It All Together

What’s the big deal about FID, INP, field data, and lab data anyway?

Well, field data is provided in Chrome tools that report data on Core Web vVtals.

You can obtain field data from the CrUX Report (or Chrome User Experience Report).

But, the CrUX report is only part of the picture.

This is why it’s important to collect field data on your own.

Using CrUX by itself cannot provide enough actionable insights to make a real difference in your site’s performance.

Google explains that the most important insight about field data is that it’s not just one number.

It’s actually a distribution of numbers.

This means that for a certain sample of users, it’s possible that your site is going to load very slowly.

For other users, it’s possible your site could load very fast.

In other words: The field data is a total set of collected performance data from all of your users.

How Can You Measure INP?

While measuring INP is most effective when using combined lab and field data, there are some “easiest” ways to measure this Core Web Vitals metric.

You can use the Google Chrome Extension called Lighthouse, which has a timespan mode.

This mode allows you to more easily monitor exactly what is happening during the page load, which can further help you troubleshoot issues with INP.

You can also utilize theses other lab tools to help you collect your data:

How To Improve Your Own INP Values?

The best way to do this is to optimize your main thread work.

This means making sure that things like third-party fonts are kept to a minimum (i.e., using system fonts only), and that you don’t use too many plugins that load on the page load.

For example, say that you have a WordPress site with 15 ad plugins that are dedicated to showing ads on your page – and perhaps you don’t necessarily use all of them.

Turning off 90% of these plugins should help improve your INP, and uncomplicate the main thread work – because this is delaying the page load.

Some INP issues arise because people do not optimize their main thread work enough to make sure that things are properly viable from a Core Web Vitals perspective.

Others can be caused by JavaScript files misfirings, and a lack of attention to how things load on the page – especially with larger images.

These are just some, but not all, of the factors that should be optimized for better, more effective INP numbers.

As well as better overall Core Web Vitals numbers.

Improving Your INP Is Not A Silver Bullet

It’s important to note that improving your INP is not a silver bullet that is guaranteed to deliver instant SEO success.

Instead, it is but one item among many that may need to be completed as part of a batch of quality changes that can help make a difference in your overall SEO performance.

How do you plan on implementing repairing INP in your overall SEO strategy?

More resources:

Featured Image: BestForBest/Shutterstock