Interaction to Next Paint became a stable Core Web Vital in March 2024, and for Adobe Commerce stores on Hyvä it has been the most interesting metric to optimize. LCP and CLS responded relatively well to the Luma-to-Hyvä migration, Hyvä’s smaller JavaScript surface shipped a fast first paint by default. INP is a different story. The metric measures how long the browser is busy after a user interaction, and Hyvä’s Alpine.js components, when not carefully written, can stall the main thread enough to push INP above the 200ms “good” threshold even on otherwise fast pages.
This piece is a working playbook for engineering teams optimizing INP on Hyvä-based Adobe Commerce storefronts. It assumes Hyvä 1.3+ and PHP 8.3, and it focuses on the diagnostic techniques and patterns that have produced measurable improvements in production. Bemeir’s Hyvä performance practice has run INP audits across enterprise retailers, mid-market DTC brands, and B2B catalogs, and the patterns below are the ones that have generalized across categories.
What INP Actually Measures
Before tuning, it helps to be precise about the metric. INP records the longest event duration (from input to the next rendered frame) across a user’s session on a page. The browser samples every click, tap, and keypress, and reports the slowest one. A page with 99 fast interactions and one slow one is scored on the slow one.
This matters because INP cannot be improved by optimizing the “average” interaction. The work has to find the worst interaction on the page and fix it. That worst interaction is usually a specific component handler that does too much work synchronously, and the diagnostic process is about narrowing down to it.
Google’s INP documentation is the authoritative reference for the metric definition and measurement.
Field Data Before Lab Data
Start with field data from the Chrome User Experience Report (CrUX) or your own Real User Monitoring. The Lighthouse INP score in a synthetic test is useful for regression testing but is not how the metric is actually computed in production. CrUX gives you the 75th-percentile INP of real users, segmented by device, geography, and page type.
For most Adobe Commerce stores the relevant CrUX segmentation is: mobile vs desktop, and PDP vs PLP vs cart vs checkout. INP problems often concentrate on a single page type, and once you know where the problem lives, the diagnostic work narrows considerably.
If you don’t have CrUX coverage (it requires enough traffic), Chrome DevTools’ Performance panel with the Web Vitals extension installed will surface INP during recorded interactions in production. The web-vitals JavaScript library can be added to any storefront to capture INP from real users into your own analytics pipeline.
Long Tasks: The Most Common Cause
The most common INP regression on Hyvä storefronts is a long task, JavaScript work that holds the main thread for more than 50ms. Hyvä’s Alpine.js components can produce long tasks when they hydrate large DOM trees on first interaction, when reactive state updates trigger cascading re-renders, or when third-party scripts (analytics, A/B testing, chat widgets) hijack the main thread.
To find them, open Chrome DevTools, switch to the Performance panel, and start a recording. Interact with the page in the way users do, open a mini-cart, expand a product variant selector, type into a search box. Stop the recording and look at the Main thread track. Any block longer than 50ms is a long task. Look at the call stack to identify which JavaScript file and function is responsible.
Common culprits in Hyvä builds:
- Tailwind’s JIT compiler running in development mode in production (never ship the JIT compiler to production)
- Alpine.js `x-for` loops over large arrays without proper keys
- `x-data` initializers that perform synchronous DOM queries on every component instance
- Third-party tag managers loading dozens of scripts on first interaction
- Image lazy-loading libraries that handle hundreds of images on a single PLP
Hydration Cost on First Interaction
Hyvä is server-rendered with minimal client hydration, which is one of the reasons it ships fast LCP. But the hydration cost has to land somewhere, and on stores with many Alpine components, that cost concentrates on the first user interaction. The user clicks something, and Alpine has to initialize the component tree before responding. The result is a high INP score on the first click and lower scores on subsequent clicks.
The fix is to spread hydration over time rather than concentrate it on first interaction. A few patterns that help:
- Use `x-init` only for components that genuinely need initialization. For static or near-static components, render server-side and skip the client component entirely.
- Defer non-critical components to `requestIdleCallback` so they hydrate during browser idle time rather than on user interaction.
- Mark below-the-fold components as `loading=”lazy”` equivalents, hydrating them only when they scroll into view.
- Use `prefers-reduced-motion` and other client-context hints to skip components that the current user does not need.
Bemeir’s Hyvä migration team has documented these patterns across enterprise builds in the firm’s Hyvä performance practice, and the same patterns apply equally to Hyvä Checkout and to custom Hyvä modules built on top of the base theme.
Event Handler Throttling and Debouncing
Event handlers attached to high-frequency events (scroll, mousemove, input) are a classic INP trap. Even if each handler invocation is fast, the cumulative cost during a single interaction can blow the budget. Debounce input handlers, throttle scroll handlers, and consider passive event listeners for scroll and touch events.
A specific Hyvä trap: search-as-you-type components that fire requests on every keystroke. The handler itself may be fast, but the network response triggers a DOM update that holds the main thread. Add a 200ms debounce minimum, and consider rendering the search results in a way that does not block the next user input.
| INP cause | Diagnostic signal | Typical fix |
|---|---|---|
| Long task from Alpine hydration | DevTools long-task warning on first click | Defer hydration, lazy-load components |
| Tag manager script storm | Many small tasks clustered after consent | Move tags to web worker, restructure consent |
| Search-as-you-type handler | INP spikes when typing in search | Debounce 200ms minimum, async results |
| Cascading reactive updates | INP spikes on variant selection | Restructure state, avoid x-for on large arrays |
| Synchronous storage access | INP spikes on cart interaction | Replace localStorage reads with cached state |
| Image library bulk operations | INP spikes on first scroll | Native lazy-loading, native intersection observer |
Third-Party Scripts: The Hidden Cost
Most INP problems on production Hyvä stores trace back to third-party scripts. The pattern is consistent: the developer’s local Hyvä build measures INP under 100ms, the staging environment looks fine, and production INP is 400ms because of analytics, chat, A/B testing, recommendation widgets, and other tags. The tags individually look cheap. Together they consume the entire main thread budget.
The fix is to apply the same discipline to third-party scripts as to your own code. Measure each tag’s impact in isolation. Consider moving tags to a web worker via Partytown or equivalent. Defer tags that do not need to run on first paint. Negotiate with vendors whose scripts are particularly heavy, most will offer a lighter variant if you push back.
For Adobe Commerce specifically, the official Hyvä Tag Manager documentation covers patterns for managing tags without blocking the main thread.
Checkout INP
The checkout is the highest-stakes page for INP. Customers interact heavily during checkout, and any slow interaction directly correlates with abandonment. Hyvä Checkout was rebuilt specifically to address INP and other Core Web Vitals on the checkout flow, and stores still on the legacy Magento checkout almost always benefit from migrating.
For stores already on Hyvä Checkout, the remaining INP work tends to focus on payment provider integrations, address validation, and shipping calculation. Each of these triggers async work that can chain into long tasks if the integration is naive. The patterns above, debouncing, deferring, throttling, apply equally to checkout.
Measuring the Improvement
Track INP improvements in CrUX over the next 28 days after each change. CrUX reports are updated monthly, with a rolling 28-day window. Lab tests show direction; CrUX shows whether the change actually reached real users.
A reasonable improvement target for a Hyvä INP optimization sprint is moving 75th-percentile mobile INP from “needs improvement” (200-500ms) to “good” (under 200ms). The work usually takes four to eight weeks of focused engineering. Bemeir’s Adobe Commerce performance engagements often pair INP work with LCP and CLS optimization in a unified Core Web Vitals sprint, which is the cheapest way to address all three metrics in parallel.
The Pattern That Holds
The teams that ship fast INP on Hyvä have one thing in common: they measure in production, they hunt the worst interaction rather than the average, and they treat third-party scripts with the same rigor as first-party code. INP is the metric where the difference between an experienced Hyvä team and a less experienced one shows up most quickly, because everything has to be right at the same time. The good news is that the patterns are well-understood and the diagnostic tools are excellent. With a structured approach, getting Hyvä stores into the green on INP is a reliably solvable problem.
