We Scanned 600 Dutch WooCommerce Sites: Here’s What’s Slowing Them Down

Dutch WooCommerce shops have a mobile performance problem. We know this because we run an ongoing scan of the .nl domain space looking for active WooCommerce installations — thousands identified so far, with more added every day. From the shops surfaced so far, we took a sample of more than 600 and ran each one through Google PageSpeed Insights for both mobile and desktop.

The results were worse than expected. Average mobile score: 59 out of 100. More than half the shops scored below 60. Twenty-two scored below 30 — territory where Google’s own research shows the majority of visitors leave before a product page finishes loading. Here is what we found, and why it keeps happening.

How we ran the analysis

We fetched .nl domains from the Common Crawl index — a public web crawl archive updated monthly. Each domain ran through an async WooCommerce detection scanner checking for active REST API endpoints, plugin asset URLs, cart fragment AJAX calls, and WooCommerce-specific body class patterns. Domains with two or more confirmed signals were treated as probable WooCommerce installations. From that filtered pool we selected sites with Dutch-language pages and non-service titles — active product shops rather than agencies or service businesses — and scored them via the Google PageSpeed Insights API for both mobile and desktop. The figures below reflect our sample as of May 2026; the scan is ongoing, so the shop count keeps growing.

Finding 1: Unused JavaScript is the #1 problem

On 95% of the shops we analyzed in depth, unused JavaScript was the top Lighthouse finding. The average wasted payload: 599KB per page. The worst case: 1.3MB of JavaScript the browser had to download, parse, and execute before anything visible appeared on screen.

Where does this come from? WooCommerce itself loads cart-related scripts on every page — including pages that have no cart. Page builders like Elementor and Divi bundle hundreds of kilobytes of JavaScript for components that may not appear anywhere on the page being viewed. Plugin authors rarely ship minimal builds, and the default WooCommerce configuration makes no attempt to defer or split these scripts.

The practical effect: the browser is blocked from rendering content while it processes scripts the visitor will never use. On mobile, where CPU is slower, this alone can add several seconds to the time before anything is visible.

Finding 2: The mobile/desktop gap reveals where the pain is

Mobile scores in our sample averaged 59/100. On the shops we scored both ways, mobile came in about 13 points below desktop — and that gap matters: it tells you the problems are largely mobile-specific. Desktop browsers run on faster CPUs, often on faster connections, and are more tolerant of bloated JavaScript. Mobile devices are not.

Below are four representative examples from our dataset, anonymized by sector:

Shop type	Mobile score	Desktop score	LCP (mobile)	Unused JS
Fashion retailer	15 / 100	20 / 100	22.1s	551 KB
Gift & beauty shop	32 / 100	58 / 100	6.9s	448 KB
Auto parts retailer	38 / 100	65 / 100	6.7s	736 KB
Sporting goods shop	37 / 100	65 / 100	6.3s	168 KB

The fashion retailer in the first row scored 15 on mobile and 20 on desktop — both platforms are struggling. The others show the more typical pattern: desktop is mediocre, mobile is poor. None of these sites had obvious technical problems on the surface. All were live, actively maintained shops with real product catalogs.

Finding 3: LCP consistently exceeds Google’s “poor” threshold

Largest Contentful Paint — the time until the page’s primary image or text block appears — was over 6 seconds on virtually every underperforming site in our sample. Google’s “good” threshold is 2.5 seconds. The “poor” threshold is 4 seconds. Most shops in our below-50 mobile cohort had LCP between 6 and 25 seconds.

The worst-performing site in our dataset scored 10 on mobile with an LCP of 46 seconds. This shop was ranking organically, running traffic, and sending visitors to a page where the main image took nearly a minute to appear on a standard 4G connection. Cart abandonment at that speed is not a risk — it is a certainty.

The causes are consistent across sites: a large above-the-fold product or hero image served without proper dimensions, no server-level caching so WooCommerce generates the page dynamically on every request, and render-blocking scripts delaying the browser’s ability to display anything at all.

Why WooCommerce sites are especially vulnerable

Static WordPress sites can be heavily optimized with minimal configuration. WooCommerce adds persistent complexity: cart sessions, dynamic pricing, stock status checks — legitimate reasons why some caching strategies cannot be applied universally. Plugin authors respond to this by defaulting to safe configurations that sacrifice performance for compatibility.

The result is that a freshly installed WooCommerce shop — even without any customization — carries meaningful performance debt. Every plugin added for functionality adds more JavaScript and CSS. Most shops run five to fifteen plugins. Almost none have a caching layer correctly configured to exclude only the pages that genuinely cannot be cached (cart, checkout, account) while caching everything else aggressively.

What a fix actually looks like

Improving scores in the 30–50 range does not require switching platforms or rebuilding anything. The highest-impact interventions are consistently the same:

• Configure caching correctly — WP Rocket or W3 Total Cache with proper WooCommerce exclusions for cart, checkout, and account pages. FastCGI caching at the server level is more effective still.
• Convert images to WebP — typically a 30–70% reduction in image payload with no visible quality loss. Hero and product images are the highest-priority targets.
• Defer non-critical JavaScript — most plugin scripts do not need to execute before the page is interactive. Deferring or asynchronously loading them removes the render-blocking penalty.
• Set explicit image dimensions — missing width and height attributes cause layout shifts and prevent the browser from reserving space before images load, which inflates LCP.

For a typical shop scoring in the 30–50 range on mobile, these changes reliably produce a 20–40 point improvement and cut LCP by 50% or more. The work is not glamorous. It does not require a redesign. It does require knowing which WooCommerce pages must remain uncached and which caching rules to write around them — that is where most DIY attempts go wrong.

Frequently Asked Questions

• Does a low PageSpeed score actually affect sales? Google’s research consistently shows that each additional second of load time increases bounce rate by 20–30%. For mobile e-commerce, a 1-second improvement in LCP correlates with roughly 10% more conversions.
• Does Google use PageSpeed score as a ranking factor? Core Web Vitals — which include LCP, CLS, and INP — are a confirmed Google ranking signal as of 2021. A poor score is not an automatic penalty, but it is a disadvantage when other ranking factors are equal.
• Can I fix this without changing my theme or plugins? In most cases, yes. Caching configuration and image optimization are independent of theme choice. JavaScript deferral may need testing against your specific plugin stack, but rarely requires removing functionality.
• How long does an optimization take? For a typical WooCommerce shop, the core work — caching setup, WebP conversion, JS deferral — takes two to three days. Results are visible in PageSpeed Insights immediately after deployment.