# WooCommerce checkout INP: fix slow interactions INP on WooCommerce checkout. Cart fragments, jQuery, wallets and field count. How to measure field data. - Date: 2026-08-20 - Category: WooCommerce # WooCommerce checkout INP: fix slow interactions WooCommerce checkout INP is the Interaction to Next Paint you record on cart and checkout, and it is usually worse than the homepage Lighthouse screenshot. Typing a postcode, opening a wallet, or toggling shipping should paint the next frame quickly. On many WordPress shops those clicks wait on cart fragments, jQuery, three field plugins and a chat widget. I am Alan Vo. I work from the Gold Coast on WooCommerce catalogues. I treat checkout INP as a conversion bug, not a vanity Core Web Vitals badge. Google explains the metric in [INP on web.dev](https://web.dev/articles/inp). The good threshold is 200ms or less at the 75th percentile of field data. This note is what actually burns that budget on WooCommerce, and how I measure it on real checkouts rather than a cached blog post. ## Why WooCommerce checkout INP is a different problem to homepage speed WooCommerce checkout INP is a different problem because checkout is an interaction machine. Homepage LCP is often a hero image. Checkout INP is keypresses, radio clicks and payment iframes. A store can pass LCP on the PDP and fail INP on checkout while revenue quietly leaks. Classic checkout re-renders large HTML fragments when the address changes. Cart fragments poll `wc-ajax=get_refreshed_fragments` on every page, including checkout, unless you stop them. Each response runs jQuery to replace mini-cart HTML. That work sits on the main thread next to your field-validation plugin. Block checkout moves some of that to the Store API and React. It is better when the plugin pack is thin. It is not magic. A blocks checkout with two wallet SDKs, a live-chat embed, and a pixel manager still fails INP. I still migrate when I can, because new work lands there: [how to migrate to WooCommerce block checkout](https://alanvo.com/blog/woocommerce-block-checkout/). The store-wide vitals context is [Core Web Vitals for online stores](https://alanvo.com/blog/core-web-vitals-online-stores/). Field count is product, not only engineering. Every extra required input is an interaction. Every "helpful" inline validator that hits the server on blur is an INP sample. I argue for fewer fields before I argue for a new theme. ## What actually makes WooCommerce checkout INP fail Cart fragments are the first suspect on classic themes. `wc-cart-fragments.js` runs site-wide. On checkout it competes with `checkout.js`. I dequeue fragments on cart and checkout when the mini-cart is not needed there, or I delay fragments until interaction on other templates. ![WooCommerce checkout INP checkout fields on a laptop in a studio](../../images/blog/woocommerce-checkout-inp-1.jpg) jQuery is the second. WooCommerce still uses it on classic checkout. Themes add more. Field plugins add more. Everything binds `keyup` on every input. I count `keyup` and `input` listeners in the performance panel. If a plugin validates VAT against an API on every keystroke, that is your INP. Wallets are the third. Apple Pay and Google Pay scripts are heavy. They should load on checkout, not on the blog. They should not load three times because Elementor, the gateway, and GTM all inject them. One wallet SDK. Test that the button still appears. Payment iframes are the fourth. Stripe and similar gateways paint slowly if the main thread is busy. INP attributes the click to your page even when the iframe is the slow part. Reducing your own JS still helps the click start the iframe work sooner. Chat, reviews, heatmaps and loyalty popups are the fifth. None of them belong on checkout. I strip them by URL. This is the highest-ROI cut I make. Autocomplete and address lookup APIs are the sixth. They are worth it when they reduce typing. They are INP poison when they query on every character with no debounce and then rewrite the DOM. Themes that animate the order review table on every update force layout. CSS transitions on large tables are a classic "it feels broken" interaction. PHP is rarely the INP story. TTFB can be bad on cart (uncached), which makes the page late. INP is after load. Do not "fix INP" by buying a larger server if the trace is 400ms of JavaScript. ## How I profile WooCommerce checkout INP in the field and in the lab I start with field data. Search Console Core Web Vitals, CrUX, or RUM if the client has it. I need the checkout URL group, not origin-wide. Origin-wide INP can look fine because blog posts are cheap. Checkout can still be failing. Lab: Chrome performance panel on a throttled CPU, mobile viewport, with cache disabled, on a staging site that still has the same plugins. I record: focus postcode, type four digits, tab to city, select shipping, click a payment method, click place order (test mode). I look at long tasks over 50ms during those interactions. I name the file: `cart-fragments`, a plugin slug, `gtm.js`, a chat vendor. Then I remove or defer that file on checkout and record again. Web Vitals extension and `web-vitals` JS can log INP attribution (the element and the next paint delay). Attribution that says `input#billing_postcode` plus a 300ms processing delay is a smoking gun. ![Shopping bags on a counter used while testing WooCommerce checkout INP](../../images/blog/woocommerce-checkout-inp-2.jpg) I test guest and logged-in. Logged-in checkout loads account data and saved cards. It is often slower. I test wallets separately. A trace without the wallet SDK is not the customer path. I do not use a Lighthouse "mobile" run on the homepage as a proxy. Lighthouse on checkout is useful for unused JS, not as the INP number you report to a merchandiser. Field 75th percentile is the number. Australian mobile networks and mid-range Androids are the devices I care about from the Gold Coast. A checkout that feels fine on a desktop with cache disabled in a warm office still fails WooCommerce checkout INP in the field when a wallet SDK compiles on a throttled CPU. If the client only ever QA's on a company MacBook, I record a trace on a cheap phone before I call the job done. The CrUX 75th percentile is mostly those phones, not the office hardware. ## Production checklist to improve WooCommerce checkout INP 1. Split field INP for cart and checkout URL patterns in Search Console. 2. Disable chat, reviews, heatmap, popups and non-payment pixels on cart and checkout. 3. Confirm GTM on checkout only fires payment and conversion tags, not the full marketing stack. 4. Dequeue cart fragments on checkout if the mini-cart is unused there. 5. Audit `keyup`/`input` handlers. Debounce address and VAT lookups to blur or 300ms+. 6. Load one wallet SDK, only on checkout, after first idle or on payment-step visibility. 7. Remove duplicate jQuery and migrate off classic field plugins that wrap every input. 8. Prefer block checkout when plugins allow. Re-measure. Do not assume a win. 9. Cut checkout fields. Phone, company, and two note boxes are frequent extras. 10. Avoid Elementor on the checkout template. Builder runtime on checkout is INP debt. 11. Ensure payment buttons have immediate disabled/loading state so the click feels acknowledged even if the network is slow. 12. Cache is off for cart and checkout. Do not "fix INP" by full-page caching checkout. You will cache another customer's cart. 13. Re-test after each plugin removal. Bundled changes hide the winner. 14. Watch field INP for 28 days. Lab wins that never show in CrUX did not ship to real phones. ## What breaks when you "optimise" checkout blindly Dequeuing `checkout.min.js` or block checkout scripts to save KB. Place order stops working. Do not asset-strip by filename without a test order. ![WordPress admin on a screen during WooCommerce checkout INP work](../../images/blog/woocommerce-checkout-inp-3.jpg) Caching checkout HTML. Customers see someone else's cart or an empty cart. INP looks great. Trust dies. Deferring the payment SDK so far that Place order runs before Stripe is ready. Failures look like INP wins in Lighthouse. Removing cart fragments site-wide without a replacement mini-cart. Header cart count stays at 0. People add to cart twice. Block checkout plus a classic fragment mini-cart. Two sources of truth. Counts flicker. INP includes the flicker work. Aggressive `content-visibility` on the order summary so screen readers and focus order break. Consent banners that block the main thread on checkout. Put the CMP on a lighter path, but do not hide payment until seven clicks of legal copy if you already collected consent on the PDP. ## How I measure whether checkout INP work paid off I measure field INP on checkout URLs and the `begin_checkout` to `purchase` completion rate in GA4. If INP improves and completion does not, you may have cut a field people needed, or ads traffic quality changed. If completion improves and INP does not yet (CrUX lags), keep the JS cuts and wait a month. I also watch payment error rates and customer-service tickets about "button did nothing." That phrase is often INP: the click happened, the paint did not. Gateway time-to-charge is not INP. Do not confuse a slow acquirer with a slow theme. ## Related work on this site Fashion and print shops on WooCommerce feel INP on phones in a shop window and at home. The [Stitching Stories storefront](https://alanvo.com/work/stitching-stories/) has to hold photography and still sell a t-shirt. [Throttle Haus](https://alanvo.com/work/throttle-haus/) is automotive prints with filters and PDPs that cannot fight checkout. Those builds are where I strip third-party JS from the order path first, then argue about theme chrome. ## FAQ ### What is a good WooCommerce checkout INP score? A good WooCommerce checkout INP score is 200ms or under at the 75th percentile in field data for checkout URLs. 200-500ms needs work. Over 500ms is failing. Lab Lighthouse is not that number. ### Does block checkout fix WooCommerce checkout INP automatically? No. Block checkout can reduce fragment churn and jQuery, which often helps WooCommerce checkout INP. Wallets, GTM and chat can still fail it. Measure after the migration. ### Should I remove jQuery to fix WooCommerce checkout INP? Remove extra jQuery plugins. Classic checkout still needs WooCommerce's own scripts. A slash-and-burn dequeue that kills checkout is not an INP strategy. Profile, then cut identified long tasks. ![Product photography on a table for a WooCommerce PDP](../../images/blog/woocommerce-checkout-inp-4.jpg) ### Why is homepage INP fine but WooCommerce checkout INP poor? Homepage interactions are usually a menu and a link. Checkout samples postcode typing, shipping radios and wallets. Different JS, uncached HTML, more fields. Always slice CrUX by checkout paths. HTML version: https://alanvo.com/blog/woocommerce-checkout-inp/