Interaction to Next Paint (INP) measures how quickly your storefront visually responds after a shopper taps, clicks, or types. On a Hyva theme, most INP problems come from Alpine.js components doing too much work on the main thread at the wrong time. The fastest fix is deferring component initialization with the x-defer plugin, then trimming long tasks and heavy DOM work.
A Hyva migration usually improves INP on its own, because it strips the Luma JavaScript bundle down by roughly tenfold. But “better than Luma” is not the same as “passing.” INP became a Google Core Web Vital in March 2024, replacing First Input Delay, and the passing bar is 200 milliseconds or less at the 75th percentile of real-user data. Plenty of Hyva stores sit just over that line because a few Alpine components are heavy, or every component initializes at once on load. This guide is the playbook we use at Bemeir, the first US-based official Hyva Gold Partner, to get a Hyva storefront comfortably under the INP threshold.
What INP measures, and where Hyva starts
INP is a responsiveness metric. It watches every interaction a shopper makes during a page visit and reports close to the worst one: the time from the input to the next frame the browser paints in response. Three bands matter, all measured at the 75th percentile of field data:
| INP value | Rating | What shoppers feel |
|---|---|---|
| 200 ms or less | Good | Taps feel instant |
| 201 to 500 ms | Needs improvement | Noticeable lag on menus, filters, add-to-cart |
| Over 500 ms | Poor | Store feels stuck or broken |
The reason a Hyva build starts ahead is payload. A comparable page that shipped 700 KB to 1.2 MB of Luma JavaScript drops toward 50 to 100 KB on Hyva, because RequireJS, Knockout, and most jQuery are gone and Alpine.js is tiny by comparison. Less script to parse and execute means less main thread congestion, which improves Total Blocking Time, INP, and even LCP together. If you want the fuller before-and-after picture of what a migration does and does not fix, our breakdown of what a Hyva migration fixes when PageSpeed is below 40 covers the whole metric set.
The catch is that INP is driven by interactions, not by load. You can have a great LCP and still fail INP if the first tap on a mega menu or a layered-navigation filter triggers a long task.
Why Alpine.js can hurt INP
Hyva replaces Luma’s frontend model with inline Alpine.js and native JavaScript. Alpine is small and fast for most work, but it has one specific failure mode that maps directly onto INP: component initialization cost.
When Alpine boots, it walks the DOM and initializes every x-data component it finds. If a component wraps a large DOM branch, or does heavy computation in its init(), that work runs on the main thread and blocks the browser from responding to the shopper’s next tap. The Hyva performance documentation is blunt about the specific anti-patterns: large DOM branches inside a single Alpine component, frequent use of x-bind:class (or the :class shorthand), and direct setAttribute calls all add main thread work. On a category page with dozens of product tiles, a swatch component, a mega menu, and a cart drawer, that initialization can stack up into a long task right when the shopper wants to interact.
Two moves solve most of it: initialize fewer components up front, and make the components you do initialize lighter. Alpine and Hyva give you tools for both. Developers coming from the old stack should also read our guide on retraining a Magento frontend team from Knockout to Alpine, because several INP habits are the opposite of what Luma taught.
The x-defer plugin: Hyva’s primary INP lever
Hyva introduced the x-defer plugin in Hyva Theme 1.3.7 specifically to answer the INP change. It delays when Alpine components initialize, so the main thread is not choked at load by components the shopper cannot even see yet.
The most useful directive is x-defer="intersect". Add it to a component and Alpine holds off on initializing that component until it is about to scroll into the viewport. For a storefront, that means the footer newsletter widget, the below-the-fold product carousels, and the accordions at the bottom of a product page do not compete for the main thread while the shopper is interacting with the top of the page.
A few practitioner notes that separate a good x-defer implementation from a naive one:
- Do not defer everything. The Hyva docs warn directly that adding
x-deferto every component on a page can increase main thread blocking time instead of reducing it, because you trade one big init for many small scheduled ones. Defer below-the-fold and interaction-triggered components, not the ones the shopper touches first. - Keep above-the-fold components eager. The add-to-cart button, the primary swatch selector, and the header search should initialize normally so the first interaction is instant.
- Tune
deferSelectors. The plugin is driven by a selector configuration, so you can target component types across the theme rather than hand-editing every template. - It is portable. The mechanism ships as a drop-in snippet that works on any Alpine.js site, so the pattern is not locked to one Hyva version.
On most stores, correct x-defer placement is the single biggest INP win available, and it requires no rearchitecting.
A field-tested INP playbook for Hyva
Beyond x-defer, these are the techniques we apply in order, from highest to lowest impact. The table maps each one to what it actually moves.
| Technique | What you do | Primary effect |
|---|---|---|
| Defer off-screen components | x-defer="intersect" on below-the-fold Alpine blocks |
Cuts init long tasks at load |
| Keep hot components eager | Leave add-to-cart, swatches, search un-deferred | Protects first-interaction INP |
| Shrink component DOM | Split one giant x-data into smaller scoped components |
Lowers per-init cost |
Prefer x-if over x-show |
Keep conditional blocks out of the DOM until needed | Reduces DOM size and scan cost |
| AJAX heavy off-screen blocks | Load mega menu and cart drawer markup on demand | Smaller initial document |
Avoid :class and setAttribute churn |
Refactor hot paths to vanilla JS | Less reactive main thread work |
| Break up long tasks | Yield to the main thread inside heavy handlers | Frees the browser to paint |
| Debounce input handlers | Throttle search, filter, and quantity events | Fewer redundant tasks |
Two of these deserve expansion.
Use x-if instead of x-show for content that is not always visible. An element behind x-show still lives in the DOM and still gets scanned by Alpine; x-if keeps it out of the DOM entirely until its condition is met. Reserve x-show for content that must be indexable by search engines or that toggles very frequently, where re-inserting the node would cost more than keeping it.
Break up long tasks by yielding to the main thread. Any handler that runs longer than about 50 milliseconds is a long task and a direct INP risk. The web.dev guidance on optimizing long tasks covers the pattern: split the work and yield between chunks so the browser can respond to input and paint. In practice that means moving non-urgent work out of the click handler, deferring it with a scheduler yield or a timeout, and only doing the visually necessary part synchronously.
Defer third-party scripts, not just your own
A large share of Hyva INP failures are not caused by the theme at all. They are caused by analytics, tag managers, chat widgets, and marketing pixels that install heavy event listeners and run on the main thread. A store can pass INP on a clean staging build and fail in production purely because of what the tag manager loads.
Hyva builds in a lever for this. The theme dispatches an init-external-scripts event on the first user interaction, so you can hold analytics, tracking pixels, and marketing tools until the shopper actually engages rather than firing them during initial render. Wiring your third-party tags to that event keeps them off the main thread during the most INP-sensitive moments. Audit the tag manager the same way you audit your own components, because an unmanaged GTM container will quietly undo careful Alpine work.
Measuring INP properly
INP is a field metric, so lab tools only get you part of the way. A Lighthouse run in a Chrome tab reports a lab estimate, but the number Google ranks on is the 75th percentile of real Chrome User Experience Report data over 28 days. Trust field data over a single lab score.
A practical measurement loop:
- Baseline the field. Pull INP at the 75th percentile from the Chrome UX Report or your real-user monitoring, segmented by device. Mobile is almost always where INP fails first.
- Reproduce in the lab. Use Chrome DevTools performance traces to find the specific interaction and the long task behind it, then read which script and which component caused it.
- Fix the worst interaction first. INP reports near your worst interaction, so fixing the single heaviest tap moves the metric more than shaving milliseconds off ten fast ones.
- Confirm in the field. Field data lags, so verify improvement over the following weeks, not the same afternoon.
Because a lab win does not guarantee a field win, treat measurement as a discipline in its own right. Our guide to measuring a Hyva migration with lab scores versus field data explains why the 75th-percentile field number is the one that decides rankings.
FAQ
What is a good INP score for a Magento store?
A good INP is 200 milliseconds or less at the 75th percentile of real-user field data. Between 201 and 500 milliseconds needs improvement, and over 500 milliseconds is poor. INP became a Core Web Vital in March 2024, replacing First Input Delay, so it is now a Google ranking signal.
Does migrating to Hyva fix INP automatically?
A Hyva migration usually improves INP because it cuts the JavaScript payload by roughly tenfold versus Luma, which frees the main thread. It does not guarantee a passing score. Heavy Alpine components, everything initializing at once, and unmanaged third-party scripts can still push a Hyva store over the 200 millisecond threshold.
What is the x-defer plugin in Hyva?
x-defer is a Hyva plugin, introduced in Hyva Theme 1.3.7, that delays Alpine.js component initialization. Adding x-defer="intersect" holds off initializing a component until it nears the viewport, which keeps below-the-fold components from blocking the main thread while the shopper interacts with the top of the page.
Should I add x-defer to every Alpine component?
No. Hyva’s own documentation warns that deferring every component can increase main thread blocking time rather than reduce it. Defer below-the-fold and interaction-triggered components, and keep components the shopper touches first, like add-to-cart and search, initializing eagerly.
Why does my Hyva store still fail INP in production but pass in staging?
The usual cause is third-party scripts. Analytics, tag managers, chat widgets, and marketing pixels that are absent on staging install heavy main thread listeners in production. Hyva’s init-external-scripts event lets you defer those until the first user interaction.
Getting a Hyva store under the INP threshold
INP rewards restraint. A Hyva build gives you a large head start by shedding the Luma JavaScript weight, and from there the wins come from initializing fewer Alpine components up front, keeping the hot ones light, deferring the rest with x-defer, and refusing to let third-party tags run wild on the main thread. None of it requires a replatform, and most of it is configuration and disciplined component design rather than a rewrite.
Bemeir does this work as an extension of your team on both Magento and Adobe Commerce builds, and we bring the same performance discipline to Shopify and Shopify Plus, Shopware, and BigCommerce projects when a merchant runs one of those platforms. Our deep technology partner ecosystem means we can tune the third-party layer as carefully as the theme, and you can read more about how we work if that matters to you. If your Hyva storefront is stuck just over the INP line, talk to Bemeir and we will trace it to the interaction and fix it.
