Adobe Commerce INP Optimization: Why Your Store Feels Slow Even When Page Speed Looks Fine

Learn why your Adobe Commerce store fails Interaction to Next Paint (INP), how it silently hurts conversion, and how Hyvä's architecture delivers instantly responsive storefronts.

Your Largest Contentful Paint is under 2.5 seconds. Your Cumulative Layout Shift is clean. Your Lighthouse score looks respectable. But customers keep telling you the store feels slow — and your conversion rate is stuck below where it should be.

The problem might be hiding in the metric most Adobe Commerce merchants never check: Interaction to Next Paint (INP).

INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. Unlike LCP, which measures how fast your page loads, INP measures how fast your page responds when someone clicks a button, selects a dropdown, or adds a product to cart. And for Adobe Commerce stores running Magento’s default Luma theme, it is often the weakest link in your performance profile.

What INP Actually Measures

INP tracks the full lifecycle of a user interaction. When a visitor clicks “Add to Cart,” INP measures three phases:

1. Input delay — the time from the click until the browser starts processing your event handler
2. Processing time — how long your JavaScript event handler takes to execute
3. Presentation delay — the time for the browser to render the visual result of that interaction

Google considers an INP score good at 200 milliseconds or below. Scores between 200–500ms need improvement. Above 500ms is poor. For context, a 500ms INP means half a second between clicking a button and seeing anything happen. On a mobile device with a slow CPU, that can stretch to over a second.

Here is the critical difference from the old FID metric: FID only measured the first interaction on a page, and only the input delay portion. INP measures the worst interaction throughout the entire page lifecycle. That means every add-to-cart click, every quantity change, every filter toggle, every mini-cart open — the slowest one defines your score.

Why Adobe Commerce Stores Struggle With INP

Adobe Commerce’s default frontend stack creates several structural challenges for INP performance.

The JavaScript Layer Problem

The Luma theme ships with a heavy JavaScript stack: jQuery, Knockout.js, RequireJS, and dozens of Magento-specific modules. When a user interacts with a product page, that click often triggers a chain of JavaScript operations — Knockout observables update, multiple RequireJS modules load, jQuery DOM manipulations cascade. Each step adds processing time.

On a product detail page with configurable options, the interaction path might look like: user selects a swatch → Knockout re-evaluates the product configuration → AJAX call fetches updated pricing → DOM re-renders the price block → inventory check updates availability. If that chain takes 350ms, your INP is already in the “needs improvement” range.

Third-Party Script Accumulation

Most Adobe Commerce stores accumulate third-party scripts over time: analytics platforms, chat widgets, personalization engines, A/B testing tools, tag managers. Each one adds event listeners and JavaScript execution to the main thread. When a user interacts with the page, the browser must process all registered event handlers — not just the one relevant to that interaction.

Research from RUMvision and others consistently shows that third-party scripts are the single largest contributor to poor INP scores on ecommerce sites. The problem compounds: each new tool added by marketing degrades the performance that engineering works to improve.

B2B Complexity Multiplies the Problem

B2B Adobe Commerce stores face additional INP challenges. Quick order forms with quantity grids, tiered pricing lookups that require real-time API calls, multi-step checkout with address validation, dealer portal navigation with account switching — each of these interactions is heavier than a typical B2C click. For manufacturers and distributors running complex catalogs with ERP-integrated pricing, the INP problem is structurally harder.

The INP-to-Revenue Connection

INP is not an abstract technical metric. It directly impacts conversion, and the numbers are significant.

Deloitte’s research found that a 100ms improvement in site speed can increase conversions by 8.4% and grow basket size by 9.2%. INP specifically measures perceived responsiveness — the subjective feeling of whether a site is fast or sluggish. When clicking “Add to Cart” produces no visible response for 400ms, users start to doubt whether their action registered. Some click again (creating duplicate actions). Others abandon.

For B2B stores, the stakes are higher. A buyer placing a $50,000 order expects the same responsiveness they get from consumer sites. When quantity updates, pricing tiers, and shipping calculations each introduce noticeable delays, the purchasing experience feels unreliable. In our work with B2B manufacturers at Creatuity, we have seen INP improvements of 200ms+ translate directly into higher order completion rates and larger average order values.

Google also uses INP as a ranking signal. Stores with poor INP may see lower organic visibility, compounding the revenue impact through reduced traffic in addition to reduced conversion.

How Hyvä’s Architecture Solves INP at the Root

This is where Hyvä’s approach to the Adobe Commerce frontend makes a structural difference — not through incremental optimization, but by fundamentally reducing the JavaScript that the browser must process on every interaction.

Alpine.js Instead of Knockout/jQuery

Hyvä replaces Magento’s jQuery + Knockout.js stack with Alpine.js, a lightweight reactive framework (~15KB vs. Magento’s combined ~300KB+ for jQuery and Knockout alone). Alpine.js runs directly in the browser without a build step, and its reactivity model produces far less main-thread work per interaction.

When a user clicks a swatch on a Hyvä product page, Alpine handles the state change and DOM update in a single reactive cycle — no RequireJS module loading, no Knockout observable chain, no jQuery DOM manipulation. The interaction completes faster because there is simply less code executing.

Tailwind CSS Instead of LESS/Bootstrap

Hyvä uses Tailwind CSS with aggressive purging, meaning only the CSS classes actually used on the page are shipped. Default Magento themes ship hundreds of kilobytes of unused CSS. While CSS does not directly affect INP’s JavaScript processing time, it reduces overall page weight and parsing time, which creates more main-thread headroom for interaction handling.

No RequireJS Overhead

Perhaps the most impactful INP improvement: Hyvä eliminates RequireJS entirely. In Luma, interaction handlers often trigger lazy-loaded modules through RequireJS, which adds a module resolution and fetch step to every interaction. Hyvä loads its JavaScript upfront as native ES modules, so when a user interacts, the handler code is already parsed and ready.

Practical INP Optimization Strategies for Adobe Commerce

Whether you are running Hyvä or still on Luma, these strategies will improve your INP scores.

1. Audit Third-Party Scripts Ruthlessly

Run a third-party script audit using Chrome DevTools’ Performance panel or WebPageTest. For each script, ask:

• Does this tool still provide value proportional to its performance cost?
• Can it be loaded asynchronously or deferred until after the initial interaction window?
• Can it be replaced with a lighter alternative?

Common culprits on Adobe Commerce stores: tag managers loading synchronously, chat widgets that inject heavy bundles, and personalization tools that block the main thread during interactions.

2. Break Up Long JavaScript Tasks

INP is fundamentally a main-thread metric. Any JavaScript task that runs longer than 50ms is considered a “long task” and will contribute to poor INP. Use requestIdleCallback() or scheduler.yield() to break long tasks into smaller chunks that allow the browser to process user interactions between them.

For custom Adobe Commerce modules, this means restructuring event handlers that do multiple things (update UI + fetch data + trigger analytics) into prioritized sequences where the visual update happens first.

3. Optimize Product Configurator Interactions

Configurable products are typically the worst INP offenders on Adobe Commerce stores. Each swatch selection triggers price recalculation, inventory checks, and image updates. Strategies:

• Pre-fetch pricing for visible configurations on page load
• Use optimistic UI updates (show the change immediately, reconcile data in the background)
• Debounce rapid sequential selections to avoid processing stale intermediate states

4. Implement Performance Governance

INP degrades over time as new scripts, features, and integrations are added. Without governance, a store that scores well today will regress within months. Establish:

• INP budgets per page type (e.g., PDP INP must stay below 150ms)
• Automated monitoring via RUM (Real User Monitoring) tools like RUMvision or SpeedCurve
• Regression alerts that trigger when INP exceeds thresholds on key pages
• Pre-launch checks that block deployments introducing INP regressions above the budget

For a deeper framework on managing this discipline, see our Adobe Commerce Core Web Vitals playbook covering governance cadences and operational checklists.

5. Consider the Hyvä Migration Path

For stores still on Luma, migrating to Hyvä addresses INP at the architectural level rather than through constant patching. The migration eliminates the jQuery/Knockout/RequireJS stack, reduces JavaScript payload by 70-80%, and provides a frontend that passes Core Web Vitals — including INP — out of the box for most implementations.

Hyvä is not a different platform. It is a frontend layer built specifically for Adobe Commerce, maintaining full compatibility with Magento’s backend, extensions, and integrations. At Creatuity, we implement Hyvä as a performance-first frontend strategy, preserving existing backend logic while replacing the performance-bottlenecked presentation layer.

Monitoring INP: What to Measure and How

Unlike Lighthouse scores, which are synthetic lab data, INP should be measured with real user data. Google’s Chrome User Experience Report (CrUX) provides field data aggregated over 28-day windows. For faster feedback:

• Google Search Console shows INP pass/fail rates at the origin and URL level
• PageSpeed Insights displays both lab and field INP data side by side
• RUM tools (RUMvision, SpeedCurve, Datadog RUM) provide real-time INP measurements per page, device, and geography

The 28-day aggregation window in CrUX means that any INP fix you deploy will not appear in Google’s official data for nearly a month. Use RUM tools for immediate feedback on whether your optimizations are working.

Track INP by page type. Product pages, category pages with filters, and checkout pages typically have very different INP profiles. A store-wide average can mask severe problems on specific page types that matter most for conversion.

For a framework on quantifying the revenue impact of these improvements, see our guide on measuring ROI from Adobe Commerce performance investments.

The Bottom Line

INP is the Core Web Vital that most directly reflects how your customers experience your Adobe Commerce store. A fast-loading page that feels sluggish when you interact with it creates the same outcome as a slow-loading page: lost revenue.

The fix is not another caching plugin or a CDN upgrade. It requires addressing the JavaScript architecture that processes every click, tap, and keystroke. Hyvä provides the strongest architectural foundation for INP performance on Adobe Commerce, but even stores on Luma can achieve meaningful improvements through script governance, task optimization, and interaction-level performance budgets.

If your Core Web Vitals report shows green for LCP and CLS but yellow or red for INP, you have found the gap between your technical performance and your customers’ actual experience.