Adobe Commerce INP Optimization: Fixing Interaction to Next Paint for Faster Stores

Learn how to diagnose and fix poor INP scores on Adobe Commerce. Discover why Interaction to Next Paint matters for ecommerce conversion and how Hyvä's architecture delivers measurably better responsiveness.

When a customer taps “Add to Cart” on your Adobe Commerce store, how long does the page take to respond? If the answer is more than 200 milliseconds, your store is failing a Core Web Vital that directly affects both search rankings and revenue.

Interaction to Next Paint (INP) replaced First Input Delay (FID) as an official Core Web Vital in March 2024, and it changed the performance conversation for ecommerce teams. Where FID only measured the delay before the browser started processing a single interaction, INP measures the full responsiveness of every interaction throughout a user’s session. For Adobe Commerce merchants, this shift exposed performance problems that FID had been hiding.

This guide explains what INP means for your Adobe Commerce store, identifies the most common causes of poor INP scores, and walks through the architectural and tactical fixes that bring interaction responsiveness in line with what Google — and your customers — expect.

What INP Measures and Why It Matters More Than FID

FID tracked a single metric: how long the browser waited before it began handling the first user interaction. A store could score well on FID even if every subsequent button click, dropdown selection, and form submission felt sluggish. FID was a narrow window into a broad problem.

INP observes every discrete interaction during a page visit — clicks, taps, and keyboard inputs — and reports the worst interaction latency (with some outlier adjustment). Google considers an INP score below 200ms as “good,” between 200ms and 500ms as “needs improvement,” and above 500ms as “poor.”

For ecommerce, this distinction is significant. A customer browsing a product detail page (PDP) might interact with size selectors, quantity fields, variant swatches, and the add-to-cart button in a single visit. Under FID, only the first of those interactions counted. Under INP, the slowest one sets your score.

Research consistently shows that interaction responsiveness correlates with conversion behavior. Pages that feel unresponsive — where tapping a button produces a visible delay — generate higher abandonment rates. When users cannot trust that their input was registered, they hesitate, retry, or leave. Every millisecond of perceived interaction delay compounds across your funnel.

The Adobe Commerce INP Problem: Common Offenders

Adobe Commerce’s default Luma frontend was designed before Core Web Vitals existed. Its JavaScript architecture creates several patterns that reliably produce poor INP scores.

RequireJS Module Loading

Luma uses RequireJS as its module loader. On interaction, RequireJS may need to resolve dependency chains and load additional JavaScript modules before the handler can execute. This deferred loading pattern means the first interaction with certain page elements triggers a cascade of synchronous script evaluation, blocking the main thread and inflating INP.

The result: a customer clicks a swatch or opens a minicart, and the browser stalls while it loads and evaluates JavaScript that should have been ready.

KnockoutJS Data Binding Overhead

Luma relies on KnockoutJS for UI data binding across the storefront — cart totals, shipping estimates, product options, and checkout forms all use Knockout observables. Each interaction that modifies bound data triggers a synchronous re-evaluation of the dependency graph. On complex pages with many bound elements, this re-evaluation blocks the main thread for tens or hundreds of milliseconds.

Checkout pages are the most common casualty. Changing a shipping method or applying a coupon code can trigger a cascade of observable updates that freezes the UI while the binding system recalculates.

Third-Party Script Contention

Analytics tags, chat widgets, personalization engines, and remarketing pixels compete for main-thread time. On Adobe Commerce stores running the default frontend, these scripts often load synchronously or attach event listeners that execute expensive operations on every interaction.

A single poorly-optimized third-party script can turn a 150ms interaction into a 400ms one — the difference between a “good” and “needs improvement” INP classification.

Long Tasks in Custom Modules

Custom Adobe Commerce modules frequently add JavaScript that performs synchronous DOM manipulation, runs complex calculations client-side, or makes blocking API calls in response to user interactions. Without deliberate optimization, each custom feature becomes a potential INP bottleneck.

How Hyvä’s Architecture Solves the INP Problem

Hyvä (opens in new tab) replaces Luma’s entire frontend stack, and the architectural differences have a direct impact on INP performance.

Alpine.js Instead of KnockoutJS

Where KnockoutJS maintains a complex observable dependency graph, Alpine.js uses a lightweight reactive model that updates only the DOM elements directly affected by a state change. The re-rendering scope is narrower, the evaluation cost is lower, and the main thread stays available for the browser to process the next paint.

In practice, interactions that trigger 200-400ms of KnockoutJS processing in Luma often complete in under 50ms with Alpine.js in Hyvä. The difference is architecturally inherent — not a matter of configuration tuning.

Eliminated RequireJS Dependency Chains

Hyvä removes RequireJS entirely. JavaScript is bundled and loaded as standard ES modules or inline Alpine.js components. There is no deferred module resolution on interaction, which eliminates the class of INP problems caused by lazy-loaded dependency chains.

Dramatically Reduced JavaScript Payload

A typical Luma storefront ships 300-500KB of parsed JavaScript. A comparable Hyvä storefront ships 50-100KB. Less JavaScript means less main-thread parsing time, fewer long tasks, and faster event handler execution. The INP benefit is mechanical: smaller scripts complete faster.

Tailwind CSS Instead of LESS Compilation

While CSS does not directly affect INP measurement, Hyvä’s use of Tailwind CSS produces smaller, more predictable stylesheets that reduce layout recalculation costs. When the browser needs to paint the result of an interaction, leaner CSS means the “next paint” arrives sooner.

Tactical INP Fixes for Adobe Commerce (With or Without Hyvä)

Whether your store runs Hyvä or Luma, these techniques reduce INP scores.

Audit and Defer Third-Party Scripts

Use Google Chrome DevTools Performance panel or WebPageTest (opens in new tab) to identify third-party scripts that execute during user interactions. Move non-critical scripts to defer or async loading. For scripts that must run, use requestIdleCallback or schedule execution during idle periods.

The goal: ensure that when a user interacts, the main thread is available for your store’s event handlers — not occupied by an analytics tag.

Break Up Long Tasks

The browser defines a “long task” as any single JavaScript execution that blocks the main thread for more than 50ms. Use the Long Tasks API or Chrome DevTools to identify these, then break them into smaller chunks using setTimeout(fn, 0), requestAnimationFrame, or the scheduler.yield() API.

For Adobe Commerce custom modules, this often means refactoring synchronous loops (iterating over cart items, recalculating totals) into asynchronous batches.

Optimize Event Handlers

Audit click and input handlers on interactive elements. Common issues include:

• Redundant DOM queries: Cache element references instead of querying the DOM on every interaction.
• Synchronous layout reads after writes: Batch DOM reads before writes to avoid forced reflows.
• Unbatched state updates: Group related state changes into a single update cycle.

Preload Critical Interaction Paths

For known high-value interactions (add-to-cart, variant selection, checkout form submission), ensure all required JavaScript is loaded and parsed before the user reaches that point. Use <link rel="modulepreload"> for critical modules and prefetch API endpoints that interaction handlers will call.

Reduce DOM Complexity

Large DOM trees slow down every interaction because the browser must traverse more nodes during style calculation and layout. Adobe Commerce stores with complex category pages (hundreds of products with multiple swatches each) often have DOM node counts exceeding 3,000 — well above the recommended threshold.

Implement virtual scrolling for long product lists, lazy-render below-the-fold content, and simplify nested wrapper elements.

Measuring INP on Adobe Commerce

Effective INP optimization requires measurement in both lab and field contexts.

Lab tools (synthetic testing):

• Chrome DevTools Performance panel: Records interaction traces and highlights long tasks. Use the “Interactions” track to see exactly which interaction produced the worst latency.
• Lighthouse: Reports INP in its performance audit, though lab-based INP can differ significantly from field data.
• WebPageTest: Supports interaction scripting that can simulate clicks and measure response latency.

Field tools (real user data):

• Google Search Console: Reports Core Web Vitals including INP from Chrome User Experience Report (CrUX) data — this is what Google uses for ranking.
• web-vitals JavaScript library: Add this to your Adobe Commerce frontend to collect INP data from real user sessions and send it to your analytics platform.

The most actionable approach: use Search Console to identify which page types have INP issues in the field, then use DevTools to diagnose and fix the specific interactions causing the problem.

The Conversion Case for INP Investment

Performance optimization is a business decision, not just a technical exercise. When interaction responsiveness improves:

• Cart completion rates increase because users trust that their clicks registered and their selections were saved.
• Checkout abandonment decreases because form interactions feel instant rather than laggy.
• Mobile conversion gaps narrow because mobile devices — where most ecommerce traffic originates — are more sensitive to main-thread blocking than desktop machines.
• Search visibility improves because Google uses field INP data as a ranking signal, and better rankings compound traffic over time.

The merchants who treat INP as a conversion rate lever — not just an SEO checkbox — are the ones who see measurable revenue impact from their performance work.

Where to Start

If your Adobe Commerce store has INP issues, the highest-leverage starting point depends on your frontend:

• Running Luma: Audit third-party scripts first (quick wins), then evaluate Hyvä migration for architectural INP improvement.
• Running Hyvä: Focus on custom module optimization and third-party script management — Hyvä’s architecture handles the rest.
• Planning a new build: Start with Hyvä. The INP advantage is built into the architecture from day one.

Creatuity’s Adobe Commerce team has delivered performance-focused implementations that address INP alongside LCP and CLS — because real performance means every metric, not just the ones that are easiest to fix. If your store’s interaction responsiveness is costing you conversions, reach out for a performance assessment.

Frequently Asked Questions

What is INP and why did it replace FID?

Interaction to Next Paint (INP) measures the responsiveness of all user interactions on a page, reporting the worst-case latency. It replaced First Input Delay (FID) because FID only captured the delay before the browser started processing the very first interaction, missing responsiveness problems that appeared later in the session. INP gives a more complete picture of how responsive a page actually feels.

What causes poor INP scores on Adobe Commerce stores?

The most common causes are RequireJS module loading delays, KnockoutJS data binding overhead on complex pages, third-party scripts blocking the main thread during interactions, and custom module JavaScript that performs synchronous operations. These issues are most pronounced on the default Luma frontend.

How does Hyvä improve INP compared to Luma?

Hyvä replaces KnockoutJS with Alpine.js (lighter reactive updates), removes RequireJS entirely (no deferred module loading on interaction), and reduces total JavaScript payload from 300-500KB to 50-100KB. These architectural changes eliminate the most common sources of interaction delay on Adobe Commerce storefronts.

How does INP affect ecommerce conversion rates?

Poor INP scores mean users experience visible delays when clicking buttons, selecting options, or submitting forms. This creates distrust — users are unsure whether their input was registered — leading to higher abandonment rates on product pages, cart pages, and checkout. Improving INP to under 200ms reduces this friction and supports higher completion rates across the purchase funnel.

What tools can measure INP on Adobe Commerce?

For real-user field data, use Google Search Console (CrUX data) and the web-vitals JavaScript library. For lab diagnosis, use Chrome DevTools Performance panel with the Interactions track, Lighthouse, and WebPageTest with scripted interactions. Field data determines your Google ranking impact; lab tools help you find and fix the specific problems.