Short answer: speed is not a technical metric, it is a multiplier on the whole funnel. It acts on conversion, on search rankings and on the price of a paid click at the same time. It is the one improvement you cannot make "for a single channel" — it works everywhere at once.
What Google actually measures
Since 2020 there are three metrics Google collects from real users of your site, not from a lab. They are called Core Web Vitals, and the thresholds are:
| Metric | What it means in plain terms | "Good" threshold |
|---|---|---|
| LCP | When the main block appears — the product photo, the heading | under 2.5 s |
| INP | How fast the page responds to taps and clicks | under 200 ms |
| CLS | How much the content jumps around while loading | under 0.1 |
One detail people routinely miss: you are scored at the 75th percentile. It is not enough that "it opens fast on my laptop" — three quarters of real visits, including old Android phones on mobile data, have to fit inside the threshold.
In WordPress stores the metric that fails most often is INP: the page paints, but then ignores taps for another second because plugin scripts, the chat widget, pixels and cart fragments are still running. Users don't read that as "slow site" — they read it as "broken site", and they hit back.
What it costs in money
The most honest public illustration is the Vodafone case study on web.dev: an A/B test on two visually identical versions of a page showed that a 31% improvement in LCP produced 8% more sales. No redesign, no new promotion — speed alone.
Translate that into your own numbers the same way as in the first topic: if the store does €40,000 a month, 8% is €3,200 every month. The speed work is a one-off.
There is a second effect people rarely count: speed changes what advertising costs you. A slow landing page hurts quality scores in ad platforms and raises cost per click. You pay twice — fewer people arrive, and each arrival cost more.
Why WooCommerce specifically gets slow
WooCommerce is not slow by itself. What makes it slow is the typical build around it. From my audits, the order of culprits is almost always this:
1. A page-builder theme. A multipurpose theme with a visual builder drags dozens of CSS and JS files onto every page — including the ones only the homepage needs. This is the most common and most underestimated cause.
2. Plugins that load everywhere. The slider, form, review and shipping-calculator plugins each register their scripts across the whole store rather than only where they are used.
3. No page cache. Every category visit becomes a full PHP cycle plus database queries. On €5/month shared hosting that is 1.5–3 seconds before the first byte.
4. Cart fragments. By default WooCommerce calls wc-ajax=get_refreshed_fragments on every page to refresh the cart counter. On an otherwise cached site this is the one uncacheable request that holds everything up.
5. Images at original size. The photographer delivered 4000 px, 3 MB JPEGs and they were uploaded as-is. The browser downloads 3 MB to show a 600 px image.
6. Third-party scripts. Chat, pixels, maps, review widgets. Each looks harmless; together they eat your INP.
What to fix, in order of payback
The order matters — cheapest and most effective first:
- Images — convert to WebP/AVIF, serve the right size, lazy-load everything below the fold but not the main product photo (that ruins LCP)
- Page cache + object cache — static caching for categories and product pages, Redis or Memcached for database queries
- Disable cart fragments where they aren't needed, or replace them with a lightweight counter update
- Clean out plugins — remove the unused ones, restrict script loading to the pages that actually need them
- Defer third-party scripts — load chat and pixels after interaction, not in the
<head> - Fonts — self-host,
font-display: swap, only the weights you use - Hosting — if TTFB is still above 600 ms after all of the above, it is the hardware, not the code
The first three usually deliver 70% of the result and take a few days. Technical detail on each lives in the neighbouring guide: Core Web Vitals, images, fonts and scripts and caching.
Developer note
- Turn on HPOS. High-Performance Order Storage moves orders out of
wp_posts/wp_postmetainto dedicated tables. On a store with tens of thousands of orders it transforms both the admin and any order-related query. - Measure field data, not lab data. PageSpeed Insights lab mode is useful for debugging, but the scoring uses CrUX field data. The Core Web Vitals report in Search Console is the one that counts.
- Hunt long tasks, not "page weight". INP is killed by specific handlers: cart re-rendering, the slider script, synchronous analytics code. Profile the Performance tab instead of counting kilobytes.
- Check autoloaded options.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'— if that is megabytes, every single request drags the junk along. It is usually residue from deleted plugins. - Verify on a throttled mobile profile, network and CPU. Everything is fast on your MacBook.
When theme optimisation stops helping
There is a point beyond which there is nothing left to improve: the theme and plugins impose a floor of work you cannot remove without breaking the store. Signs you have hit it:
- Mobile LCP is stuck at 3–4 seconds even though images and caching are already handled
- Every new plugin visibly degrades the metrics
- You are forced to choose between "fast" and "has the features we need"
At that point there are two paths. One is to cut functionality: drop the builder, rewrite templates, remove plugins. The other is to split storefront from backend: keep WooCommerce for products, orders and the admin, and build the frontend separately on a fast stack. How that works and when it pays off is on the WooCommerce and headless page, including an honest account of when it does not. A ready-made solution of that type is NextWoo, a Next.js storefront on top of an existing WooCommerce.
Practical check
- Opened the Core Web Vitals report in Google Search Console and looked at mobile URLs
- I know LCP, INP and CLS from field data, not just a lab test
- Checked the weight of the main product photo — under 150–200 KB
- Checked TTFB on a category page — under 600 ms
- Disabled or limited cart fragments
- Reviewed the plugin list: each one is either needed or gone
- Calculated what 8% more sales is worth in my own money
What's next
A fast store is a precondition, not a reason to buy. Next the visitor lands on a product page and decides whether they trust you enough to hand over money: the product page that sells.
If you'd rather hand this over: website speed optimisation — audit, prioritised work list and a fixed price for the implementation.