All you need to know

0

The field of SEO is not short of acronyms.

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

Google is currently changing Core Web Vitals.

He added two new measures 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 time it takes for the first byte to be transferred by the server.

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

Google only recently decided to implement TTFB as a new metric so that SEO professionals can measure their site’s performance at the server level.

For the purposes of this discussion, we’ll stick to the INP for this round.

What exactly is INP?

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

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

If a page has less than 50 total interactions, INP considers the interaction with the absolute worst lag.

The INP metric is a representation of how long a user must take to interact with the entire page.

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

The FID simply measures only the first interaction response of 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 the INP

JavaScript is usually the primary signal for any interaction performed on a page.

Other types of interactivity exist, including radio buttons, checkboxes, HTML element and many others.

The INP is however interested in the following types of interactions:

  • Any mouse click on an interactive element.
  • Any tap on an interactive element on any device that includes a touchscreen.
  • Pressing a key on a physical or on-screen keyboard.

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

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

Any touch interaction can also include pointerup and pointerdown events.

These are all considered “logical user interactions”.

What are the parts of the INP?

Every interaction has a few phases: presentation time, processing time, and entry delay.

The associated events callback contains the total time required to complete the three phases.

The longest duration of a logical user interaction is the one that will be recorded.

What is a good INP value?

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

He says the following:

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

An INP greater than 200 milliseconds and less than or 500 milliseconds means that your page’s responsiveness needs improvement.

An INP over 500 milliseconds means your page has poor responsiveness.

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

How is INP different from First Entry Delay?

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

INP considers all page interactions.

FID only measures the input delay metric and does not take into account event handlers or their processing time.

It also does not take into account delays in presenting the next image 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 about what your users are experiencing is to use field data.

Lab tools are items that will not fully interact with the page and therefore typically require manual input when performing measurement tasks.

Alternatively, using an automation tool such as Puppeteer can help you script manual interactions as they happen when using lab tools for testing.

About lab data

In this type of testing, lab data is a metric determined by controlling page load using a predefined set of conditions, usually tailored to the device and network.

Because these conditions are in a controlled environment, they are known as the laboratory environment, and this is where the term “laboratory 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 performance metrics of individual performance, often providing insight into these certain performance metrics.

Terrain data is based on real user visits – so it’s something where your website can be represented on real devices, users’ geographic locations, as well as that device’s network conditions.

put it all together

What’s wrong with FID, INP, field data and lab data anyway?

Well, terrain data is provided in Chrome tools that report data to Core Web vVtals.

You can get 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 is important to collect field data yourself.

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

Google explains that the most important information about terrain data is that it is not a single number.

It is actually a distribution of numbers.

This means that for a certain sample of users, your site may load very slowly.

For other users, your site may load very quickly.

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

How can you measure the INP?

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

You can use the Google Chrome extension called Lighthouse, which has a duration mode.

This mode makes it easier for you to monitor what exactly is happening while the page is loading, which can help you troubleshoot issues with INP.

You can also use these 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 things like third-party fonts are kept to a minimum (i.e. only using system fonts) and that you don’t use too many plugins that load when loading the page.

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

Disabling 90% of these plugins should help improve your INP and make the work of the main thread easier, as it delays page load.

Some INP issues arise because people don’t optimize their main thread work enough to ensure things are properly viable from a Core Web Vitals perspective.

Others can be caused by JavaScript file misfires 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 need to be optimized to achieve better and more efficient INP numbers.

As well as better overall numbers from Core Web Vitals.

Improving your INP is not a silver bullet

It is important to note that improving your INP is not a magic bullet that guarantees instant SEO success.

Instead, it’s just one of many things that may need to be completed as part of a bundle of quality changes that can help make a difference to your overall SEO performance.

How do you plan to implement INP repair into your overall SEO strategy?

More resources:


Featured Image: BestForBest/Shutterstock

Share.

Comments are closed.