WooCommerce CRO Technique

Improve Core Web Vitals on the WooCommerce templates that make you money

This technique uses PageSpeed Insights and CrUX field data to find the worst high-value WooCommerce template, then fixes LCP, INP and CLS where customers actually feel them: product, category, cart and checkout. A page only passes when real-user data at the 75th percentile hits LCP at 2.5s or less, INP at 200ms or less, and CLS at 0.1 or less, measured separately for mobile and desktop.

Summary

Bottom Line: Start with the slowest revenue template, not your sitewide score: use PageSpeed Insights and CrUX to identify the product, category, cart or checkout URL with poor field Core Web Vitals, then improve LCP by fixing the main image and TTFB

  • INP replaced FID as the Core Web Vital for responsiveness on 12 March 2024, and it is often the missed metric on WooCommerce stores carrying heavy tag, widget and checkout-script load.
  • LCP usually improves fastest when the main image is discoverable in the initial HTML, not lazy-loaded, and explicitly prioritised; CSS-background heroes are harder because the browser discovers them later unless you preload them.
  • CLS is usually caused by unsized images, badges, embeds, iframes or late-injected content, so reserving space up front is the core fix.
  • Cart, Checkout and My Account are dynamic pages and major Woo-compatible cache plugins exclude them from full-page cache by default; on those templates, you usually win by slimming assets and stabilising layout rather than forcing cache.

How To Implement

  • Pick the worst revenue template, not the prettiest score

    In GA4, start with Reports → Engagement → Landing page to see which URLs users hit first, then shortlist one representative URL for each WooCommerce revenue template: a top category, a top product, cart and checkout. Run each URL through PageSpeed Insights on mobile and desktop. PSI shows CrUX field data plus Lighthouse lab diagnostics; if the URL lacks enough field samples, it can fall back to origin data, which is useful as a sitewide clue but not proof for that specific page. For trend lines, use CrUX Vis or the CrUX History API, because PSI mainly shows the latest daily aggregation. Measurement note: save the current p75 LCP, INP and CLS for each chosen URL and device before changing anything.

  • Fix LCP on the template that carries revenue

    On product and category templates, the likely LCP element is usually the main image or large hero content. In WooCommerce, standard product image sizing lives at Appearance → Customize → WooCommerce → Product Images, and WooCommerce’s tools can regenerate shop images after size changes via WooCommerce → Status → Tools. Keep the above-the-fold LCP image out of lazy loading, and prioritise it instead: web.dev explicitly warns never to lazy-load the LCP image, and WordPress’s loading optimisation APIs support fetchpriority="high" while warning that no image should combine loading="lazy" with fetchpriority="high". If your theme or page builder puts the hero image in CSS, either move it into real HTML markup or preload it, because CSS-referenced LCP images get discovered later.

  • Improve LCP further by reducing TTFB on cacheable templates

    A fast product or category page still loses if the first byte arrives late, because TTFB sits ahead of every meaningful loading metric. web.dev recommends using a CDN to reduce document and asset TTFB where cacheable content is involved. In practice, that means getting product and category templates behind a sensible page cache and CDN, while keeping checkout state dynamic. If you are using WP Rocket, the main controls are in File Optimization, Media, Preload and Content Delivery; Remove Unused CSS is in File Optimization, and the plugin also exposes image, font and preload controls. If you are on LiteSpeed Cache, LiteSpeed Cache → Page Optimization → CSS Settings includes Generate UCSS, but LiteSpeed warns that UCSS and Guest Optimisation can create heavy disk and crawler usage on larger sites. If you are using Jetpack Boost, its dashboard exposes Cache Site Pages, CSS loading controls, Defer Non-Essential JavaScript, Image CDN and LCP image optimisation for Cornerstone Pages, including the WooCommerce shop page when active.

  • Do not “fix” cart and checkout by forcing full-page cache

    Full-page cache is the wrong lever for pages that carry user-specific state. WP Rocket says WooCommerce Cart, Checkout and My Account are automatically excluded from cache, and LiteSpeed Cache says the same. On these templates, focus instead on front-end payload: fewer scripts, fewer layout shifts, fewer expensive widgets, and less work on the main thread during interaction. That is where checkout CWV work normally pays off safely.

  • Cut INP by removing or delaying JavaScript that does not belong on that template

    INP became the live responsiveness metric in March 2024 and is judged in the field at the 75th percentile. web.dev’s guidance is consistent: slow interactions usually come from long tasks, heavy script evaluation and blocked main-thread work, and third-party JavaScript can hurt the critical rendering path and interaction responsiveness. On WooCommerce stores, common offenders are marketing tags, chat, review widgets, personalisation tools, page-builder assets and plugin scripts that load sitewide. If you use Perfmatters, enable Script Manager at Perfmatters → Tools, then open the target page on the front end and launch Script Manager from the admin bar; use Testing Mode before public rollout. If you prefer broad deferral, Perfmatters → JavaScript → Delay JavaScript, WP Rocket → File Optimization → Delay JavaScript execution, or Jetpack Boost’s Defer Non-Essential JavaScript can all help, but vendor docs are clear that exclusions should be minimal and breakages should be handled script by script. Measurement note: after each batch, test product variations, mini-cart, coupon, shipping and payment interactions on real mobile devices, because improving lab responsiveness is not worth a broken checkout.

  • Fix CLS by reserving space before anything async arrives

    web.dev lists unsized images, ads, embeds, iframes and dynamically injected content as common CLS causes. On WooCommerce, that often means product gallery images, payment badges, finance widgets, review summaries, recommendation slots and embedded video. The core fix is boring but effective: set image width and height, or reserve the slot with a stable CSS aspect-ratio wrapper before the content loads. On classic templates, that may mean adding a fixed-height wrapper in the template for trust badges or review widgets above the add-to-basket section. On block-based pages, use blocks that output known dimensions and avoid dropping late-loading promo bars or badges above existing content without a reserved container. WP Rocket also exposes Add missing image dimensions in its Media tab, which can help on stores with inconsistent markup.

  • Handle Blocks, classic shortcodes and HPOS as compatibility checks, not ideology

    For block-based cart and checkout, WooCommerce documents editing paths for both block themes and non-block themes: use Appearance → Editor → Template → WooCommerce on block themes, or Pages → All Pages on non-block themes. Woo also documents how to transform the Cart or Checkout block back to Classic Shortcode if an extension still works better there. For checkout architecture, compatibility matters more than fashion. On the storage side, HPOS is enabled by default for new installs from WooCommerce 8.2 onward. HPOS is mainly an order-storage change, not a direct front-end CWV fix, but incompatible extensions can block or complicate checkout changes, so confirm extension compatibility before changing the checkout implementation during a speed project.

How To Measure

The primary technical KPI is field Core Web Vitals pass rate on the target URL or representative template URL at the p75, split by mobile and desktop. The business KPI is RPV, with conversion rate and, where relevant, checkout completion as secondaries. Google’s thresholds are LCP at 2.5s or less, INP at 200ms or less, and CLS at 0.1 or less, assessed at the 75th percentile.

In GA4, use the ecommerce events and reports that match the template you changed. For product and category work, watch view_item, add_to_cart and purchase, along with the Ecommerce purchases report. For cart and checkout work, watch begin_checkout and purchase, plus the Checkout journey and Purchase journey reports. Use the Landing page report to isolate URLs that start sessions, and apply a device category comparison so mobile and desktop are not blended together.

Read the data in three slices: by device, by target page or template representative URL, and by comparable traffic mix if acquisition changed during the test period. Success looks like the target URL moving materially closer to, or into, passing field thresholds in CrUX while RPV and conversion rate on the affected segment stay flat or improve. Good lab scores alone do not count as success, because PSI’s own documentation distinguishes lab data used for debugging from field data that reflects real-world experience. Guardrail metrics that must not worsen are AOV, add_to_cart rate, begin_checkout rate, checkout completion, and total purchase revenue on the same device split.

Pitfalls

  • Myth: “Better Core Web Vitals guarantee rankings.” They do not. Google says Core Web Vitals are used by ranking systems, but good scores in reports do not guarantee top rankings, and relevance still matters more.
  • Mistake: Optimising the homepage while the real leak is product, category or checkout. Page experience is largely page-specific, and GA4’s Landing page report exists precisely because users do not all enter through the homepage. Prioritise the worst high-traffic revenue template first.
  • Mistake: Turning on overlapping optimisation features across multiple plugins at once. Running several lazy-load, CSS-removal or JS-deferral systems together can create duplicated behaviour, broken layouts or hard-to-debug exclusions. WP Rocket explicitly notes feature overlap with Perfmatters’ Remove Unused CSS, and Jetpack Boost, WP Rocket and Perfmatters all document exclusions for scripts or styles that break when optimised too aggressively.
  • Mistake: Treating origin-level CrUX as template truth. CrUX reports at page and origin granularity, not by WooCommerce template. If PSI shows origin data because the URL lacks enough samples, use it as a signal, but prioritise fixes with representative URLs plus your own analytics.
  • Myth: “INP is a developer-only concern.” It is a buyer concern the moment taps, quantity changes, accordions, coupon fields or payment method interactions feel delayed. INP exists to measure end-to-end responsiveness as users experience it, and long tasks on the main thread can make interfaces feel broken.

Examples

FAQs

Sources & Further Reading

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 18 Jun 2026
  • Last Updated: