Interaction to Next Paint (INP) is a Core Web Vitals (CWV) metric to measure the web page’s interactivity for user experience quality. INP is a user-centric page speed metric that affects search engine optimization performance, conversion rate, and user satisfaction. Interaction to Next Paint replaced First Input Delay (FID) in March 2024 in Core Web Vitals. A high INP score means the web page fails to respond to user interactions. Chrome User Experience (CrUX) reports that 90% of a user’s time is spent on the web page after loading and rendering. Thus, INP focuses on the quality of the user experience at 90%, which is the majority.
The importance of Interaction to Next Paint is measuring the visual feedback delays rather than every type of interaction delay. For example, network fetches, or asynchronous requests from the web servers are not considered in INP calculation. INP is calculated when the next paint event is blocked or delayed.
Interaction to Next Paint (INP) has three main components these are Input Delay, Processing Delay and Presentation Delay.
- Input Delay is the time between user interaction triggers, such as a click and a request to the server.
- Processing Delay is the time between the triggered request and its completion from the web server.
- Presentation Delay is the time required to complete the visual feedback and change caused by the user interaction.
To decrease and have a low INP score, the input, processing and presentation delays should be optimized. Use PageSpeed Insights, Real User Monitoring, and Web-Vitals library to optimize, measure and track the INP.
What is a Good Interaction to Next Paint (INP) Score?
Measurement of Interaction to Next Paint involves three main score ranges: below 200 miliseconds, between 200 and 500 milliseconds, and above the 500 milliseconds. Below 200 milliseconds of INP means good performance, between 200 and 500 milliseconds of INP score means improvement, and above 500 miliseconds of INP means poor performance on web page interactivity.
- A good INP Score means good responsiveness. Good responsiveness means below 200 milliseconds of Interaction to the Next Paint timing.
- INP timing between 200 milliseconds and 500 milliseconds represents a medium INP score. A medium INP score means mediocre responsiveness and needs optimization.
- An INP timing above 500 milliseconds means poor web page responsiveness and user experience on web page interactions.
How to Measure Interaction to Next Paint in the Field?
To measure the responsiveness via Interaction to Next Paint (INP), Chrome User Experience Report (Crux) data is used. Chrome User Experience Report involves Real User Monitoring (RUM) which explains what percentage of the users interacted with a good or bad INP score. Chrome User Experience Report is created via CRuX pipeline on Google. CrUX data includes information about click, tap, touch, mouse up, and keypress. Measuring INP for website (origin-level) and individual URL-level is possible. To measure the field data for INP requires having a notable website with enough traffic. A website without popularity and enough search engine traffic is not included in the CrUX, thus it is not possible to see the INP data.
Alternative method of INP measurement in the field is using a customized javascript for tracking and recording the user metrics. Creating customized events from Google Tag Manager and reflecting the event data on the Google Analytics 4 for INP, Page Load, DomContentLoaded helps a webmaster and UX expert to track the INP.
There are two methods of measurement for Interaction to Next Paint (INP), the first one is using Real User Monitoring (RUM) and the second one is using the Lab Data which comes from page loading performance simulators such as Lighthouse of Google.
How to Test Interaction to Next Paint in the Lab?
To test interaction to next paint in the lab, use Lighthouse, web page loading timing simulator. Lighthouse is a web page loading performance tester, and designed by Google Web Developer team. Lighthouse results for INP reflects a simulated user experience based on the page loading and interaction flow. To get the best results for INP measurement, use Lab and Field measurement and data together.
When does a web page have an INP Score?
A web page has an INP score if there is an interaction between the user and the web page. If there is no interaction between the user and the web page, the INP score can’t be measured or calculated. The Chrome tracks the first 50 interactions between the user and the web page. The worst interaction delay is counted as the INP score. If there is no interaction, INP score won’t be included in the measurement data.
How to Measure INP with Web-Vitals JavaScript Library?
To measure the INP score with Web-Vitals JavaScript library, follow the steps below.
- Install the web-vitals Library: Make sure you have the web-vitals library installed in your project. If it’s not installed, you can add it using a package manager like npm with the command npm install web-vitals.
- Import the onINP Function: At the beginning of your JavaScript file, import the onINP function from the web-vitals/attribution module. This is necessary to access the enhanced interaction tracking capabilities.
- Define the sendToGoogleAnalytics Function: Copy the sendToGoogleAnalytics function into your script. This function is responsible for handling the data captured by onINP and formatting it for Google Analytics.
- Understand the sendToGoogleAnalytics Function: Familiarize yourself with the structure of the sendToGoogleAnalytics function. It deconstructs the attribution object to extract detailed interaction data and then prepares this data for transmission to Google Analytics.
- Set Up Google Analytics: Ensure that Google Analytics is correctly set up on your website. You should have the Global Site Tag (gtag.js) installed on your pages where you intend to track interactions.
- Configure the Event Parameters: In the sendToGoogleAnalytics function, review and, if necessary, modify the event parameters to align with your specific tracking requirements for Google Analytics.
- Initiate the INP Listener: Call the onINP function at the end of your script, passing the sendToGoogleAnalytics function as an argument. This step sets up the listener to capture INP events and send the data to the sendToGoogleAnalytics function.
- Test the Implementation: After integrating the script, test your web page to ensure that INP events are being captured and sent to Google Analytics. You can use tools like the browser’s developer console or Google Analytics’ real-time reporting feature to verify the data flow.
- Analyze the Data in Google Analytics: Once you’ve confirmed that data is being sent, use Google Analytics to analyze the INP metrics. These insights can help you understand user interactions and webpage responsiveness, guiding improvements for a better user experience.
- Keep Your Implementation Updated: Stay informed about updates to the web-vitals library or changes in Google Analytics to ensure your implementation remains effective and accurate over time.
An example code snippet for measurement of INP is below.
import {onINP} from 'web-vitals/attribution';
function sendToGoogleAnalytics ({name, value, id, attribution}) {
const {eventEntry, eventTarget, eventType, loadState} = attribution;
const {startTime, processingStart, processingEnd, duration, interactionId} = eventEntry;
const eventParams = {
metric_inp_value: value,
metric_id: id,
metric_inp_event_target: eventTarget,
metric_inp_event_type: eventType,
metric_inp_load_state: loadState,
metric_inp_start_time: startTime,
metric_inp_processing_start: processingStart,
metric_inp_processing_end: processingEnd,
metric_inp_duration: duration,
metric_inp_interaction_id: interactionId
};
gtag('event', name, eventParams);
}
onINP(sendToGoogleAnalytics);This code snippet is designed to collect and send Interaction to Next Paint (INP) metrics to Google Analytics. INP is a performance metric that measures the responsiveness of a webpage. The code uses the web-vitals library, specifically the attribution build, which provides more detailed information about each interaction. Here’s a breakdown of the key components of this script:
- Importing the onINP function: The script begins by importing onINP from the web-vitals/attribution module. This function is used to set up a listener that reports INP metrics.
- The sendToGoogleAnalytics function: This function is defined to handle the data sent from the onINP listener. It receives an object with several properties related to the INP event.
- Destructuring the attribution object: The attribution object provides detailed context about the interaction, including the event that triggered it, the target element, and timing information.
- Timing Information: The script extracts various timing details like when the interaction started (startTime), when processing began (processingStart), and when it ended (processingEnd).
- Interaction Metrics: It captures several metrics, such as the INP value (value), a unique ID for the interaction (id), and the type of event (eventType).
- Event Parameters Object: The script constructs an eventParams object that consolidates all the relevant data points. This includes the INP value, the event type, the target element, and various timing metrics.
- Sending Data to Google Analytics: The data is then sent to Google Analytics using the gtag function. The event name is passed along with the eventParams object, allowing Google Analytics to record and analyze these interaction metrics.
- Setting up the INP Listener: Finally, the onINP function is called with sendToGoogleAnalytics as an argument. This sets up the listener to report INP metrics, which are then processed and sent to Google Analytics.
The INP measurement code snippet uses the EventTiming API, and its outputs’ interactionID property.
How to Optimize Interaction to Next Paint (INP)?
To optimize the Interaction to Next Paint (INP), follow the steps below.
- Start with Field Data from Real User Monitoring (RUM)
- Analyze Interaction Types: Determine if clicks, keypresses, or taps are causing delays, affecting INP.
- Monitor Timing Relative to Page Load: Observe if interactions are slower during or after the page load, impacting INP.
- Leverage RUM Tools: Use tools like New Relic or Dynatrace to gather detailed RUM data, crucial for INP analysis.
- Perform Comparative Analysis: Compare INP across user segments and browsers to identify specific optimization areas.
- Utilize Chrome User Experience Report (CrUX) if RUM is Unavailable
- Interpret Core Web Vitals Data: Use CrUX to gain an overview of INP and other vital metrics.
- Access Data via PageSpeed Insights: Retrieve CrUX data for your site through PageSpeed Insights for a basic INP assessment.
- Benchmark Against Industry Standards: Use CrUX for comparing your site’s INP with industry benchmarks.
- Understand CrUX Limitations: Acknowledge CrUX’s lack of detailed interaction data compared to RUM.
- Diagnose Slow Interactions in the Lab
- Create Controlled Test Environments: Simulate user behavior in a lab setting to identify INP issues.
- Simulate Common User Flows: Test typical user pathways on your site to uncover INP bottlenecks.
- Conduct Stress Tests: Evaluate how page interactions perform under various load conditions.
- Utilize Diagnostic Tools: Employ tools like Lighthouse and Chrome DevTools for detailed INP analysis.
- Optimize Each Phase of Interaction
- Minimize Input Delay: Reduce the time from user action to event processing start, crucial for INP.
- Accelerate Processing Time: Optimize the duration of event callbacks to improve INP.
- Reduce Presentation Delay: Shorten the time from event completion to the visual update.
- Aim for Holistic Optimization: Focus on enhancing all interaction phases to improve overall INP.
- Understand the Impact of Multiple Main Threads
- Recognize Separate Browsing Contexts: Understand how iframes and pop-ups with their threads affect INP.
- Analyze Page-Level INP: INP considers all frames within a page, influencing overall performance.
- Balance Thread Workloads: Manage tasks across multiple threads to avoid performance issues.
- Consider Resource Constraints: Be aware of how limited device resources can influence thread performance and INP.
- Reduce Input Delay
- Manage Main Thread Activities: Address activities like script execution that impact INP.
- Handle Overlapping Interactions: Efficiently manage simultaneous user actions to reduce input delays.
- Implement Continuous Monitoring: Regularly track interaction delays for ongoing INP optimization.
- Optimize Script Loading and Execution: Improve script handling to reduce initial input delay, a critical component of INP.
- Manage Script Evaluation During Startup
- Understand Script Impact on INP: Recognize how script processing during startup can extend input delay.
- Optimize Script Parsing and Execution: Reduce time taken in script evaluation to improve INP during page load.
- Prevent Long Tasks During Load: Avoid extensive script tasks at startup to maintain a responsive page.
- Monitor Startup Performance: Regularly evaluate how startup processes affect INP, adjusting scripts and load sequences as needed.
How to Avoid Layout Trashing to Improve Interaction to Next Paint (INP)?
To Avoid Layout Trashing to improve Interaction to Next Paint (INP), use simpler layout styling, and avoid the complex requests for rendering the web page. The Layout Trashing means that the rendered layout is restyled by another request which makes the first layout vanished. The cycle of layout trashing keeps the main thread of the web browser busy and cause input latency which is part of INP score.
Follow the steps below to improve INP by avoiding layout trashing.
- Batch DOM Modifications: Group together DOM (Document Object Model) changes to minimize the number of reflows and repaints. This prevents frequent, inefficient alterations to the layout.
- Use CSS Transforms Over Top/Left Animations: Prefer CSS transforms for animations instead of changing the top or left properties. Transforms are more performance-efficient as they don’t trigger layout recalculations.
- Optimize JavaScript Execution: Keep JavaScript execution times short. Long-running scripts can block the main thread, leading to input delays. Break up long tasks into smaller, asynchronous chunks where possible.
- Leverage requestAnimationFrame: When making visual changes, use requestAnimationFrame to ensure changes are made at the optimal time in the frame lifecycle, reducing layout thrashing.
- Use Virtualization for Large Lists: Implement virtualization for rendering large lists or data sets. This technique renders only the items in view, reducing the amount of DOM manipulation.
- Avoid Forced Synchronous Layouts: Identify and eliminate instances where styles are read (like getting an element’s width) and then immediately written to (like setting an element’s width), as this forces a synchronous layout.
- Defer Non-Critical Work with requestIdleCallback: Use requestIdleCallback for non-essential tasks. This API allows you to schedule work when the main thread is idle, reducing the impact on key user interactions.
- Use CSS Containment: Apply the contain property in CSS to limit the scope of the browser’s rendering process, which can help in isolating layout changes to specific parts of the DOM.
- Minimize Complex CSS Selectors: Simplify CSS selectors to reduce the time the browser spends calculating styles. Complex selectors can slow down rendering performance.
- Utilize Web Workers for Heavy Computations: Offload heavy computations to Web Workers. This keeps the main thread free for user interactions, as Web Workers run in a separate thread.
How to Optimize INP with CSS Optimization?
CSS and layout thresholds are connected to each other. Rendering, painting, layout, and composite events during creating the web pages have an effect on input and interaction latencies. To optimize INP with the CSS related changes, follow the steps below.
- Minimize JavaScript’s Impact on Styles
- Context: JavaScript manipulations often trigger visual changes, either directly or through calculations affecting styles. Poorly timed or extended JavaScript execution can degrade performance.
- INP Relevance: Minimizing JavaScript’s impact, especially on style changes, can reduce the time for style recalculations, thereby enhancing INP.
- Simplify CSS Selectors
- Context: Complex selectors require more processing time as the browser determines which elements they apply to. Simplifying these selectors can reduce style calculation time.
- INP Relevance: By reducing the complexity of selectors, the browser spends less time matching selectors to elements, improving the time to next paint after a user interaction.
- Reduce Number of Styled Elements
- Context: The overall cost of style calculations is related to the number of elements and selectors. Reducing either reduces the computational burden.
- INP Relevance: Fewer elements needing style recalculations mean a more responsive page, contributing positively to INP.
- Measure Style Recalculation Costs
- Context: Chrome DevTools can be used to measure the cost of style recalculations, identifying long-running frames and the affected elements
- INP Relevance: Identifying and addressing costly style recalculations can directly improve INP by reducing delays in rendering after interactions.
- Implement BEM (Block, Element, Modifier)
- Context: BEM methodology simplifies selectors and hierarchies, promoting efficient style calculations.
- INP Relevance: Efficiently structured CSS using BEM reduces the time browsers spend in style matching and recalculations, benefiting INP by reducing delays in visual updates post-interaction.
How to Optimize INP by using Content-visibilty in CSS
To optimize INP by using Content-visibility in CSS, follow the steps below.
- Understand content-visibility: Familiarize yourself with the content-visibility CSS property. This property allows the browser to skip the rendering work for off-screen content until it’s needed (i.e., when it approaches the viewport).
- Apply content-visibility to Off-Screen Elements: In your CSS, apply content-visibility: auto; to elements that are initially off-screen. This tells the browser these elements can be rendered lazily.
- Use contain-intrinsic-size for Placeholder Sizing: For elements with content-visibility: auto, use the contain-intrinsic-size property to specify a placeholder size. This helps the browser allocate space even when the content is not rendered yet.
- Test Your Layout: Ensure your layout behaves as expected with content-visibility applied. Sometimes, this property can cause unexpected layout shifts, so it’s important to test thoroughly.
- Monitor Performance: Use performance monitoring tools (like Chrome’s DevTools) to measure the impact of content-visibility on your page’s rendering performance. Look for improvements in rendering times and INP scores.
- Adjust as Needed: If you encounter layout issues or less-than-ideal performance improvements, adjust your usage of content-visibility. This might involve tweaking the elements it’s applied to or adjusting other CSS properties that interact with it.
- Consider Progressive Enhancement: Use content-visibility as a progressive enhancement. Ensure that your site functions correctly even in browsers that do not support this property.
- Stay Updated on Best Practices: As content-visibility is a relatively new CSS feature, stay updated on best practices and emerging patterns in its usage. Follow web development blogs, forums, and the latest documentation.
How does DOM Size affect INP?
Excessive DOM size affect INP negatively. There are 5 main reasons for this. These are increased processing time for DOM manipulations, rendering cost and performance, javascript execution time, main thread blockage, and network parsing delays.
- Increased Processing Time for DOM Manipulations:
- Complexity of DOM Operations: When the DOM is large, any operation that involves reading from, writing to, or manipulating the DOM becomes more resource-intensive. Tasks like adding, removing, or updating elements take longer because the browser has to manage more nodes.
- Event Handling Overhead: Large DOMs often have more elements that require event listeners. The browser may take more time to identify which element an event (like a click or keystroke) is targeting, thus increasing the time between the user action and the start of event processing.
- Impact on Rendering Performance:
- Layout Calculations: With a bigger DOM, the browser must perform more complex layout calculations. When a user interacts with a page, any change that triggers a re-layout or reflow (like a hover effect or a dynamic content update) will take longer to process and render.
- Rendering Pipeline Delays: In the browser’s rendering pipeline, changes to the DOM can affect the layout, paint, and composite stages. A larger DOM can slow down these stages, especially if it involves visually complex or nested elements.
- Increased JavaScript Execution Time:
- JavaScript-DOM Interactions: Scripts that interact with the DOM will take longer to execute on a large DOM. This is because tasks such as querying elements, binding data, and manipulating the DOM tree are more time-consuming.
- Garbage Collection Overhead: Larger DOMs can lead to increased memory usage, which in turn can trigger more frequent and longer garbage collection pauses in JavaScript engines. This process can temporarily block the main thread, adding to input latency.
- Main Thread Blockage:
- Synchronous Blocking: If the main thread is busy processing a large DOM, it can’t simultaneously process user inputs, leading to noticeable input latency.
- Cumulative Layout Shift (CLS): A large DOM can contribute to layout shifts, where elements move around as the page loads or in response to user interactions. This not only affects visual stability but can also delay the processing of user inputs.
- Network and Parsing Delays:
A large DOM often means a larger HTML document to be downloaded and parsed, which can delay the initial render of the page and the readiness for user interaction.
How to Use Server-side Rendering for Optimizing INP?
Server-side rendering is rendering a web document on the server-side and prvoide it to the user. The optimization of INP requires server-side rendering because server-side rendering provides less burden on the client-side. But, server-side rendering can increase the Time to First Byte (TTFB) score, thus streamlining the HTML file is necessary to improve input latency and Interaction to Next Paint.
Follow the steps below to use server-side rendering for improving INP performance in core web vitals and load responsiveness context.
- Stream HTML from the Server
- Utilize Streaming: Implement server-side streaming where HTML is sent in chunks as soon as it’s available. This allows the browser to start processing HTML incrementally, reducing the time to first paint and improving INP.
- Browser’s Incremental Processing: As the server streams HTML, the browser parses and renders it in chunks. This periodic yielding to the main thread ensures other processes, including user interaction handling, are not blocked, positively impacting INP.
- Avoid Long Tasks: Streaming prevents the creation of long tasks in parsing HTML, which is beneficial for INP as it allows other critical tasks, including interaction processing, to be handled more promptly.
- Optimize Client-Side Rendering
- Limit Client-Side HTML Generation: When using client-side JavaScript to create HTML (e.g., via innerHTML or document.createElement), keep the generated DOM nodes minimal to reduce processing time.
- Understand Rendering Impact: Creating HTML on the client leads to longer tasks that block the main thread, adversely affecting INP. Keep client-side DOM manipulations lightweight and efficient.
- Preload Important Resources: Ensure that critical resources are preloaded. Client-side HTML generation often misses out on browser preloading optimizations, affecting the Largest Contentful Paint (LCP) and potentially INP.
- Provide HTML from the Server
- Use Server-Side Rendering (SSR): For frameworks like React, Vue, or Svelte, leverage SSR to deliver HTML directly from the server. This reduces the burden on the client-side for initial rendering.
- Optimize Time to First Byte (TTFB): Ensure your server-side rendering process is efficient to avoid delays in TTFB, which can impact FCP, LCP, and subsequently INP.
- Utilize Streaming APIs for SSR: Implement streaming APIs in Node.js or other JavaScript runtimes to allow the server to begin streaming HTML to the browser as soon as possible.
- Limit DOM Size on the Client
- Reduce DOM Complexity: Whether in SPAs or MPAs, strive to keep the DOM size small. This reduces the rendering workload and helps maintain a lower INP.
- Optimize Client-Side Updates: For dynamic content updates, be mindful of the amount of DOM manipulation to avoid creating performance bottlenecks.
- Implement a Streaming Service Worker Architecture
- Leverage Service Workers: Use service workers to cache static parts of your site, while fetching HTML for dynamic content using the ReadableStream API.
- Enhance Perceived Performance: This approach can make navigation between pages feel instant, improving user experience and potentially enhancing INP by reducing the load on the main thread.
- Complement Browser Navigation: A streaming service worker architecture augments rather than replaces browser navigation, allowing for efficient loading while maintaining optimal INP.
- Component Hydration on the Client
- Hydrate with Performance in Mind: If using frameworks like React, Vue, or Svelte, ensure that client-side hydration of components is done efficiently to keep interactions responsive.
- Balance Interactivity and Performance: While hydration is necessary for interactivity, it should be balanced with performance considerations to maintain optimal INP.
- Monitor and Analyze INP Metrics
- Continuous Monitoring: Use performance monitoring tools to track INP metrics regularly.
- Analyze Field Data: Look into field data to identify specific interactions or elements that might be causing high INP values, and optimize them accordingly.
What is the Difference between Interction to Paint (INP) and First Input Delay (FID)?
The main difference between Interaction to Next Paint (INP) and First Input Delay (FID) is that INP focuses on user-centric page experience and quality of interaction between the user and web page, while First Input Delay (FID) is a load responsiveness metric focuses on loading phase of the web page for interaction.
What is the Weight of Interaction to Next Paint (INP) for Lighthouse Scoring?
The Weight of Interaction to Next Paint (INP) in Lighthouse Scoring is a performance metric used to evaluate the responsiveness of a web page. Lighthouse, a tool for auditing web pages, uses various metrics to assess performance, including the INP. Interaction to Next Paint (INP) weight on Lighthouse score is not expressed by Google Chrome Web Developers at the moment.
- Sliding Window - August 12, 2024
- B2P Marketing: How it Works, Benefits, and Strategies - April 26, 2024
- SEO for Casino Websites: A SEO Case Study for the Bet and Gamble Industry - February 5, 2024
