This post was sponsored by DebugBear. The opinions expressed in this article are solely those of the sponsor.
Maintaining website speed is important for user experience and SEO.
The Core Web Vitals initiative by Google provides a set of metrics to help you understand how your website is performing.
The three key Web Vitals metrics are:
This post will focus on the recently introduced INP metric and what you can do to improve it.
How do you measure your interaction with the next paint?
INP measures how quickly a website responds to user interactions (such as button clicks). More specifically, INP measures the time, in milliseconds, from user input until the browser finishes processing the interaction and is ready to display a visual update on the page.
This process must be completed within 200 milliseconds for a website to receive a “good” score. Values ​​greater than 0.5 seconds are considered “bad”. A low score on the Core Web Vitals metric can negatively impact your search engine rankings.
Google collects INP data from real website visitors as part of the Chrome User Experience Report (CrUX). This CrUX data ultimately influences rankings.
How to identify and fix slow INP time
The factors that cause poor next-paint interactions are often complex and can be difficult to understand. Follow this step-by-step guide to understand slow interactions on your website and find optimization opportunities.
1. How to identify pages with slow INP time
Different pages on your website will have different Core Web Vitals scores. Therefore, you need to identify slow pages and investigate what is slow.
Use Google Search Console
One easy way to check your INP score is to use the Core Web Vitals section of Google Search Console. This section reports data based on the Google CrUX data described previously.
By default, page URLs are grouped into URL groups that cover different pages. Please be careful here. Not all pages have the issues that Google reports. Instead, click on each URL group to see if URL-specific data is available for some pages and focus on those pages.
Using the Real User Monitoring (RUM) service
Google does not report Core Web Vitals data for every page on your website, and only raw measurements are provided without the details that can help you understand and solve problems. To achieve this, you can use real user monitoring tools such as DebugBear.
Real user monitoring works by installing an analytics snippet on your website that measures how fast your website is for your visitors. Once setup is complete, you will have access to the Interaction to Next Paint dashboard, which looks like this:
Identify the page you want to optimize in the list, hover over the URL, and click the funnel icon to see data only for that specific page.
2. Identify which elements interact slowly
Different visitors viewing the same page will have different experiences. A lot of it depends on how your visitors interact with your page. If you click on a background image, there's no risk of the page suddenly freezing, but if you click on a button that starts some heavy processing, it's more likely. And users in the latter scenario will experience much higher her INP.
To help with this, RUM data provides a breakdown of which page elements users interacted with and how large the interaction latency was.
The above screenshot shows various INP interactions categorized by user interaction frequency. To make optimization as easy as possible, you should focus on slow interactions that affect many users.
DebugBear allows you to click on page elements to add them to your filter and continue your investigation.
3. Identify the INP components that are most responsible for slowing down interactions
INP delay can be broken down into three different components:
- Input delay: Background code that blocks interaction processing.
- Processing time: Time spent directly processing the interaction.
- Presentation delay: Displays visual updates on screen.
Focus on which INP components are the biggest cause of INP time delays and make sure to keep that in mind during your investigation.
In this scenario, processing time is the biggest cause of slow INP times for the set of pages you're viewing, but you need to dig deeper to understand why.
Long processing times indicate the presence of code that is interrupting user interaction and running slowly. Instead, if you see high input lag, it suggests that there is a background task, such as a third-party script, that is blocking the interaction from being processed.
4. Check which script is causing the INP delay
Browsers may report certain scripts as causing slow interactions. A website may contain both first-party and third-party scripts, both of which can contribute to her INP time degradation.
RUM tools like DebugBear can collect and display this data, and the main thing to ask is whether you're seeing mostly your own website's code or third-party code.
Tip: If a script or source code function is marked as “N/A”, it means that the script comes from another publisher and has additional security restrictions that prevent the RUM tool from retrieving more detailed information. It may indicate that there is.
This begins the story. It seems like analytics/3rd party scripts are the biggest culprit for her slow INP times.
5. Determine why these scripts are running
At this point, I have a strong suspicion that third-party scripts are responsible for most of the INP delays, at least on the pages and elements that I'm currently seeing. But how do you know if these are general tracking scripts or if they actually play a role in handling interactions?
DebugBear provides a breakdown called INP Primary Script Invoker breakdown to help you see why your code is running. This is a bit of an exaggeration. Multiple different scripts may be responsible for slowing down the interaction. Only the biggest culprits are listed here. “Invoker” is just a value that the browser reports as to why this code was executed.
The following caller name is an example of a page-wide event handler.
- When clicked
- on mouse down
- Pointer up
You can see many of these things in the screenshot above. You can see that the analytics script is tracking clicks anywhere on the page.
In contrast, a caller name such as the following indicates an event handler for a specific element on the page.
- .load_more.onclick
- #Click logo
6. Check specific page views
It aggregates a lot of the data we've seen so far. We will now examine the individual INP events to draw a final conclusion about why INP is slow in this example.
Actual user monitoring tools, such as DebugBear, typically provide a way to review specific user experiences. For example, you can see which browser the user used, what screen size they used, and which elements caused the slowest interactions.
As mentioned earlier, multiple scripts can slow down the overall INP.[INP スクリプト]The section shows the scripts that were executed during the INP interaction.
You can take a closer look at each of these scripts to understand why they are running and why they take so long to complete.
7. For more information, use DevTools Profiler
Real user monitoring tools have access to large amounts of data, but for performance and security reasons they cannot access all available data. Therefore, we recommend that you also use Chrome DevTools to measure page performance.
To debug your INP with DevTools, you can measure how the browser handles one of the slow interactions you previously identified. DevTools shows you exactly how the browser is spending its time processing interactions.
How to resolve this issue
In this example, you or your development team can resolve this issue by:
- Work with third-party script providers to optimize your scripts.
- If the script is not essential to your website, remove it or find an alternative provider.
- Adjust how your own code interacts with scripts
How to investigate high input lag
In the previous example, most of the INP time was spent executing code in response to interactions. However, often by the time a user interaction occurs, the browser is already busy running other code. Inspecting the INP component reveals a high input delay value.
This can happen for a variety of reasons, including:
- The user interacted with the website while the website was still loading.
- A scheduled task (such as an ongoing animation) is running on the page.
- The page is loading and rendering new content.
To understand what's going on, check the INP script section for the performer name and individual user experience.
In this screenshot, you can see that the timer is running code as soon as the user interaction begins.
Open the script and you will see the exact code that will be executed.
The source code shown in the previous screenshot comes from a third-party user tracking script running on the page.
At this stage, you and your development team can continue with the INP workflow described earlier in this article. For example, use browser DevTools to debug or contact third-party providers for support.
How to investigate long presentation delays
Presentation lag tends to be more difficult to debug than input lag or processing time. This is often caused by browser behavior rather than specific scripts. But as before, start by identifying specific pages and specific interactions.
Here you can see an example of an interaction with high presentation delay.
You can see this happen when a user enters text into a form field. In this example, many visitors have pasted in large amounts of text that must be processed in the browser.
The fix here was to delay the process, show the user a “Waiting…” message, and complete the process later. You can see how your INP score has improved starting May 3rd.
Get the data you need to improve your next interaction with Paint
Setting up real user monitoring helps you understand how users experience your website and what you can do to improve it. Try DebugBear today by signing up for a 14-day free trial.
Google's CrUX data is aggregated over 28 days, so it can take some time to notice regressions. Real-user monitoring lets you instantly see the impact of changes to your website and automatically alerts you to major changes.
DebugBear monitors lab data, CrUX data, and real user data, so you have all the data you need to optimize your Core Web Vitals in one place.
This article is sponsored by DebugBear and the views expressed here represent those of the sponsor.
Ready to start optimizing your website? Sign up for DebugBear and get the data you need to deliver a great user experience.
image credits
Featured Image: Image by Redesign.co. Used with permission.