WooCommerce INP Problems: Why Checkout Can Feel Slow

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 200) {
      console.table({
        name: entry.name,
        duration: Math.round(entry.duration),
        target: entry.target?.id || entry.target?.className || 'unknown',
        startTime: Math.round(entry.startTime)
      });
    }
  }
});

observer.observe({ type: 'event', buffered: true, durationThreshold: 40 });

<?php
add_action(
    'wp_enqueue_scripts',
    static function (): void {
        if ( ! is_checkout() ) {
            return;
        }

        wp_dequeue_script( 'nonessential-chat-widget' );
        wp_dequeue_script( 'homepage-animation-bundle' );
    },
    100
);

End-to-end INP investigation for WooCommerce checkout

Full implementation: Interaction to Next Paint is not a generic speed score. It measures how long the page takes to provide visual feedback after a real interaction. On checkout, the slow interaction might be changing a country, choosing shipping, applying a coupon, opening a wallet or submitting payment. I diagnose the exact interaction before changing assets.

Start with field data and a reproducible journey

Use real-user monitoring or Search Console to identify affected templates and device classes. Lab tools are useful, but they cannot tell you which interaction your customers struggle with. Write a short journey that reproduces the issue with the same cart type, consent state, gateway and network conditions. Save the URL, device profile and result so the next trace is comparable.

Do not test only while logged in as an administrator. Admin toolbars, uncached responses and disabled optimisation can change the page. Use a fresh customer session and test both first visit and returning visit. Checkout behaviour often changes after address data, wallet scripts or cached consent choices are present.

Break the interaction into three parts

An interaction has input delay, processing time and presentation delay. Input delay means earlier main-thread work prevented the handler from starting. Processing time means the handler itself or related JavaScript performed too much work. Presentation delay means rendering, layout or paint was expensive after the handler completed. Each component suggests a different fix.

• High input delay: find unrelated long tasks already occupying the main thread.
• High processing time: inspect handlers, synchronous loops and chained state updates.
• High presentation delay: inspect layout shifts, large DOM changes and expensive styles.

Record a focused performance trace

Open the browser performance panel, enable screenshots and record only the interaction plus a few seconds around it. Mark the exact click or keypress. Expand the related event, then inspect long tasks, script URLs, function names, style recalculation and layout. One focused trace is more useful than a minute of unrelated page activity.

The Event Timing observer in the earlier example helps identify a slow target, but it does not replace the trace. Observer output tells you what was slow. The performance recording helps explain why. Keep both beside the test case and rerun them after each material change.

Audit WordPress script ownership

Map every loaded script to the plugin, theme or tag that owns it. WordPress handles make this easier when code is enqueued correctly. Separate critical checkout dependencies from optional marketing, chat, animation and recommendation features. Then test removal in staging one handle at a time.

<?php
add_action( 'wp_enqueue_scripts', static function (): void {
    if ( ! is_checkout() || is_order_received_page() ) {
        return;
    }

    wp_dequeue_script( 'homepage-slider' );
    wp_dequeue_script( 'nonessential-recommendations' );
}, 100 );

Do not copy handles blindly from an example. Confirm the registered handle and dependency graph on the site. Dequeuing a parent while a child expects it can create a quieter but more serious checkout defect. I test payment, shipping, validation and tracking after every script policy change.

Reduce work inside the interaction

If your own handler performs several jobs, separate the immediate response from work that can wait. Update the visible control first. Move analytics enrichment, recommendations or nonessential storage to a later task. Break large loops into smaller work so the browser can render between them. Avoid repeatedly reading layout values after writing styles because this forces synchronous layout.

React code can also cause broad rerenders when state is stored too high in the tree or selectors return new objects on every change. Profile the component update, memoise only where evidence supports it and keep derived state close to the component that uses it. Optimisation without a trace often adds complexity without improving the measured interaction.

Treat third-party scripts as production dependencies

Tag managers can make ownership unclear because a WordPress page loads one container that later injects several libraries. Export or document the container, list every checkout tag and record its trigger. Consent platforms, chat widgets, fraud tools, heatmaps and advertising pixels all compete for the same main thread.

Delay is not always safe. A fraud or payment script may be required before submission. Classify each script by customer or compliance purpose, then choose load timing accordingly. Remove duplicate libraries, prevent tags from firing on every state change and use server-side events where that reduces browser work without damaging consent or attribution.

Check the server side too

INP is a browser metric, but WooCommerce interactions often wait on Store API or Ajax responses. Slow PHP and database queries can extend the period before the interface updates. Inspect the network request, server timing and WooCommerce logs alongside the browser trace. Optimising JavaScript will not fix a shipping request that spends two seconds in the database.

• Profile custom fee and shipping calculations.
• Cache safe reference data, not customer-specific totals.
• Remove remote API calls from synchronous calculation paths where possible.
• Check repeated fragments or Store API requests after one interaction.
• Review database queries added by custom checkout extensions.

Create a checkout-specific regression suite

1. Change country, postcode and address fields.
2. Switch between all shipping methods.
3. Apply and remove valid and invalid coupons.
4. Select each gateway and express wallet.
5. Trigger validation, a declined payment and a successful payment.
6. Repeat on a mid-range mobile profile with consent enabled.

Record responsiveness and functional outcome. A lower interaction duration is not a win if taxes, analytics or payment confirmation stop working. I keep the before and after traces with the release notes so future plugin updates can be compared against a known baseline.

Monitor after deployment

Field data takes time to change, so add immediate operational signals: JavaScript errors, Store API failures, payment errors and checkout completion rate by device. Then compare real-user INP distributions when enough traffic is available. Look at the slow end of the distribution, not only an average that hides affected customers.

The practical order is simple: identify the real interaction, explain the delay with a trace, remove unrelated work, shorten required work and verify the commercial flow. That produces a defensible performance improvement instead of a collection of optimisation settings.

Need a production review?

If this system carries revenue or customer data, I can review the current architecture, reproduce the risky paths and turn the findings into a prioritised implementation plan. Request a technical review.

How I prioritise fixes when several scripts are slow

I rank candidates by interaction impact, business necessity and removal risk. A large homepage library loaded on checkout is a high-priority removal. A payment SDK inside the confirmed slow interaction is necessary, so I look for duplicate initialisation, earlier loading or work that can move after visual feedback. A small script outside the trace is not prioritised simply because an audit labels it unused.

This prevents performance work from becoming random deletion. Every change has a hypothesis, a trace, a functional test and a rollback. The team can then explain why responsiveness improved and repeat the method when a plugin update changes the result.