The WooCommerce Debloat Guide: Patching Out Automattic’s Tracking & Bloat

Disabling WooCommerce tracking doesn’t disable WooCommerce tracking.

That sentence is worth reading again. Buried in the WooCommerce source code is a tracking infrastructure that operates entirely independently of the toggle you were told would switch it off. Automattic — the company behind WordPress.com, WooCommerce, and Jetpack — has built a system that monitors nearly every action you take in the admin area, fires pixel requests to pixel.wp.com, and phones home to Jetpack servers, regardless of what your settings say.

I didn’t set out to find this. I was investigating why WooCommerce admin areas were running slow across my hosting clients’ sites. What I found, when I started reading the code, was quite a lot of shit.

My WooCommerce website feels slow

If you’re running a WooCommerce website that processes hundreds of sales every month, there’s probably a small team of people accessing the back-end of WooCommerce all throughout the day. Each WordPress/WooCommerce browser tab runs a “heartbeat”, which is a periodic request/response from the browser to the server, and back to the browser. In the back-end of a Woo site, logged in as an administrator, this request can sometimes take several seconds, even on good hosting. If you’ve got 3+ staff using the back-end of Woo, each with one-or-more tabs left open on their computers, that’s a lot of time that the server’s PHP worker threads are tied-up doing work.

Every PHP worker thread that’s servicing a heartbeat request is a PHP worker that can’t serve content to a customer.

The solution to the “slow WooCommerce” problem is two-fold:

1. Reduce the number of heartbeat requests the server needs to deal with. This is a combination of staff training, and tweaking WordPress to increase the time between heartbeat requests.
2. Speed up the admin area requests & responses (heartbeat and otherwise). This is more complex, because WooCommerce is so bloated these days.

A quick Woo fix

The first thing I did was add a code snippet to reduce the “aggressiveness” of the WordPress heartbeat. This snippet works for any WordPress website, but is especially useful when there’s a team of people with multiple admin-area tabs open.

/**
 * Modify the WordPress Heartbeat API interval to minimise server load.
 *
 * Increase the Heartbeat execution interval to 5 minutes (300 seconds). 
 * This reduces the frequency of admin-ajax.php requests, optimising 
 * server resource allocation during prolonged editing sessions.
 *
 * @param array $settings
 * @return array The modified Heartbeat API settings.
 */
function custom_heartbeat_interval( $settings ) {
    $settings['interval'] = MINUTE_IN_SECONDS * 5;

    return $settings;
}
add_filter( 'heartbeat_settings', 'custom_heartbeat_interval', PHP_INT_MAX, 1 );

That reduced the heartbeat from once every 60 seconds (or whatever the WordPress default is, these days), to once every 5 minutes. This slashed the number of requests browsers were making to the server.

Tip: You can change MINUTE_IN_SECONDS * 5 to MINUTE_IN_SECONDS * 10 if you want to throttle it back some more.

But… that was just a workaround, really. The core problem is that back-end WooCommerce requests were running slow.

Investigating slow WooCommerce admin page-load

Usually, slow page-load is not because the server itself is being slow… it’s because PHP is locked into a “waiting state” for some reason. And this reason is usually that a plugin is trying to call home to the plugin developer’s website. In the case of WooCommerce, the plugin developers are Automattic (the WordPress people).

To start diagnosing this, I activated the Query Monitor (QM) plugin. It’s my go-to tool for diagnosing troublesome WordPress websites. One of QM’s tools is that it will monitor outbound HTTP API calls that use WordPress’ wp_remote_get() (and the POST version).

Poking about the back-end of my development website, it was clear there were multiple WooCommerce API calls happening, to various domains (including jetpack.com).

Trying the obvious

The first thing to do was to check & disable some Woo options:

• Order Attribution: this is a front-end page-speed killer. If you already use Google Analytics, or a self-hosted tool like Independent Analytics, switch off order attribution.
• Disable WooCommerce tracking (WooCommerce > Settings > Advanced > woocommerce.com)
• Disable WooCommerce marketplace suggestions

The “marketplace suggestions” was surprisingly noisy – WooCommerce (Automattic) spend a lot of energy trying to promote their own services above other available services, so the WooCommerce marketplace and the general plugins page will always list WordPress/Automattic software above more relevant options.

The worst thing about this set of actions is that disabling tracking… doesn’t really disable tracking. The WooCommerce tracking JS code is always injected into WooCommerce admin page-load HTML, and we see this sort of workflow:

A deep code-dive and software patch

Adjusting settings wasn’t going to cut it. I needed to dive into the WooCommerce plugin source code and patch it.

I started by adding a snippet to the WooCommerce plugin itself to always disable the marketplace suggestions & tracking. Then I looked into the tracking code itself and patched that out… so the tracking to Automattic really was disabled.

This was a big step forward. With these modifications in place, I was confident I could produce a “diff patch” for WooCommerce that would dramatically improve performance, without degrading functionality.

Tracking admin UI interactions

WooCommerce includes a sophisticated tracking system (includes/tracks/class-wc-tracks-client.php) that monitors nearly every action you take in the admin area. This system sets identity cookies, batches events, and fires pixel requests to pixel.wp.com on every page load and AJAX request – even when you’ve disabled tracking in settings.

The reason? The code that runs tracking is separate from the toggle that enables it. Disabling the toggle just sets a flag elsewhere. The tracking infrastructure still loads, initialises and makes the outbound HTTP API calls. For a busy WooCommerce store with multiple staff, this means hundreds of outbound HTTP requests per day, each consuming resources that could be used to serve customers.

WooCommerce Marketplace upsells

Automattic has embedded an aggressive marketplace promotion system into WooCommerce (includes/admin/class-wc-admin-marketplace-promotions.php). This includes:

• Scheduled cron jobs that fetch extension “suggestions” from woocommerce.com
• Admin notices promoting Automattic’s own extensions (often positioned above more relevant third-party options)
• Dashboard widgets and admin area clutter designed to drive extension sales

The cron jobs consume server resources, the API calls add latency, and the UI elements slow down the admin experience.

The Jetpack connection

WooCommerce includes Jetpack connection infrastructure (vendor/automattic/jetpack-connection/src/) that acts as a bridge to Automattic’s servers. This feels borderline “naughty” to me. If my customers want the bloated Jetpack experience, they can install the Jetpack plugin. It shouldn’t be baked into WooCommerce core.

The Jetpack connection…

• Initialises on every request.
• Registers REST endpoints for remote plugin installation!
• Sends periodic heartbeat checks to api.jetpack.com
• Allows Automattic to remotely monitor your site and push updates without explicit per-request consent!

This is the “phone home” infrastructure… separate from WooCommerce tracking, and deeply pervasive.

Why disabling settings doesn’t work

The fundamental issue is architectural. WooCommerce’s toggle switches (in Settings > Advanced) don’t actually prevent the code from loading—they just change a flag that the code checks after it’s already running. The initialisation, network calls, and blocking happen before the code even gets to that flag check.

This looks like a deliberate design choice by Automattic. Their business model depends on understanding how WooCommerce is used and upselling services. Tracking benefits them more than it benefits you.

The patch strategy

Rather than trying to work around this, I decided to patch WooCommerce itself and disable these features at the code level.

The approach was simple: short-circuit the initialisation methods before they do any work. Rather than deleting code (risky), I added an early return; statement at the beginning of key initialisation methods:

public static function init() {
    return; // Disable [feature]

    // Original code below (now unreachable)
    add_action( 'admin_init', array( __CLASS__, 'maybe_set_identity_cookie' ) );
    // ...
}

Why this approach:

• Minimal code change (single line per feature) = low risk of breaking dependencies
• Clear intent (comment explains why)
• Safe (doesn’t break hooks or filters that depend on the class existing)

What I patched:

Tier 1 (Safe to apply):

• Disable WC_Tracks_Client (tracking pixels)
• Disable Jetpack Connection Manager
• Disable Jetpack Heartbeat
• Disable Legacy Setup Wizard
• Disable Marketplace Promotions cron
• Disable Dashboard Setup widgets

Tier 2 (Needs testing):

• Disable Marketplace Suggestions UI
• Disable Legacy Reports (conditional)
• Conditional admin asset loading
• Selective admin notice suppression

Performance gains

After applying Tier 1 patches:

• Admin page load time: 200–500ms faster.
• HTTP requests per admin load: 2–4 fewer requests. This is the big win.
• Cron jobs: Marketplace fetches eliminated.
• Privacy: Zero outbound calls to Automattic infrastructure for tracking/marketplace/heartbeat.

Testing & deployment

Pre-patch checklist

Before applying the patch:

• Backup WordPress database
• Backup WooCommerce plugin directory
• Note your current WooCommerce version
• Check error log baseline: tail -50 /var/www/[site]/log/error.log

Applying the patch

cd /path/to/wp-content/plugins

# Apply the patch
patch -p1 --directory=woocommerce < /path/to/woocommerce-[version].patch

# Check for rejects (if any lines didn't apply cleanly)
ls woocommerce/**/*.rej 2>/dev/null && echo "Check rejects!" || echo "Clean apply"

Post-patch testing

In the admin:

1. Load dashboard: check for warnings or console errors
2. Edit a product: verify rendering is correct
3. Check settings pages
4. Test order processing and payment flows

In the logs:

# Follow the site's error logs
tail -f /var/www/[site]/log/error.log

We should see zero new errors.

Network verification:

# You may need to install this with: sudo apt install tcpdump
sudo tcpdump -i eth0 -A 'host woocommerce.com or host pixel.wp.com'

Should see nothing (no requests to those domains). You may need to swap out “eth0” for your network interface.

Functionality check:

# Check the tracking is switched off (not that the setting works properly though)
wp --path=/var/www/[site]/web option get woocommerce_allow_tracking

Should return: no

Rollback process

If something breaks, just reinstall the stock WooCommerce plugin (latest version). You can do this with WP CLI quite easily:

# Re-install the stock WooCommerce plugin
wp --path=/var/www/[site]/web install woocommerce --force

Real-world impact

Across my network of hosted WooCommerce sites, this pattern was consistent:

• Average admin page load time dropped by ~250ms
• Eliminated ~3 HTTP requests per admin action
• Stopped cron job overhead from marketplace fetches
• Improved UI experience for store admins (faster workflows, less frustration, more server resource available for customer page-load requests)

Safety record: No breaking changes to core e-commerce functionality. Order processing, payments, shipping, and customer-facing features all work exactly as before. Extensions work as normal (they’re not targeted by the patch).

---

An open-source patch for anyone to use

Why build an open-source patch?

After implementing this on my own hosting platform, I realised other hosts and Woo store admins would be facing the same problems. Rather than keep the patch to myself, I shared it as an open-source project so the broader WordPress community can benefit.

Enter: woocommerce-debloat

What is woocommerce-debloat?

woocommerce-debloat is a curated patch suite for WooCommerce that removes tracking, marketplace promotions, Jetpack phone-home behaviour, and other bloat… without breaking core functionality.

It’s designed for:

• Hosting providers managing multiple WooCommerce sites (easy to deploy at scale)
• Site owners who want faster admin performance and privacy
• Developers who want a reference for patching WooCommerce safely

How to use it

The repository includes pre-built patches for multiple WooCommerce versions. You simply:

1. Download the patch for your WooCommerce version
2. Apply it to your WooCommerce plugin directory
3. Test (using the checklist above)
4. Deploy with confidence

Full instructions, compatibility matrix, and troubleshooting are in the README.

Maintaining patches across WooCommerce updates

WooCommerce releases regular updates. When a new version lands, the patch may need minor adjustments (usually just line number offsets). The repository includes:

• A changelog tracking which patches apply to which versions.
• Instructions for maintainers to update patches.
• Tools for analysing the woocommerce plugin for new performance opportunities.

Because I host a lot of WordPress and WooCommerce websites, I usually get new versions of WooCommerce patched within 24 hours. But I can’t guarantee this, so if your site becomes dependent on the patch, be aware there may be a lag of a couple of days between WC updates and a new patch becoming ready.

Contributing & reporting issues

The project welcomes contributions:

• Found a new source of bloat we missed? Submit a pull request, leave a comment on this post or contact me directly.
• Discovered a safer way to patch something? Let’s discuss it.
• Found a breaking change? Open an issue with reproduction steps.

Get the latest WooCommerce patch

ℹ️ This patch is NOT an attempt to nullify commercial plugins or extensions. I created it to improve my hosting clients’ WooCommerce admin area performance, and to stop unnecessary data being sent to third parties without meaningful consent. If you’re looking for something that lets you use commercial WooCommerce extensions without paying, you’re looking in the wrong place.