Fix WoodMart Core Web Vitals without leaving WooCommerce

LCP is usually a heavy hero image, slider or render-blocking CSS. INP is JavaScript — theme modules, swatches, quick view and tag managers competing for the main thread when a shopper taps. CLS is layout: unsized images, late banners, font swaps. Treating them as one "speed" problem is why generic optimization often stalls.

We start from field data (CrUX / real users), not a single lab run, and separate metric by page type:

• LCP element and its load timeline per template
• INP: which scripts block interaction on product and category pages
• CLS sources on mobile above the fold
• Whether home, PLP, PDP, cart each fail differently

If you're close — one heavy metric driven by images, an uncached query or a couple of third-party tags — the honest recommendation is to fix those in place. Many stores pass without a rebuild, and the audit will say so.

When the shared theme CSS/JS bundle, builder markup and plugin scripts keep INP high no matter what you defer, you've hit the structural limit. A Next.js storefront ships per-page JavaScript and pre-rendered HTML, which targets exactly the LCP and INP costs a theme can't shed.

Because the three metrics have different causes, the cheapest route is to fix them in the right sequence rather than all at once. CLS usually comes first: reserving space for images, banners and swatches is low-effort and also stops the mis-taps that quietly cost sales. LCP is next: correct image format, size and priority for the one element that defines the score. INP is last and hardest, because it means reducing and deferring JavaScript, which is exactly where a theme's shared bundle resists tuning. Working in that order means each step banks a visible win before you reach the expensive one.

A frequent surprise is a WoodMart store that looks fine in a desktop test and fails Core Web Vitals in the report, because Google grades the mobile field data. Phones have slower CPUs and networks, so the theme's global CSS and JavaScript bundle that a laptop shrugs off overwhelms a mid-range device — inflating INP and LCP where it actually counts. The practical consequence is simple: judge the store on a throttled mobile profile and on field data, because that is the version of the page Google is measuring.

It helps to work toward concrete pass marks rather than a vague 'faster'. Google's thresholds, measured at the 75th percentile of real mobile visits, are an LCP under 2.5 seconds, an INP under 200 milliseconds and a CLS under 0.1. 'Passing' means the field data — not a single lab score — sits under those marks for most of your users. Knowing the numbers reframes the work: you are not chasing a perfect Lighthouse result, you are getting the p75 of real WoodMart shoppers under three specific limits, on the templates that earn money.

• LCP under 2.5s at the 75th percentile of mobile visits
• INP under 200ms
• CLS under 0.1
• Judge on field p75, not a single lab run

We rebuild the storefront with a strict per-template budget, verify LCP/INP/CLS in the field on staging across each page type, and only switch the domain once the numbers hold. WooCommerce remains the backend, admin and source of catalog data throughout.