WooCommerce INP Optimization: Fix Your Interaction to Next Paint Score

INP – Interaction to Next Paint – replaced Google’s old FID metric in March 2024 and immediately exposed a problem WooCommerce stores had always had but never been measured on: slow interactions. Add to Cart, variation swatches, checkout fields – every one of those is now a data point in your Core Web Vitals score. This guide covers the seven causes of poor WooCommerce INP and exactly how to fix each one.

Last updated: March 2026

The Short Version

If your WooCommerce store has a poor INP score, the most likely culprits are:

Cart fragments firing an AJAX request on every page load – even blog posts
WooCommerce scripts loading on pages that don’t need them
Third-party scripts from payment gateways, analytics and chat widgets blocking the main thread
Variable product pages embedding large JSON blobs that take 100–300ms to parse
Legacy order storage making add-to-cart and checkout database writes slow

Fix those five things and most WooCommerce stores will move from Poor or Needs Improvement into the Good range.

The rest of this guide explains why each one happens, how to confirm it’s your problem, and exactly what to do about it.

What Is INP and Why Does WooCommerce Fail It?

INP (Interaction to Next Paint) measures how long your page takes to visually respond after a user interaction – clicking Add to Cart, tapping a product image, tabbing through a checkout field.

Google replaced the old FID metric with INP in March 2024. The difference matters for WooCommerce specifically: FID only measured the delay before the browser started responding to the very first interaction. INP measures the complete response time – input delay, all event handler code running, layout and painting – for every click and tap throughout the entire page visit.

WooCommerce failed FID on far fewer stores than it fails INP, because FID never measured what happens when someone actually clicks Add to Cart.

The scoring thresholds:

Score	What it means
≤ 200ms	Good – passes Core Web Vitals
201–500ms	Needs Improvement
> 500ms	Poor – actively hurts rankings

Google ranks you on the 75th percentile of real user sessions – meaning 75% of your visitors need to experience INP under 200ms for your store to pass.

The Three Parts of Every INP Interaction

Every click or tap has three phases:

User clicks → [INPUT DELAY] → [PROCESSING TIME] → [PRESENTATION DELAY] → Screen updates

Input Delay – The browser was busy doing something else when you clicked. JavaScript was running, an AJAX response was being processed, a timer fired. Your click sat in a queue.

Processing Time – Your click handler actually ran. WooCommerce ran its add-to-cart logic, sent an AJAX request, waited for a response, updated the cart.

Presentation Delay – After the JavaScript finished, the browser recalculated styles, ran layout, and painted the result to screen. Large DOM trees make this expensive.

Knowing which phase is large tells you exactly where to look. A large input delay means something was blocking the main thread before you clicked. A large processing time means your click handler is slow. A large presentation delay means your DOM is too complex.

How to Check Your WooCommerce INP Score

Step 1: PageSpeed Insights (What Google Actually Sees)

Go to pagespeed.web.dev and test these specific pages:

Your homepage
A product page (especially one with variable products)
Your cart page
Your checkout page

The Field Data section at the top shows your real INP from actual Chrome users over the past 28 days – this is the number Google uses for rankings. The Lab section lower down shows TBT (Total Blocking Time), which is an approximation for INP in synthetic tests.

If your product page shows INP: 450ms, your checkout shows 680ms, and your homepage shows 160ms – you immediately know the commerce-specific pages are the problem, which narrows the fix list considerably.

Step 2: Google Search Console

Search Console > Experience > Core Web Vitals shows your pages grouped as Good, Needs Improvement, and Poor, based on real user data. If your checkout and product pages are in the Poor group, that confirms the INP problem is real and widespread, not just a one-off lab result.

Step 3: Chrome DevTools (Find the Specific Cause)

PageSpeed Insights tells you that you have a problem. Chrome DevTools tells you why.

Open Chrome DevTools (F12) on your product page or checkout
Go to the Performance tab
Click the gear icon and set CPU Throttling to 4x slowdown – this simulates a mid-range Android phone, where most INP failures happen
Click Record, perform the interaction (click Add to Cart, change a variation, fill a checkout field), click Record again to stop
Find the Interactions track and hover over the interaction block

The tooltip shows you the exact breakdown:

Type: click
Target: button.single_add_to_cart_button
Duration: 340ms
  Input Delay:        190ms  ← Main thread was busy
  Processing Time:     95ms  ← Your cart handler ran
  Presentation Delay:  55ms  ← DOM updated and painted

In this example, the 190ms input delay is the problem. Look left on the timeline to find what was running on the main thread at the moment you clicked.

The 7 WooCommerce INP Problems (And How to Fix Each One)

Problem 1: Cart Fragments Fires on Every Single Page

This is the most common cause of WooCommerce INP failures – and genuinely the most annoying, because it’s a WooCommerce default that makes no sense. WooCommerce cart fragments slowing down every page on your site is the first thing to check when you start seeing poor INP scores.

What’s happening: Every time any page on your site loads, WooCommerce fires a script called wc-cart-fragments. It sends an AJAX request to your server (/wp-admin/admin-ajax.php?wc-ajax=get_refreshed_fragments) to fetch the current cart state. This keeps the mini-cart count in your header up to date.

The problem: this request fires on your blog posts, your About page, your Contact page – everywhere. And while the AJAX response is being processed, it occupies the main thread. Any user who clicks something while that’s happening gets a delayed response. This is also why your WooCommerce AJAX add to cart feels slow – the cart fragments request may still be running when the customer clicks the button.

On a slow server or congested connection, this AJAX call can take 1–3 seconds. During that time, the main thread is partially blocked. Every interaction during that window will show elevated input delay.

How to confirm it’s your problem: In Chrome DevTools Network tab, filter by XHR and look for admin-ajax.php?wc-ajax=get_refreshed_fragments on non-shop pages. If it’s there and taking 200ms+, it’s contributing to your INP.

Fix option 1 – Disable on non-commerce pages (Recommended):

Add this to your theme’s functions.php or a site-specific plugin:

add_action('wp_enqueue_scripts', function() {
    if (!is_cart() && !is_checkout() && !is_woocommerce()) {
        wp_dequeue_script('wc-cart-fragments');
    }
}, 99);

This keeps cart fragments active on your shop, product, cart and checkout pages where it’s needed, but removes it everywhere else.

Fix option 2 – Use WP Rocket, FlyingPress or Perfmatters:

All three plugins have a one-click toggle to disable cart fragments. WP Rocket calls it “Remove WooCommerce Cart Fragments”. FlyingPress has “Cache Cart Fragments” which serves the AJAX response from cache instead of hitting the database every time (often the better option if you want the header cart to stay live).

What to watch out for: If your theme shows a live cart item count in the header, disabling fragments entirely will break that for visitors who have items in their cart. The code snippet above is safer because it only disables on pages where the cart widget doesn’t need updating. Test with items in cart after making changes.

Problem 2: WooCommerce Scripts Load on Every Page

WooCommerce loads its JavaScript on every page of your site by default – product pages, blog posts, the contact form, everything. Most of this JS is irrelevant on non-commerce pages, but it still executes and takes up main thread time.

What’s loading unnecessarily:

woocommerce.js – event handlers and utilities
wc-add-to-cart.js – add to cart logic (irrelevant on a blog post)
Payment gateway scripts – Stripe, PayPal loading their SDK on your homepage
WooCommerce CSS – extra stylesheets parsed on every page

Fix – Perfmatters Script Manager:

Perfmatters has the most surgical tool for this. Its Script Manager shows every script and stylesheet loading on any given URL, with toggles to disable them per page type. You can disable all WooCommerce scripts on posts, pages and archives in minutes.

In the Script Manager:

Disable woocommerce and woocommerce-general scripts on post type: post
Disable payment gateway scripts everywhere except /checkout/
Disable variation scripts everywhere except product pages

Fix – WP Rocket and FlyingPress:

Both plugins have “Remove Unused CSS” and “Delay JS” features that reduce what loads and when. FlyingPress is more precise – it analyses each URL individually rather than using global rules.

Problem 3: Variable Products Embed Too Much JSON

If your store sells products with multiple variants (size + colour, for example), WooCommerce embeds all variation data as a JSON blob directly into the page HTML. A product with 50 variations can embed 30–100KB of JSON.

When a customer clicks a variation swatch or changes a dropdown, WooCommerce’s JavaScript parses that entire JSON object to find the matching variation, look up its price, check stock status, swap the product image. Parsing 100KB of JSON on a mid-range Android phone takes 100–300ms – and that entire duration lands in the processing time phase of your INP score.

How to spot this: In Chrome DevTools, click a variation swatch and look at the Processing Time in the interaction tooltip. If it’s 150ms+, check the page source for JSON.parse calls or look for a wc_product_block_data or woocommerce_variation variable in the source containing a large object.

Fixes:

Enable WooCommerce Variation Lookup Tables – Go to WooCommerce > Status > Tools and run “Update variation lookup table”. This creates a proper indexed table for variation lookups, shifting the work to a more efficient database query instead of JSON parsing.
Limit variations per product – WooCommerce’s own documentation recommends keeping products under 50 variations. Above that, consider splitting into separate products.
Lazy-load variation data – Some variation/swatches plugins can be configured to load variation data via AJAX when a swatch is first clicked rather than pre-loading everything. This means the initial page is lighter, and the first swatch click triggers a fast targeted request instead of parsing a large pre-loaded blob.

Problem 4: Third-Party Scripts Block Interactions

Analytics tools, live chat widgets, heatmap recorders and ad scripts all run in the same main thread as your WooCommerce code. When they run long tasks, your customers’ clicks get delayed.

The worst offenders for INP:

Google Tag Manager with many tags – GTM itself is lightweight but it loads and executes every subordinate tag, each of which can register global event listeners
Hotjar, FullStory, Microsoft Clarity – these tools attach listeners to every mouse movement and click across your entire site, adding overhead to every interaction
Live chat widgets (Intercom, Crisp, Zendesk) – heavyweight scripts plus global listeners
Facebook/Meta Pixel – fires callbacks on page events
Google AdSense auto-ads – continuously scans the DOM

Fix – Delay scripts until after first user interaction:

WP Rocket, FlyingPress and Perfmatters can all delay third-party scripts from loading until the user first moves their mouse, scrolls or touches the screen. This means those scripts simply do not exist on the main thread during the initial page load window – dramatically reducing input delay for early interactions.

WP Rocket calls this “Delay JavaScript Execution”. FlyingPress calls it “Delay JS”. Both maintain a safelist of WooCommerce-critical scripts that should never be delayed.

What to test after enabling delay: Add items to cart, complete a test checkout, verify all payment gateways work. Delayed scripts still work – they just load a fraction of a second later. But some payment gateways (older PayPal SDK versions) break if delayed. Always test thoroughly and add payment scripts to your exclusion list.

Problem 5: Slow Checkout Due to Payment Gateway Scripts and Form Interactions

A WooCommerce slow checkout page is one of the most damaging INP failures – it occurs at exactly the point where a customer is ready to buy. The checkout page is typically the hardest page to get into the Good INP range. It has:

Payment gateway scripts loading iframes and attaching listeners (Stripe Elements, PayPal SDK)
JavaScript validation firing on every field blur event
AJAX calls for shipping recalculation, coupon validation, address lookup
The page is not cacheable, so PHP runs on every visit

Every field interaction – typing your email, tabbing to the next field, clicking Place Order – is an INP event. If a payment gateway script is doing something on the main thread when you tab between fields, you get input delay.

1. Load payment gateway scripts conditionally

Most payment gateways load their SDK on every page by default. Stripe.js, for example, loads on your homepage when it only needs to be on the checkout page. Perfmatters Script Manager can restrict payment scripts to /checkout/ only.

2. Migrate to WooCommerce Checkout Block

The classic WooCommerce checkout uses a jQuery-driven approach that replaces large chunks of the DOM on every update. The WooCommerce Checkout Block (built with React) uses incremental DOM updates – it only changes what changed. This reduces the presentation delay phase of checkout interactions significantly.

Note: Verify all your payment gateways and shipping plugins support the Checkout Block before migrating. Most major gateways now do, but older or less-maintained extensions may not.

3. Reduce the number of scripts loading on checkout

Use Perfmatters or FlyingPress Script Manager to disable all non-essential scripts on the checkout page. Blog post scripts, slider scripts, portfolio plugins – none of them should be loading on /checkout/.

What’s a realistic checkout INP?

With Stripe or PayPal active, 200–250ms is a realistic floor for most stores – payment gateway SDKs require some main thread time. Below 200ms on checkout is achievable without third-party payment iframes, but unusual with them.

Problem 6: Legacy Order Storage Slowing Down Cart and Checkout

When a customer clicks Add to Cart, WooCommerce writes to your database to create or update the cart session. With legacy order storage, this write goes into the wp_posts and wp_postmeta tables – the same generic tables used for blog posts, pages and every other WordPress content type.

At scale (stores with thousands of orders), wp_postmeta develops table lock contention. Add-to-cart operations that should complete in 50ms can take 200–500ms, and that waiting time shows up directly in your INP processing time.

The fix: Enable High-Performance Order Storage (HPOS)

HPOS gives WooCommerce its own dedicated, properly indexed database tables. The performance improvement is significant:

Up to 5x faster order creation
Up to 40x faster order lookup on large stores
Measurably faster add-to-cart and checkout responses

Go to: WooCommerce > Settings > Advanced > Features > High-performance order storage

Enable it, then go to WooCommerce > Status > Tools and run “Sync order data” to migrate existing orders.

Important: HPOS has been the default for new installations since WooCommerce 8.2 (October 2023). If your store is older, you may still be on legacy storage without knowing it. Check the Features screen – if HPOS isn’t enabled, enable it.

HPOS is compatible with the vast majority of extensions. WooCommerce maintains a compatibility list. Any well-maintained payment gateway or shipping plugin will have added HPOS support by now.

Problem 7: Elementor and Page Builder DOM Bloat

If your product pages or shop archive are built with Elementor (or Divi, WPBakery, Beaver Builder), your DOM is likely larger than it needs to be, adding to the presentation delay phase of every interaction.

Elementor wraps every content block in 4–6 nested divs:

<div class="elementor-section">
  <div class="elementor-container">
    <div class="elementor-row">
      <div class="elementor-column">
        <div class="elementor-widget-wrap">
          <div class="elementor-widget">
            <!-- your actual content here -->
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

A product page with 20 content sections can add 120–150 extra wrapper divs. Google flags pages with more than 1,500 DOM nodes as excessive. Elementor-built pages frequently exceed 2,000–3,000 nodes.

Every time a user clicks something that triggers a DOM update (a cart widget updating, a variation changing, a quantity field incrementing), the browser recalculates styles and runs layout across all those nodes. More nodes = more work = higher presentation delay.

Fixes:

Enable Elementor’s Optimised DOM Output: Elementor > Settings > Advanced > Optimised DOM Output. This removes several wrapper divs from every element. Requires a cache clear after enabling.
Migrate to Elementor Flexbox Containers: If you’re still using legacy Section/Column structure, migrating to Containers (Elementor 3.6+) produces a significantly flatter DOM. Elementor has a migration tool under Dashboard > Tools > Convert to Containers.
Elementor’s Improved Asset Loading: Loads CSS per-widget on demand rather than one large global stylesheet. Reduces parser work on initial load.
Consider Gutenberg for commerce pages: If your product pages are simple (main image, description, add to cart, tabs), a block-theme approach with core Gutenberg blocks can produce DOM counts of 500–800 nodes versus Elementor’s 2,000+. The speed difference is measurable.

Which Plugin Should You Use?

Most WooCommerce stores need a performance plugin to implement several of these fixes without writing code. Here is how the main options compare for INP specifically:

WP Rocket

The most widely used WordPress caching and performance plugin. Good INP coverage:

Delay JavaScript Execution – delays third-party scripts until user interaction
WooCommerce cart fragments toggle
Defer JS with WooCommerce-safe default exclusion list
Page caching that works correctly around WooCommerce cart/checkout exclusions

Best for: Stores that want a well-supported plugin with sensible WooCommerce defaults out of the box. WP Rocket settings for WooCommerce include a dedicated tab covering caching exclusions, cart fragments and checkout – the important settings are pre-configured correctly. Less precise than FlyingPress for per-page script removal, but much easier to set up.

INP weakness: Delay JS uses a global list rather than per-page analysis. You get broader coverage but less surgical control.

FlyingPress

Growing significantly in 2024–2025 benchmarks for Core Web Vitals performance. Often edges out WP Rocket specifically on INP:

Per-URL analysis removes scripts not needed on specific pages
Cache Cart Fragments option (serves fragments from cache, faster than disabling)
More granular Delay JS controls
Better critical CSS generation per page

Best for: Stores where precision matters – high-traffic product pages, complex JS environments, stores with many plugins active.

INP strength: The per-page script removal is genuinely more precise. A script that only runs on /checkout/ can be excluded from all other pages automatically.

Perfmatters

Not a caching plugin – it pairs with Nginx, Cloudflare or another caching layer. Its strength is the Script Manager:

Disable any plugin’s JS or CSS on any URL pattern
Disable WooCommerce scripts on non-commerce pages precisely
Disable payment gateway scripts outside checkout
Disable Elementor scripts on pages built with Gutenberg
Dedicated toggles: Disable Cart Fragments, Disable Heartbeat, Defer JS, Delay JS

Best for: Developers and technically confident store owners. Gives the most control of any plugin. Combine with WP Rocket or Nginx caching for a full solution.

INP strength: Script Manager is unmatched for surgical disabling. Nothing else lets you say “load this script only on /product/, /cart/ and /checkout/”.

The Combination Most People End Up With

FlyingPress or WP Rocket + Perfmatters

FlyingPress or WP Rocket handles page caching, CSS/JS optimisation and delay. Perfmatters handles surgical script removal at the page-type level. The two are designed to complement each other and do not conflict.

Realistic INP Targets for WooCommerce Stores

Store Setup	Realistic Mobile INP (75th percentile)
Lightweight theme + minimal plugins + HPOS + Perfmatters	80–150ms (Good)
WP Rocket or FlyingPress, properly configured, HPOS on	150–220ms (Good to borderline)
Elementor-built + multiple plugins + basic caching only	300–600ms (Needs improvement to Poor)
Default WooCommerce + heavy page builder + no optimisation	600–1200ms+ (Poor)

WooCommerce product pages are consistently the hardest to get under 200ms – they carry more JavaScript than any other page on the store. If you fix product page INP first, checkout and archive pages usually follow.

Note on checkout pages: With Stripe or PayPal active, 200–250ms is a realistic floor for most stores. Payment gateway iframes require some main thread time. Getting checkout below 200ms is possible without third-party payment SDKs but unusual with them active. A 220ms checkout that was 680ms before optimisation is a genuine success.

Mobile vs desktop: Mobile INP is typically 35% worse than desktop due to lower CPU performance on Android devices. Always test with CPU throttling in DevTools to simulate real mobile conditions. Your desktop score looking Good while mobile scores Poor is common and expected if scripts haven’t been properly delayed.

How to Fix WooCommerce INP: Step by Step

Work through these steps in order. Each one is verified before moving to the next.

Enable HPOS: go to WooCommerce > Settings > Advanced > Features > High-performance order storage and turn it on. This is the single biggest server-side improvement for add-to-cart and checkout speed.
Check PageSpeed Insights field data for your product page, cart page and checkout page. Note the INP value and which pages are failing.
Open Google Search Console > Experience > Core Web Vitals and identify which page groups are showing as Poor or Needs Improvement.
Install Perfmatters or FlyingPress and disable cart fragments on all non-WooCommerce pages using the dedicated toggle.
Enable Delay JavaScript in your performance plugin to defer third-party scripts (GTM, analytics, live chat, Meta Pixel) until after the first user interaction.
Open the Script Manager and restrict payment gateway scripts (Stripe, PayPal) to load only on the /checkout/ page.
Disable the WordPress Heartbeat API on the frontend, or set its interval to 120 seconds, to remove a recurring AJAX call that blocks the main thread.
Go to WooCommerce > Status > Tools and run the Update variation lookup table action to speed up variable product interactions.
If using Elementor, enable Optimised DOM Output and Improved Asset Loading in Elementor > Settings > Advanced.
Run PageSpeed Insights again on product page and checkout to confirm improvement, then recheck Search Console after 28 days for field data changes.

Why INP Hit WooCommerce Stores Hard

FID – the metric INP replaced – was easy for WooCommerce stores to pass. It only measured the delay before the browser started responding to the very first interaction on a fresh page. Click the page once quickly after load and you passed, regardless of how slow everything after that was.

That’s why the switch to INP in March 2024 hit ecommerce disproportionately hard. INP measures every interaction throughout the session: Add to Cart, variation swatch, quantity change, coupon field, checkout steps. Every single one. WooCommerce stores that looked fine on FID suddenly showed scores of 400–800ms because all those subsequent interactions – the ones that actually matter – were never being measured before.

The fix is worth doing beyond just rankings. If you need to speed up WooCommerce and improve INP in a single pass, the seven problems in this guide are the only places that consistently move the needle. A 350ms reduction in Add to Cart response time is something customers actually notice – lower abandon rates, better conversion, a store that simply feels responsive. That’s not a benchmark number, it’s the real experience of every customer who visits.

Frequently Asked Questions

What is a good INP score for a WooCommerce store?

Under 200ms passes. 201–500ms needs improvement. Over 500ms is poor and actively hurts rankings. For WooCommerce specifically, product pages and checkout are the hardest to get under 200ms – they carry the most JavaScript. With HPOS on, cart fragments disabled and third-party scripts delayed, 150–200ms on product pages is achievable. Checkout with Stripe or PayPal active usually sits around 200–250ms – that’s a realistic floor when payment iframes are involved.

Why is my WooCommerce add to cart button slow to respond?

Almost always cart fragments. WooCommerce fires a background AJAX request on every page load to keep the header cart count updated. On shared hosting that request can take 500ms–1s, and if a customer clicks Add to Cart while it’s still running, their click gets delayed. Disable cart fragments on non-commerce pages (the code snippet in Problem 1 above does exactly this) and the button response time improves immediately.

Does disabling cart fragments break my WooCommerce store?

Disabling cart fragments entirely will break the live cart count in your header mini-cart for visitors who have items in their cart. The safer approach is to disable fragments only on pages where the cart widget does not appear – blog posts, the homepage, service pages – using a conditional dequeue or a performance plugin’s built-in toggle. This way cart and checkout pages continue updating the mini-cart normally.

What is the difference between INP and FID in WordPress?

FID measured only the delay before the browser started responding to the very first click on a page – nothing else. INP measures the full response time for every interaction throughout the session. Google replaced FID with INP in March 2024. The practical difference for WooCommerce: FID never measured add-to-cart, variation selection or checkout interactions. INP measures all of them, which is why stores that passed FID comfortably often fail INP badly.

How do I find out which interaction is causing my poor INP score?

Chrome DevTools Performance tab. Set CPU throttling to 4x slowdown (simulates a mid-range Android), click Record, perform the interaction, stop. Find the Interactions track and hover the block – it shows input delay, processing time and presentation delay broken out. Whichever is largest tells you where to look: input delay means something blocked the main thread before your click; processing time means the event handler was slow; presentation delay means the DOM was expensive to update.

Can WP Rocket fix WooCommerce INP?

Significantly, yes – but not completely on its own. WP Rocket’s Delay JavaScript and cart fragments toggle handle the most common causes. Where it falls short is surgical per-page script removal. Pair it with Perfmatters and the Script Manager fills that gap. Together they cover all the main INP causes without conflicts.

How long does it take to see INP improvement in Google Search Console?

Up to 28 days. Search Console uses a rolling 28-day window of real Chrome user data, so it’s slow to update. You’ll see improvement in PageSpeed Insights immediately (that’s a synthetic test), but the field data Google uses for rankings takes the full window to catch up. Make your changes, confirm with PageSpeed Insights, then check Search Console again in a month.

What causes poor INP on WooCommerce variable product pages specifically?

WooCommerce bakes all variation data into the page as a JSON blob – prices, stock levels, images for every combination. A product with 50 variations can embed 50–100KB of JSON. Every time a shopper clicks a swatch, the browser parses that entire object to find the right match. On a mid-range phone that takes 100–300ms, which shows up in the processing time component of your INP. Fix: run the variation lookup table update in WooCommerce > Status > Tools, keep products under 50 variations where possible, and look at variation plugins that load data on first click rather than pre-loading everything upfront.

Need Help With Your WooCommerce Store?

If you have worked through the checklist and still need to fix bad INP or can’t get your WooCommerce performance optimisation past a certain point, the remaining causes are usually one of three things:

A specific plugin is generating long tasks that cannot be removed without code – it needs to be replaced or refactored
Your server is too slow for the AJAX requests WooCommerce relies on – object caching (Redis), a faster database setup or managed WooCommerce hosting will help
Your page builder generates excessive DOM that cannot be fixed with settings alone – a partial or full rebuild with a lighter approach is the most effective route

Our WooCommerce Speed Optimisation Service covers all three. We diagnose the specific cause on your store, implement the fixes, and verify with before/after PageSpeed Insights and Search Console field data.