Google’s priority is to make sure that its search results are awesome for its users.
Depending on who you speak to, that’s not exactly happening as of late but that’s beside the point. Showing slow un-usable websites will make Google look unreliable (and untrustworthy). They then leaned heavily on the importance of user experience by introducing Core Web VItals.
What’s happening to Core Web Vitals?
From early 2020, Core Web Vitals is measured by three signaling factors:
LCP – Largest Contentful Paint
FID – First Input Delay
CLS – Cumulative Layout Shift
As of March 2024, Interaction to Next Paint (or INP for short) has replaced First Input Delay (or FID) nudging its way into the three Core Web Vitals measurements that dictate optimal user experience.
A website’s current Core Web Vitals status.
Let’s define what constitutes an interaction that INP will measure:-
- A mouse click.
- A tap on a device touchscreen.
- Pressing a key on either a physical or onscreen keyboard
Note that mouse hover interactions are not included in INP data.
The INP measurement is taken during the entire lifespan of the user’s interactions on a particular page. With what could be possibly dozens of interactions on a page, the measurement takes 50 event-handling instances and uses the longest INP as the base.
INP measures the time it takes to process three individual time factors once an event interaction takes place on the page.
Input – the time between a user interaction on the page and event handlers executing
Process – the time it takes to retrieve data once an event is triggered
Presentation – the time it takes for your site to revise on-screen content and layout format
For INP to trigger a warning of varying degrees if the delay timings exceed 200ms. Anything above the 500ms threshold is deemed to be a poor user experience and red-flagged.
Your data can be retrieved by using Google Search Console, Lighthouse, Page Insights and other tools such as DeBugBear.
Google recommends looking at both CrUX (Chrome User Experience) and RUM (Real User Monitoring) field data if available. RUM data will have to be gathered by a third party and is normally purchased. See DeBugBear for RuM data, although there are other suppliers. For any website, testing via lab data would suffice but it is nowhere near as useful as field data.
How to diagnose and fix INP issues
When you use a webpage, the first thing that happens is input delay, which is the time it takes for the page to respond to your action/s. This delay can be long depending on what else is happening on the page, such as script loading or other actions overlapping with yours. Therefore it’s important to minimize input delay so that your actions can trigger event callbacks quickly.
This includes tasks like cutting down on third-party resources and delaying code that doesn’t have to load right away. Focus on loading parts of your site that users will likely want to use straight away. Typical techniques would be deferring JS script and minifying code, particularly those required by event handlers. More drastic solutions could mean changing platform, CDN hosting or server move which could lead to your desired performance improvements. Look to pay additional attention to tools such as WebPageTest to get further insights and even testing facilities to find out what could be excluded during the page load.
As an SEO consultant, the stance on INP?
Improving Core Web Vital metrics is only important if your users are being hampered by your site’s performance issues. Set aside Google’s algorithms and ranking factors and look at what your website’s users are telling you.
You can spend precious time and resources fixing INP issues which are only a slight over the -200ms needed and it’s very difficult to say, for example, if a possible 50ms reduction would improve anything for the user. It’s largely up to the web administrator to decide what could be fixed.
There are numerous scenarios where I think a fix is not required. For example, let’s say there is a submit button that takes 368ms to handle a form submission event. For the sake of 169ms to wait for a form to submit, would it be worth dedicating effort to fix this? Improving websites takes some trial and error with fixes causing possible performance issues elsewhere.
Let’s also not forget that a web visitor will get a bad experience if a click destination leads to poor content overall or even a broken page. This is way worse for optimisation than a 500ms INP issue for example.
Just be sure to weigh up your priorities between your marketing efforts and development resources.
Overall, your goal is to present to the user the smoothest, quickest experience possible that would ultimately lead to conversion. I would look at Core Web Vitals as only a small part of a larger conversation around user experience.