Reduce WoodMart JavaScript bloat on WooCommerce storefronts

On a typical WoodMart store the main-thread cost is a stack: the theme's own modules, WooCommerce cart/fragment scripts, plugin JS (filters, reviews, wishlist), and marketing tags loaded through a tag manager. Much of it loads on every page — including product pages — before the shopper can interact.

INP measures how quickly the page responds to taps and clicks. When too much JavaScript executes or waits in the queue, that response is delayed:

• Long tasks block the main thread during and after load
• Scripts run on pages that don't use their feature
• Tag managers add third-party JS you don't fully control
• Hydration of heavy theme widgets delays interactivity

Sometimes the win is just disabling unused modules, deferring non-critical scripts and cleaning up the tag manager. If a handful of scripts cause most of the cost, that's an in-place fix — the audit shows the JavaScript breakdown by source before you decide.

A Next.js storefront only ships the JavaScript a given page actually needs, and renders the HTML up front so content is usable before scripts run. Interactive pieces load on demand instead of a single site-wide bundle — which is what moves INP the most.

WoodMart bundles a long list of interactive features, and each one ships script whether the store uses it or not: the mega menu, product-image hover swaps, quick shop and quick view, 360-degree and video galleries, countdown timers, a sticky add-to-cart bar, back-to-top, a cookie bar, a currency switcher and animation on scroll. Most stores actively use a handful of these and inherit the runtime cost of all of them. The first, cheapest win is simply auditing which are enabled and turning off the ones the store does not use — before touching architecture.

• List which WoodMart interactive modules are actually enabled
• Disable hover swaps, 360 view, timers and animations you do not use
• Keep only the features that support browsing and buying
• Measure the JavaScript saved per template after each toggle

Even a trimmed theme can feel sluggish because the tag stack is the other half of the main-thread cost. A tag manager often loads analytics, ad pixels, a chat widget, a reviews script and remarketing tags — much of it early and some of it synchronously — and this JavaScript competes with the shopper's first interaction. The fix is to load these deliberately: defer what is not needed immediately, gate marketing tags behind consent, and load campaign-specific scripts only where campaigns run. It keeps the data you rely on while taking its cost off the critical path.

Cutting scripts works best against a target rather than a feeling. Set a per-template JavaScript budget — a ceiling on the kilobytes shipped and the main-thread time spent before a page is interactive — and measure against it. The DevTools Coverage tab shows how much of the loaded JavaScript a template actually uses, which exposes scripts loaded but never executed. The Performance panel shows total blocking time and the long tasks behind poor INP. With a budget written down, every new tag or widget has to earn its place against a number, instead of being added because it was easy.

• Set a per-template JS size and main-thread budget
• Use the Coverage tab to find loaded-but-unused JavaScript
• Watch total blocking time and long tasks for INP
• Make each new tag justify itself against the budget

We identify the interactions that matter — add-to-cart, gallery, filters — and rebuild them as lean components, dropping the rest of the theme runtime. WooCommerce still serves the data; the storefront just stops shipping JavaScript shoppers never use.