{"id":505,"date":"2023-12-07T20:00:00","date_gmt":"2023-12-07T21:00:00","guid":{"rendered":"https:\/\/upprofits.net\/?p=505"},"modified":"2024-08-30T11:28:33","modified_gmt":"2024-08-30T11:28:33","slug":"preparing-for-interaction-to-next-paint-a-new-web-core-vital","status":"publish","type":"post","link":"https:\/\/upprofits.net\/index.php\/2023\/12\/07\/preparing-for-interaction-to-next-paint-a-new-web-core-vital\/","title":{"rendered":"Preparing For Interaction To Next Paint, A New Web Core Vital"},"content":{"rendered":"
Preparing For Interaction To Next Paint, A New Web Core Vital<\/title><\/p>\n<article>\n<header>\n<h1>Preparing For Interaction To Next Paint, A New Web Core Vital<\/h1>\n<address>Geoff Graham<\/address>\n<p> 2023-12-07T21:00:00+00:00<br \/>\n 2024-08-30T10:05:08+00:00<br \/>\n <\/header>\n<p>This article is sponsored by <b>DebugBear<\/b><\/p>\n<p>There\u2019s a change coming to the Core Web Vitals lineup. If you\u2019re reading this before March 2024 and fire up your favorite performance monitoring tool, you\u2019re going to to get a Core Web Vitals report like this one pulled from PageSpeed Insights:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/1-core-web-vitals-assessment.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"323\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/1-core-web-vitals-assessment.png\" alt=\"Core Web Vitals report with six mini-charts\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/1-core-web-vitals-assessment.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>You\u2019re likely used to seeing most of these metrics. But there\u2019s a good reason for the little blue icon sitting next to the second metric in the second row, <strong>Interaction to Next Paint (INP)<\/strong>. It\u2019s the newest metric of the bunch and is set to formally be a ranking factor in Google search results <a href=\"https:\/\/web.dev\/blog\/inp-cwv\">beginning in March 2024<\/a>.<\/p>\n<p>And there\u2019s a good reason that INP sits immediately below the First Input Delay (FID) in that chart. INP will officially replace FID when it becomes an official Core Web Vital metric.<\/p>\n<p>The fact that INP is already available in performance reports means we have an opportunity to familiarize ourselves with it today, in advance of its release. That\u2019s what this article is all about. Rather than pushing off INP until after it starts influencing the way we measure site performance, let\u2019s take a few minutes to level up our understanding of what it is and why it\u2019s designed to replace FID. This way, you\u2019ll not only have the information you need to read your performance reports come March 2024 but can proactively prepare your website for the change.<\/p>\n<h2 id=\"i-m-not-seeing-those-metrics-in-my-reports\">\u201cI\u2019m Not Seeing Those Metrics In My Reports\u201d<\/h2>\n<p>Chances are that you\u2019re looking at Lighthouse or some other report <a href=\"https:\/\/www.smashingmagazine.com\/2023\/10\/answering-questions-interpreting-page-speed-reports\/#does-lighthouse-use-rum-data-too\">based on lab data.<\/a> And by that, I mean data that isn\u2019t coming from the field in the form of \u201creal\u201d users. You configure the test by applying some form of simulated throttling and start watching the results pour in. In other words, the data is not looking at your <em>actual<\/em> web traffic but a <em>simulated<\/em> environment that gives you an approximate view of traffic when certain conditions are in place.<\/p>\n<p>I say all that because it\u2019s important to remember that <strong>not all performance data is equal<\/strong>, and some metrics are simply impossible to measure with certain types of data. INP and FID happen to be a couple of metrics where lab data is unsuitable for meaningful results, and that\u2019s because both <strong>INP and FID are measurements of user interactions<\/strong>. That may not have been immediately obvious by the name \u201cFirst Input Delay,\u201d but it\u2019s clear as day when we start talking about \u201c<em>Interaction<\/em> to Next Paint\u201d — it\u2019s right there in the name!<\/p>\n<p>Simulated lab data, like what is used in Lighthouse reports, does not interact with the page. That means there is no way for it to evaluate the first input a user makes or any other interactions on the page.<\/p>\n<p>So, that\u2019s why you\u2019re not seeing INP or FID in your reports. If you want these metrics, then you will want to use a performance tool that is capable of using real user data, such as DebugBear, which can <a href=\"https:\/\/www.debugbear.com\/real-user-monitoring?utm_campaign=sm-3\">monitor your actual traffic on an ongoing basis in real time<\/a>, or PageSpeed Insights which bases its finding on Google\u2019s \u201c<a href=\"https:\/\/developer.chrome.com\/docs\/crux\/\">Chrome User Experience Report<\/a>\u201d (commonly referred to as CrUX), though DebugBear is capable of providing CrUX reporting as well. The difference between real-time user monitoring and measuring performance against CrUX data is big enough that it\u2019s worth reading up on it, and <a href=\"https:\/\/www.smashingmagazine.com\/2023\/10\/answering-questions-interpreting-page-speed-reports\/\">we have a full article on Smashing Magazine<\/a> that goes deeply into the differences for you.<\/p>\n<h2 id=\"inp-improves-how-page-interactions-are-measured\">INP Improves How Page Interactions Are Measured<\/h2>\n<p>OK, so we now know that both INP and FID are about page interactions. <strong>Specifically, they are about measuring the time between a user interacting with the page and the page responding to that interaction.<\/strong><\/p>\n<p>What\u2019s the difference between the two metrics, then? The answer is two-fold. First, FID is a measure of the time it takes the page to start processing an interaction or the <strong>input delay<\/strong>. That sounds fine on the surface — we want to know how much time it takes for a user to start an interaction and optimize it if we can. The problem with it, though, is that it takes just one part of the time for the page to <em>fully<\/em> respond to an interaction.<\/p>\n<p>A more complete picture considers the input delay in addition to two other components: <strong>processing time<\/strong> and <strong>presentation delay<\/strong>. In other words, we should also look at the time it takes to process the interaction and the time it takes for the page to render the UI in response. As you may have already guessed, INP considers all three delays, whereas FID considers only the input delay.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/2-timeline-inp-components.jpg\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"393\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/2-timeline-inp-components.jpg\" alt=\"Diagram of a timeline aligned with the three INP components.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/2-timeline-inp-components.jpg\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>The second difference between INP and FID is <em>which<\/em> interactions are evaluated. FID is not shy about which interaction it measures: the very first one, as in the input delay of the <em>first<\/em> interaction on the page. <strong>We can think of INP as a more complete and accurate representation of how fast your page responds to user interactions because it looks at<\/strong> <strong><em>every single one<\/em><\/strong> <strong>on the page.<\/strong> It\u2019s probably rare for a page to have only one interaction, and whatever interactions there are after the first interaction are likely located well down the page and happen after the page has fully loaded.<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aSo,%20where%20FID%20looks%20at%20the%20first%20interaction%20%e2%80%94%20and%20only%20the%20input%20delay%20of%20that%20interaction%20%e2%80%94%20INP%20considers%20the%20entire%20lifecycle%20of%20all%20interactions.%0a&url=https:\/\/smashingmagazine.com%2f2023%2f12%2fpreparing-interaction-next-paint-web-core-vital%2f\"><\/p>\n<p>So, where FID looks at the first interaction \u2014 and only the input delay of that interaction \u2014 INP considers the entire lifecycle of all interactions.<\/p>\n<p> <\/a>\n <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<h2 id=\"measuring-interaction-to-next-paint\">Measuring Interaction To Next Paint<\/h2>\n<p>Both FID and INP are measured in milliseconds. Don\u2019t get too worried if you notice your INP time is greater than your FID. That\u2019s bound to happen when <em>all<\/em> of the interactions on the page are evaluated instead of the first interaction alone.<\/p>\n<p>Google\u2019s guidance is to <a href=\"https:\/\/web.dev\/articles\/fid#what_is_a_good_fid_score\">maintain an FID under 100ms<\/a>. And remember, FID does not take into account the time it takes for the event to process, nor does it consider the time it takes the page to update following the event. It only looks at the delay of the event process.<\/p>\n<p>And since INP does indeed take all three of those factors into account — the input delay, processing time, and presentation delay — Google\u2019s guidance for measuring INP is inherently larger than FID: <strong>under 200ms for a \u201cgood\u201d result, and between 200-500ms for a passing result.<\/strong> Any interaction that adds up to a delay greater than 500ms is a clear bottleneck.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/3-200ms-500ms-range-passing-inp-scores.jpg\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"184\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/3-200ms-500ms-range-passing-inp-scores.jpg\" alt=\"Showing the 200ms-500ms range of passing INP scores.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/3-200ms-500ms-range-passing-inp-scores.jpg\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>The goal is to spot slow interactions and optimize them for a smoother user experience. How exactly do you identify those problems? That\u2019s what we\u2019re looking at next.<\/p>\n<h2 id=\"identifying-slow-interactions\">Identifying Slow Interactions<\/h2>\n<p>There\u2019s already plenty you can do right now to optimize your site for INP before it becomes an official Core Web Vital in March 2024. Let\u2019s walk through the process.<\/p>\n<p>Of course, we\u2019re talking about the user doing <em>something<\/em> on the page, i.e., an action such as a click or keyboard focus. That might be expanding a panel in an accordion component or perhaps triggering a modal or a prompt any change in a state where the UI updates in response.<\/p>\n<p>Your page may consist of little more than content and images, making for very few, if any, interactions. It could just as well be some sort of game-based UI with thousands of interactions. INP can be a heckuva lot of work, but it really comes down to how many interactions we\u2019re talking about.<\/p>\n<p>We\u2019ve already talked about the difference between <strong>field data<\/strong> and <strong>lab data<\/strong> and how lab data is simply unable to measure page interactions accurately. That means you will want to rely on field data when pulling INP reports to identify bottlenecks. And when we\u2019re talking about field data, we\u2019re talking about two different flavors:<\/p>\n<ol>\n<li><strong>Data from the CrUX report<\/strong> that is based on the results of real Chrome users. This is readily available in PageSpeed Insights and Google Search Console, not to mention DebugBear. If you use either of Google\u2019s tools, just note that their throttling methods collect metrics on a fast connection and then estimate how fast the page would be on a slower connection. DebugBear actually tests with a slower network, resulting in more accurate data.<\/li>\n<li><strong>Monitoring your website\u2019s real-time traffic<\/strong>, which will require adding a snippet to your source code that sends traffic data to a service. And, yes, DebugBear is one such service, though there are others. You can even take advantage of <a href=\"https:\/\/developer.chrome.com\/docs\/crux\/bigquery\/\">historical CrUX data integrated with BigQuery<\/a> to get a historical view of your results dating back as far as 2017 with new data coming in monthly, which isn\u2019t exactly \u201creal-time\u201d monitoring of your actual traffic, but certainly useful.<\/li>\n<\/ol>\n<p>You will get the most bang for your buck with real-time monitoring that keeps a historical record of data you can use to evaluate INP results over time.<\/p>\n<p>That said, you can still start identifying bottlenecks today if you prefer not to dive into real-time monitoring right this second. <a href=\"https:\/\/www.debugbear.com\/inp-debugger?utm_campaign=sm-3\">DebugBear has a tool that<\/a> analyzes any URL your throw at it. What\u2019s great about this is that it <em>shows<\/em> you the elements that receive user interaction and provides the results right next to them. <strong>The result of the element that takes the longest is your INP result.<\/strong> That\u2019s true whether you have one component above the 500ms threshold or 100 of them on the page.<\/p>\n<p>The fact that DebugBear\u2019s tool highlights all of the interactions and organizes them by INP makes identifying bottlenecks a straightforward process.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/4-debugbear-inp-report.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"690\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/4-debugbear-inp-report.png\" alt=\"DebugBear INP report.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n Whoa there! We have a bottleneck! (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/4-debugbear-inp-report.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>See that? There\u2019s a clear INP offender on Smashing Magazine\u2019s homepage, and it comes in slightly outside the healthy INP range for a score of 510ms even though the next \u201cslowest\u201d result is 184ms. There\u2019s a little work we need to do between now and March to remedy that.<\/p>\n<p>Notice, too, that there are actually two scores in the report: the INP Debugger Result and the Real User Google Data. The results aren\u2019t even close! If we were to go by the Google CrUX data, we\u2019re looking at a result that is 201ms <em>faster<\/em> than the INP Debugger\u2019s result — a big enough difference that would result in the Smashing Magazine homepage fully passing INP.<\/p>\n<p>Ultimately, what matters is how real users experience your website, and you need to look at the CrUX data to see that. The elements identified by the INP Debugger may cause slow interactions, but if users only interact with them very rarely, that might not be a priority to fix. But for a perfect user experience, you would want both results to be in the green.<\/p>\n<h2 id=\"optimizing-slow-interactions\">Optimizing Slow Interactions<\/h2>\n<p>This is the ultimate objective, right? Once we have identified slow interactions — whether through a quick test with CrUX data or a real-time monitoring solution — we need to optimize them so their delays are at least under 500ms, but ideally under 200ms.<\/p>\n<p>Optimizing INP comes down to CPU activity at the end of the day. But as we now know, INP measures two additional components of interactions that FID does not for a total of three components: <strong>input delay<\/strong>, <strong>processing time<\/strong>, and <strong>presentation delay<\/strong>. Each one is an opportunity to optimize the interaction, so let\u2019s break them down.<\/p>\n<h3 id=\"reduce-the-input-delay\">Reduce The Input Delay<\/h3>\n<p>This is what FID is solely concerned with, and it\u2019s the time it takes between the user\u2019s input, such as a click, and for the interaction to start.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/5-diagram-fid-relation-total-blocking-time-ui-update.jpg\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"389\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/5-diagram-fid-relation-total-blocking-time-ui-update.jpg\" alt=\"Diagram showing FID in relation to Total Blocking Time and UI update.\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/5-diagram-fid-relation-total-blocking-time-ui-update.jpg\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>This is where the <strong>Total Blocking Time (TBT)<\/strong> metric is a good one because it looks at CPU activity happening on the main thread, which adds time for the page to be able to respond to a user\u2019s interaction. TBT does not count toward Google\u2019s search rankings, but FID and INP do, and both are directly influenced by TBT. So, it\u2019s a pretty big deal.<\/p>\n<p>You will want to heavily audit what tasks are running on the main thread to improve your TBT and, as a result, your INP. Specifically, you want to watch for <strong>long tasks<\/strong> on the main thread, which are those that take more than 50ms to execute. You can get a decent visualization of tasks on the main thread in DevTools:<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/6-safari-devtools-timelines-report.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"538\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/6-safari-devtools-timelines-report.png\" alt=\"Safari DevTools Timelines report\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n The \u201cTimelines\u201d feature in Safari DevTools records the page load and produces a timeline of activity that can be broken down by network requests, layout and rendering, JavaScript and events, and CPU. Chrome and Firefox offer the same features but may look a little different, as browsers tend to do. (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/6-safari-devtools-timelines-report.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>The bottom line: <strong>Optimize those long tasks!<\/strong> There are plenty of approaches you could take depending on your app. Not all scripts are equal in the sense that one may be executing a core feature while another is simply a nice-to-have. You\u2019ll have to ask yourself:<\/p>\n<ul>\n<li><strong>Who<\/strong> is the script serving?<\/li>\n<li><strong>When<\/strong> is it served?<\/li>\n<li><strong>Where<\/strong> is it served from?<\/li>\n<li><strong>What<\/strong> is it serving?<\/li>\n<\/ul>\n<p>Then, depending on your answers, you have plenty of options for how to optimize your long tasks:<\/p>\n<ul>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2023\/04\/potential-web-workers-multithreading-web\/\">Use Web Workers<\/a> to establish separate threads for tasks to get scripts off the main thread.<\/li>\n<li><a href=\"https:\/\/www.smashingmagazine.com\/2022\/02\/javascript-bundle-performance-code-splitting\/\">Split JavaScript bundles<\/a> into individual pieces for smaller payloads.<\/li>\n<li><a href=\"https:\/\/www.debugbear.com\/blog\/async-vs-defer?utm_campaign=sm-3\">Async or defer scripts<\/a> that can run later without affecting the initial page load.<\/li>\n<li><a href=\"https:\/\/web.dev\/articles\/preconnect-and-dns-prefetch\">Preconnect network connections<\/a>, so browsers have a hint for other domains they might need to connect to. (It\u2019s worth noting that this could reveal the user\u2019s IP address and <a href=\"https:\/\/css-tricks.com\/bunny-fonts\/\">conflict with GDPR compliance<\/a>.)<\/li>\n<\/ul>\n<p>Or, nuke any scripts that might no longer be needed!<\/p>\n<h3 id=\"reduce-processing-time\">Reduce Processing Time<\/h3>\n<p>Let\u2019s say the user\u2019s input triggers a heavy task, and you need to serve a bunch of JavaScript in response — heavy enough that you know a second or two is needed for the app to fully process the update.<\/p>\n<ul>\n<li>Try creating a loading state that triggers immediately and <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/setTimeout\">perform the work in a <code>setTimeout()<\/code> callback<\/a> because that\u2019s a much quicker way to respond to the user interaction than waiting for the complete update.<\/li>\n<li>If you\u2019re working in React, make sure you are <a href=\"https:\/\/www.debugbear.com\/blog\/react-rerenders?utm_campaign=sm-3\">preventing your components from re-rendering unnecessarily<\/a>.<\/li>\n<li>Remember that <code>alert()<\/code>, <code>confirm()<\/code>, and <code>prompt()<\/code> are capable of adding to the total processing time as they run synchronously and block the main thread. That said, it appears <a href=\"https:\/\/twitter.com\/mmocny\/status\/1679110039880040449\">there could be plans to change that behavior<\/a> ahead of INP becoming a formal Core Web Vital.<\/li>\n<\/ul>\n<h3 id=\"reduce-presentation-delay\">Reduce Presentation Delay<\/h3>\n<p>Reducing the time it takes for the presentation is really about reducing the time it takes the browser to display updates to the UI, paint styles, and do all of the calculations needed to produce the layout.<\/p>\n<p>Of course, this is entirely dependent on the complexity of the page. That said, there are a few things to consider to help decrease the gap between when an interaction\u2019s callbacks have finished running and when the browser is able to paint the resulting visual changes.<\/p>\n<p>One thing is being mindful of <strong>the overall size of the DOM<\/strong>. The bigger the DOM, the more HTML that needs to be processed. That\u2019s generally true, at least, even though <a href=\"https:\/\/web.dev\/articles\/dom-size-and-interactivity#how_can_i_reduce_dom_size\">the relationship between DOM size and rendering isn\u2019t exactly 1:1<\/a>; the browser still needs to work harder to render a larger DOM on the initial page load and when there\u2019s a change on the page. That link will take you to a deep explanation of what contributes to the DOM size, how to measure it, and approaches for reducing it. The gist, though, is trying to <strong>maintain a flat structure<\/strong> (i.e., limit the levels of nested elements). Additionally, reviewing your CSS for overly complex selectors is another piece of low-hanging fruit to help move things along.<\/p>\n<p>While we\u2019re talking about CSS, you might consider looking into the <code>content-visibility<\/code> property and how it could possibly help reduce presentation delay. It comes with a lot of considerations, but if used effectively, it can provide the browser with a hint as far as which elements to defer fully rendering. The idea is that we can render an element\u2019s layout containment but skip the paint until other resources have loaded. <a href=\"https:\/\/css-tricks.com\/more-on-content-visibility\/\">Chris Coyier explains how and why that happens<\/a>, and there are <a href=\"https:\/\/html5accessibility.com\/stuff\/2020\/08\/25\/short-note-on-content-visibility-hidden\/\">aspects of accessibility to bear in mind<\/a>.<\/p>\n<p>And remember, if you\u2019re outputting HTML from JavaScript, that JavaScript will have to load in order for the HTML to render. That\u2019s a potential cost that comes with many single-page application frameworks.<\/p>\n<h2 id=\"gain-insight-on-your-real-user-inp-breakdown\">Gain Insight On Your Real User INP Breakdown<\/h2>\n<p>The tools we\u2019ve looked at so far can help you look at specific interactions, especially when testing them on your own computer. But how close is that to what your actual visitors experience?<\/p>\n<p><strong>Real user-monitoring (RUM)<\/strong> lets you track how responsive your website is in the real world:<\/p>\n<ul>\n<li>What pages have the slowest INP?<\/li>\n<li>What INP components have the biggest impact in real life?<\/li>\n<li>What page elements do users interact with most often?<\/li>\n<li>How fast is the average interaction for a given element?<\/li>\n<li>Is our website less responsive for users in different countries?<\/li>\n<li>Are our INP scores getting better or worse over time?<\/li>\n<\/ul>\n<p>There are many RUM solutions out there, and <a href=\"https:\/\/www.debugbear.com\/real-user-monitoring?utm_campaign=sm-3\">DebugBear RUM<\/a> is one of them.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/7-debugbear-rum.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"516\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/7-debugbear-rum.png\" alt=\"DebugBear RUM\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/7-debugbear-rum.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<p>DebugBear also supports the proposed <a href=\"https:\/\/www.debugbear.com\/blog\/long-animation-frames\">Long Animation Frames API<\/a> that can help you identify the source code that\u2019s responsible for CPU tasks in the browser.<\/p>\n<figure class=\"\n \n break-out article__image\n \n \n \"><\/p>\n<p> <a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/8-long-animation-frames-api.png\"><\/p>\n<p> <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"397\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/8-long-animation-frames-api.png\" alt=\"Long Animation Frames API\" \/><\/p>\n<p> <\/a><figcaption class=\"op-vertical-bottom\">\n (<a href=\"https:\/\/files.smashing.media\/articles\/preparing-interaction-next-paint-web-core-vital\/8-long-animation-frames-api.png\">Large preview<\/a>)<br \/>\n <\/figcaption><\/figure>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>When Interaction to Next Paint makes its official debut as a Core Web Vital in March 2024, we\u2019re gaining a better way to measure a page\u2019s responsiveness to user interactions that is set to replace the First Input Delay metric.<\/p>\n<p>Rather than looking at the input delay of the first interaction on the page, we get a high-definition evaluation of the least responsive component on the page — including the <strong>input delay<\/strong>, <strong>processing time<\/strong>, and <strong>presentation delay<\/strong> — whether it\u2019s the first interaction or another one located way down the page. In other words, INP is a clearer and more accurate way to measure the speed of user interactions.<\/p>\n<p>Will your app be ready for the change in March 2024? You now have a roadmap to help optimize your user interactions and prepare ahead of time as well as all of the tools you need, <a href=\"https:\/\/www.debugbear.com\/inp-debugger?utm_campaign=sm-3\">including a quick, free option from the team over at DebugBear<\/a>. This is the time to get a jump on the work; otherwise, you could find yourself with unidentified interactions that exceed the 500ms threshold for a \u201cpassing\u201d INP score that negatively impacts your search engine rankings\u2026 and user experiences.<\/p>\n<div class=\"signature\">\n <img decoding=\"async\" src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" \/><br \/>\n <span>(yk, il)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Preparing For Interaction To Next Paint, A New Web Core Vital Preparing For Interaction To Next Paint, A New Web Core Vital Geoff Graham 2023-12-07T21:00:00+00:00 2024-08-30T10:05:08+00:00 This article is sponsored by DebugBear There\u2019s a change coming to the Core Web Vitals lineup. If you\u2019re reading this before March 2024 and fire up your favorite performance […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-505","post","type-post","status-publish","format-standard","hentry","category-performance"],"_links":{"self":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/505"}],"collection":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/comments?post=505"}],"version-history":[{"count":1,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/505\/revisions"}],"predecessor-version":[{"id":506,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/505\/revisions\/506"}],"wp:attachment":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/media?parent=505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/categories?post=505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/tags?post=505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}