I benchmarked 25 random WooCommerce stores. The distribution surprised me.

Two weeks ago I started a small experiment. I wanted to know what WordPress performance actually looks like in the wild — not the cherry-picked examples in blog posts and vendor case studies, but on real stores running real traffic.

So I pulled a random sample of 25 WooCommerce sites from a public index of sites running a common plugin combination, ran Google’s PageSpeed Insights on the homepage and the cart page of each one, and collected the numbers. Fifty measurements in total. Desktop strategy. Aggregated, small sample.

Here’s what the data said, and the one thing I didn’t expect.

The method, briefly

The sample came from a source-code search — specifically, sites running both WooCommerce and Jetpack, two plugins common in small-to-medium WooCommerce stacks. From a list of thousands of matches, I took the first 25 that were real commerce sites in English-speaking markets. Non-commerce sites that happened to have WooCommerce installed (blogs, nonprofits, magazines) were filtered out by hand.

For each site, I hit the homepage (/) and the cart page (/cart) through the PageSpeed Insights API, desktop strategy. I recorded Largest Contentful Paint, Time to First Byte, and First Contentful Paint. PageSpeed runs Lighthouse under the hood, which means the numbers are directly comparable to what you see if you run your own site through pagespeed.web.dev.

Sample size is small — 25 sites — so read this as directional, not definitive. The distribution pattern was visible enough that I don’t think it needs statistical rigor to draw conclusions from. But a 500-site run would say something more certain.

Homepage LCP distribution

Largest Contentful Paint is Google’s headline performance metric for user experience. Under 2.5 seconds is “Good”, 2.5 to 4 seconds is “Needs improvement”, over 4 seconds is “Poor”.

Across the 25 homepages:

• Median: 1.5 seconds
• 75th percentile: 1.9 seconds
• 90th percentile: 4.2 seconds
• Maximum: 9.0 seconds

Categorized by Google’s thresholds:

• 19 sites (76 percent) landed in Good
• 1 site (4 percent) landed in Needs Improvement
• 5 sites (20 percent) landed in Poor

Three quarters of these homepages would pass Google’s Core Web Vitals threshold. The median site is fine. The 76 percent don’t need the kind of optimization intervention most performance blogs pitch.

The other 20 percent are a different universe. The five slowest homepages in the sample measured 4.0, 4.2, 4.8, 6.6, and 9.0 second LCP — numbers that make most common optimization advice feel beside the point.

Cart page distribution (the surprise)

I expected cart pages to be worse. Cart pages are dynamic, per-user, never cached. The prevailing narrative on WordPress performance — one I’ve been repeating in my own writing — is that cache plugins leave cart, checkout, and my-account untouched, which is where slowness lives.

The data disagreed, or at least heavily qualified it.

Across the 25 cart pages:

• Median: 1.5 seconds
• 75th percentile: 1.7 seconds
• 90th percentile: 2.3 seconds
• Maximum: 4.5 seconds

Categorized:

• 23 sites (92 percent) were Good
• 0 sites were in Needs Improvement
• 2 sites (8 percent) were Poor

Cart pages in this sample were better than homepages. In the median case, home and cart LCP were effectively identical. In the tail, homepages were far worse than carts. The worst homepage (9.0s) was twice as slow as the worst cart (4.5s).

This wasn’t what I expected. It broke one of my priors about WordPress performance.

My best guess at why: homepages on WooCommerce sites usually carry the entire marketing surface — hero sections, sliders, multiple product feeds, testimonial blocks, newsletter opt-ins, page-builder chrome. Cart pages, by contrast, are structurally simpler. Less HTML, fewer third-party widgets, fewer decorative plugins contributing content. The plugin boot tax is the same on both, but the front-end burden differs.

“Cart pages are slow on WordPress” is true in a narrow sense — cache can’t help them, which is a real constraint. But slowness on cart pages is actually less common than slowness on homepages. At least in this 25-site sample.

Why the tail matters more than the median

The average WordPress performance post online is written for the median site — the 76 percent. Install WP Rocket. Run Autoptimize. Enable object cache. Upgrade hosting. That advice is correct for three quarters of WooCommerce stores.

It’s also approximately zero help for the remaining 20 to 25 percent.

Get Sarp EFE’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Those sites — the ones with 4+ second LCP — aren’t slow because they skipped the optimization basics. Poking at them, they all share a pattern: plugin-heavy stacks with page builders, booking widgets, marketing integrations, auth plugins, form plugins, and security plugins, all loading on every request.

The homepage pays the tax of every plugin installed, whether or not that plugin renders anything on the homepage.

No amount of page cache fixes this layer, because page cache caches the rendered output. The PHP still has to run to produce that output the first time. With 30 plus active plugins, the PHP pipeline alone eats one to two seconds before anything gets rendered.

This is the layer that general performance advice doesn’t reach. And it’s the layer where the tail sites live.

What the tail sites have in common

Without naming anyone, the five worst homepages in this sample shared these characteristics:

• A page builder plus a theme framework plus additional page-builder addons (often five to ten JavaScript bundles between them)
• A marketing automation plugin, usually CRM-linked
• A security plugin
• A backup plugin
• Three or more WooCommerce extensions
• At least one plugin for forms, popups, or lead capture
• Often a booking or appointment widget

None of these plugins are bad. Each one does its job. The problem isn’t any specific plugin; it’s what WordPress does by default. Every active plugin runs its plugins_loaded and init hooks on every single request, regardless of whether that request uses the plugin's features.

On a site with five plugins, that’s fifty to one hundred milliseconds of overhead. Fine.

On a site with thirty to forty plugins, that’s one to two seconds of overhead. Not fine.

The heavier your stack, the longer the tax. Plugin count is roughly linear with plugin-boot time, and somewhere north of fifteen active plugins the cost stops being negligible.

What the performance-advice industry misses

Most WordPress optimization tooling assumes one of three things.

First, that the problem is cache-shaped. Install WP Rocket, save HTML for anonymous visitors. This solves about 70 percent of visits on about 75 percent of sites. Real value, clear scope.

Second, that the problem is asset-shaped. Dequeue CSS and JavaScript on specific pages. Reduces transfer size, doesn’t change PHP execution time.

Third, that the problem is hosting-shaped. Upgrade to managed WordPress hosting. Gives you a faster CPU to run the same code on.

None of these stop plugins from loading on requests where they aren’t needed. That’s the tax the tail sites are paying.

There’s a category missing from most optimization stacks: conditional plugin loading. Per-request, per-page decisions about which of the 30 active plugins actually need to boot for this specific request. Your Mailchimp integration probably doesn’t need to boot on a cart AJAX refresh. Your backup plugin probably doesn’t need to boot on a REST API call for product stock. Your booking widget probably doesn’t need to boot on a homepage that doesn’t contain the widget.

That’s the layer that doesn’t show up in most WordPress performance conversations. Full disclosure: I’ve been building a tool that operates on this layer, in closed beta. But the existence of the category matters more than the specific tool. If you’re running a plugin-heavy site and cache plus asset optimization haven’t solved your homepage, this is the layer you’ve been missing.

How to tell if your site is in the tail

The fastest diagnostic takes sixty seconds.

1. Open your site in a private or incognito browser window to bypass any logged-in caching.
2. Open DevTools, Network tab.
3. Filter requests by /wp-content/plugins/.
4. Hard-refresh your homepage.
5. Count the asset requests coming from your plugin folders.

If you’re running 10 to 15 active plugins and seeing 30 to 40 asset requests before the page finishes loading, you’re probably not in the tail.

If you’re seeing 80 to 120 asset requests before the page finishes, you probably are. The exact threshold varies by stack, but the ratio of asset requests to active plugins is a better predictor than plugin count alone.

The next question is which of your plugins are doing work that doesn’t belong on your homepage specifically. That’s where individual judgment enters. Each plugin needs to be classified by whether it renders visible content on the current page, or whether it just loads its code out of default inertia.

If you want me to look at yours

I’ve been offering a free Network-tab analysis to readers who reach out. If your site looks like it might be in the tail — page-builder-heavy, SMB commerce, feels slow despite running the standard optimization stack — reply with your URL. I’ll run the same measurement I ran on the 25 sites above, plus open up the plugin map, and send you a written breakdown of which plugins look like they’re contributing to the tail on your specific site.

No obligation, no sales pitch. Part of why I’m running this research openly is to see the full distribution of plugin patterns across real sites.

sarp@for-wordpress.org — include your site URL and a one-line description of your stack.

What’s next

The obvious next version of this study is a larger sample — 100 to 500 sites — with more statistical weight and a proper report on the correlation between plugin count, plugin categories, and tail latency. If that’s interesting to you, the blog at for-wordpress.org/blog will have the next run when it’s ready.

In the meantime: if you’ve been nodding along reading this and thought “my site sounds exactly like those tail sites”, you’re probably right. The good news is the fix is narrower and more precise than most WordPress performance advice suggests. The bad news is most tools don’t reach this layer yet.