WooCommerce Performance Audit: My 15-Minute Method

When I receive an audit request, I always start the same way: 15 minutes of structured analysis that give me a clear picture of the site’s health. I don’t even need admin access for this first pass. Here’s how I do it. This method is part of my WooCommerce optimization service.

Minute 1-3: Field Core Web Vitals

I start with real data, not lab data. Google provides CrUX (Chrome User Experience Report) metrics that reflect what your actual visitors experience.

Tool: PageSpeed Insights

I test three pages:

The homepage
A product page (the most visited if I know it, otherwise a random one)
The main category page

What I look at first:

LCP (Largest Contentful Paint) - Time until the main content is visible. Above 2.5 seconds, there’s a problem. On a misconfigured WooCommerce, I regularly see 4 to 6 seconds on mobile.

INP (Interaction to Next Paint) - Click responsiveness. Above 200ms, the experience is degraded. Heavy scripts (cart fragments, jQuery) are usually responsible.

CLS (Cumulative Layout Shift) - Visual stability. Images without dimensions and late-loading fonts make the page “jump.”

As the official WooCommerce guide on Core Web Vitals points out (source: woocommerce.com), these metrics directly influence both ranking and conversions.

Minute 3-7: The Loading Waterfall

Tool: Browser DevTools (F12 → Network)

I reload a product page and examine the waterfall. What raises red flags:

Request count. Over 80-100 requests on a product page is too many. Each plugin adds its own CSS and JS files - often on every page, even when they’re not needed.

Total weight. Over 3 MB on mobile is problematic. I’ve seen stores at 8-10 MB per page because themes like Elementor or Divi load 200-400 KB of their own framework.

admin-ajax.php and wc-ajax. As WP Engine’s documentation explains (source: wpengine.com), admin-ajax requests are uncacheable - each request is processed fresh by PHP. If I see get_refreshed_fragments in the waterfall, cart fragments is active on that page. On a 10,000 visits/month site, that’s ~300,000 useless server requests.

Third-party scripts. Google Analytics (gtag.js), Facebook Pixel, Hotjar - each adds 50-150 KB. If the site doesn’t use Cloudflare Zaraz or a server-side equivalent, these scripts tank Total Blocking Time.

Google Fonts. Each font family = a render-blocking request to Google servers. System fonts eliminate this problem entirely.

Minute 7-10: The Database (if admin access)

Tool: Query Monitor

Query Monitor is essential. It shows SQL query count per page, execution time, and most importantly, which plugin is responsible for each query.

What I check:

Autoloaded options. A simple SQL query gives me the total weight:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

According to Kinsta (source: kinsta.com), the recommendation is to stay under 800 KB. Above 1 MB, it’s a problem. I’ve seen WooCommerce sites at 5-10 MB of autoloaded options - often from uninstalled plugins that left their data behind.

Slow queries. Query Monitor identifies them and shows which plugin generates them. Meta queries on wp_postmeta are the usual culprits, especially on catalogs with ACF fields.

Expired transients. They silently accumulate in wp_options and bloat the table for no reason.

Minute 10-12: The Checkout

I simulate a complete purchase flow. What I check:

Checkout type. Legacy shortcode [woocommerce_checkout] or block checkout? Legacy is heavier and less performant - migrating is often a quick win.

Field count. Every unnecessary field increases the abandonment rate. According to the Baymard Institute, 22% of abandonments are due to a process that’s too long.

Payment gateways. How many JS scripts do they load? Some older gateways load jQuery and their own files on every page of the site, not just at checkout.

Cache. Cart and checkout pages must not be cached (otherwise one customer sees another’s cart). But the rest of the site should be. I check cf-cache-status headers if the site is on Cloudflare.

Minute 12-15: Hosting

Tool: TTFB without cache

I measure TTFB by bypassing cache (adding a random parameter to the URL). This gives me the raw server response time.

Under 300ms: good
300-600ms: acceptable
Over 600ms: hosting is probably undersized

What I note:

PHP version (8.2+ minimum, each major version brings 10-20% gains)
Redis presence (Object Cache)
Hosting type (shared, VPS, managed)

As Remkus de Vries points out in his article on WooCommerce performance (source: remkusdevries.com), shared hosting isn’t suitable once your store loads product variations, cross-sells, cart fragments, and personalized content in real time.

The Result

In 15 minutes, I have a clear list of issues ranked by impact. It usually looks like this:

Quick wins (immediate impact, low risk): disable cart fragments, remove unused scripts, enable page cache
Medium optimizations (a few hours of work): clean autoloaded options, migrate to block checkout, configure Cloudflare
Structural projects (heavier): HPOS migration, FSE theme switch, ACF data architecture redesign

This is the list I send you when you request a free audit.

Want to know what’s slowing your store down? Request a free audit - personalized report within 48 hours.