Hyvä storefronts typically launch with strong INP scores – that is one of the major reasons retailers migrate to Hyvä in the first place. The pattern that emerges over time, however, is that INP regresses as the team ships new features, integrates new third-party scripts, and adds complexity to interactive components. By month twelve after launch, a Hyvä storefront’s INP can be meaningfully worse than at launch, and the team often does not realize it because the regression happened incrementally.
This article describes the INP optimization playbook for Hyvä storefronts specifically. The techniques differ from generic INP advice because Hyvä’s architecture changes which interventions matter. Alpine.js components have different optimization patterns than RequireJS modules. The TailwindCSS-based design system changes the layout cost characteristics. The lean JavaScript baseline means that third-party scripts have proportionally larger impact on the metric.
Measure INP Where It Matters
INP measurement on Hyvä should be done with Real User Monitoring rather than synthetic testing. The web-vitals JavaScript library provides the canonical INP measurement implementation. Once instrumented, the measurement should be segmented by interaction type (click, tap, keyboard input, scroll), by page template, by device class, and by component (which interactive element produced the worst INP).
The segmentation matters because INP at the page level often hides component-level problems. A PDP that has acceptable aggregate INP might have a “Add to Cart” button with terrible INP that is being averaged with cheaper interactions. The optimization should target the worst-performing components, not the aggregate, because the worst interactions are the ones that frustrate customers and pull down conversion.
The diagnostic move is to look at INP at the ninety-fifth percentile (not just the seventy-fifth) for the most important interactions on each template. The ninety-fifth percentile shows you the tail experience – what is happening when things go wrong – and that tail experience is what produces the abandonment and frustration that conversion analytics surface as a problem.
Alpine.js Patterns That Affect INP
Hyvä’s Alpine.js architecture is much more efficient than Luma’s RequireJS, but it still produces INP issues when used poorly. The common patterns that produce INP problems include expensive computed properties triggered on every interaction, synchronous mutations to large reactive objects, watchers that trigger cascading updates, and components that re-render large DOM subtrees on small state changes.
The fix patterns include moving expensive computation out of computed properties and into memoized helpers, splitting large reactive objects into smaller ones so mutations don’t trigger updates to unaffected fields, using x-cloak to defer initialization of below-the-fold components, and using x-intersect to lazy-initialize components only when they enter the viewport.
The diagnostic technique that works well for Alpine.js is the Chrome DevTools Performance panel recorded during a representative user interaction. The recording shows main-thread time spent in Alpine.js initialization, in mutation observers, and in event handlers, which surfaces which component is producing the INP cost. Combining the DevTools recording with field data from RUM gives you both the synthetic detail and the real-user validation.
Third-Party Script Impact on Hyvä INP
Hyvä’s lean JavaScript baseline means that third-party scripts have proportionally larger impact on INP than they do on Luma. A storefront where the first-party JavaScript runs in 50ms and the third-party scripts run for 400ms is going to have INP dominated by the third-party scripts. The Hyvä migration improved the first-party performance but exposed the third-party drag.
The audit pattern is to identify every third-party script loading on the storefront, measure the main-thread time each script consumes, classify each script by criticality (must-run-on-load, can-run-deferred, can-run-on-interaction, candidate-for-removal), and execute the reclassification in the script loading strategy. Most storefronts find that thirty to forty percent of their scripts can be deferred or removed, with corresponding INP improvement.
The execution pattern uses defer and async attributes where appropriate, Partytown for scripts that can run on a web worker (analytics, social pixels), and requestIdleCallback for scripts that should run when the browser is idle. The combination typically reduces third-party main-thread contribution by fifty to seventy percent.
Event Handler Patterns That Hurt INP
Interactive components on Hyvä storefronts can have INP issues from event handlers that do too much work in the synchronous path. The pattern is that a click handler runs through validation, state mutation, analytics tracking, and DOM updates all in the synchronous call, with the cumulative time exceeding the INP threshold.
The fix patterns include splitting handlers into synchronous critical-path work and deferred non-critical work, using scheduler.yield where available to yield the main thread between phases, debouncing or throttling handlers for rapid-fire events (scroll, mousemove, resize), and using passive event listeners where the handler doesn’t need to prevent default behavior.
A common Hyvä-specific pattern is the “Add to Cart” button that runs cart state mutation, mini-cart update, analytics event, and recommendation refresh all in the synchronous handler. The fix is to do the immediate visual feedback synchronously (button state change, cart count update) and defer everything else with a setTimeout or scheduler.yield. The user sees instant response; the heavier work happens in the background.
Hydration and Re-Initialization Costs
Hyvä’s Alpine.js components hydrate on page load, and the hydration cost contributes to early-page INP. The cost is usually small for well-structured components but can become substantial when many components hydrate simultaneously or when individual components have expensive initialization.
The optimization patterns are to defer non-critical components to lazy initialization using x-intersect or scheduler.postTask, to split large components into smaller ones with isolated initialization, to avoid expensive computation in component initialization paths, and to use x-cloak strategically to hide components until they are ready rather than allowing partial-render states.
The diagnostic move is to look at INP for interactions that happen during the first two seconds of page load. If those INPs are substantially worse than INPs later in the session, the hydration cost is the contributor and the lazy-init pattern is the fix.
| Hyvä INP Optimization | When It Applies | Typical Improvement |
|---|---|---|
| Third-party script audit | Always – first move | 30–50% INP reduction |
| Alpine.js component refactor | Components with heavy state | 20–40% INP reduction on those components |
| Lazy component initialization | Many components on page | 100–300ms reduction on early-page INP |
| Event handler splitting | Heavy click handlers | 100–250ms reduction per affected interaction |
| Reactive object splitting | Large state objects | 50–150ms reduction on mutations |
| Worker offloading via Partytown | Heavy analytics/pixels | 200–500ms reduction in third-party time |
What Tooling to Use
The tooling for Hyvä INP optimization has matured in 2026. The web-vitals library handles the measurement. Chrome DevTools Performance panel handles synthetic profiling. RUM platforms (SpeedCurve, New Relic, Datadog) handle field-data aggregation. PageSpeed Insights provides synthetic scoring and surfaces optimization opportunities though it should not be the primary measurement source.
For Alpine.js-specific tooling, the Alpine.js DevTools extension provides component inspection that surfaces reactive update patterns. The extension is useful for diagnosing which Alpine.js components are producing expensive updates and where the optimization should focus.
For third-party script auditing, Request Map Generator visualizes the script dependency chain and surfaces the cumulative cost. Lighthouse’s “Reduce the impact of third-party code” audit provides per-script timing that informs the prioritization.
Sustaining the Improvements
INP optimization on Hyvä is not a one-time project. The improvements regress as the team ships new features and integrates new scripts unless there is ongoing discipline. The discipline includes a CWV gate in the CI/CD process that catches regressions before they reach production, a quarterly third-party script audit that prunes accumulated scripts, an INP review in the development workflow for any new interactive component, and a quarterly RUM review that surfaces emerging issues before they become serious.
The discipline costs ongoing engineering time but is much cheaper than the cyclical pattern of optimization followed by regression. Retailers who build the discipline produce sustained good scores; retailers who treat optimization as a one-time project produce the same problem every twelve months.
Bemeir’s Hyvä practice builds this ongoing discipline into post-launch engagement structures. The pattern is to deliver the initial migration with strong CWV scores, then operate ongoing CWV monitoring and intervention as part of the steady-state engagement. The structure has produced sustained good scores across Hyvä clients rather than the regression pattern that ad-hoc optimization produces. For the broader Adobe Commerce performance practice, Hyvä is one of several interventions; INP optimization within Hyvä is the discipline that keeps the migration’s value compounding over time.
For deeper reference, Hyvä Themes’ official documentation provides the platform-level reference, the Alpine.js documentation provides the JavaScript framework reference, and the Adobe Commerce DevDocs performance section provides the platform context. Web.dev’s INP optimization guide provides the canonical technical reference for the metric and its optimization patterns.
