Caching and Optimization Exclusions

This page lists the exact scripts, paths and endpoints to exclude if a caching, minification or performance plugin needs to be told to leave the Pixel Manager alone.

Short answer

In almost all cases you don't need to exclude anything. Page caching is fully supported by design, and the Pixel Manager applies the required JavaScript optimization exclusions automatically for the most common optimization plugins. Only add manual exclusions if you actually see tracking break, or if your optimizer is not in the automatic list.

Handled automatically

For these plugins the Pixel Manager registers its own exclusions at runtime. There is no setting to switch on, and nothing to add by hand:

Plugin	What the Pixel Manager excludes automatically
WP Rocket	JS minification, JS combination, inline JS optimization, plus Delay JS on cart, checkout and order confirmation pages
LiteSpeed Cache	JS minification and combination
SiteGround Optimizer	JS combination (including inline), JS minification, and jQuery deferring
Autoptimize	JS minification (treated as already minified) and script moving
WP-Optimize	JS minification
Optimocha (Speed Booster Pack)	JS optimization (adds the Pixel Manager to the exclusion list, removes it from the include list)
FlyingPress	Delay-until-interaction for tracking scripts on cart, checkout and order confirmation pages

The Pixel Manager also purges the cache when you change its settings, so you don't keep serving stale HTML after a configuration change. That covers the plugin layer (NitroPack, WP Rocket, LiteSpeed, Autoptimize, Hummingbird, W3 Total Cache, WP-Optimize, WP Super Cache, WP Fastest Cache, FlyingPress), the host layer (SiteGround, WP Engine, Kinsta, Nginx Helper, Proxy Cache Purge) and Cloudflare.

info

Purging is not the same as excluding. For NitroPack, W3 Total Cache, WP Super Cache, WP Fastest Cache, Hummingbird, Perfmatters, Swift Performance, Breeze, Cloudflare Rocket Loader and any other optimizer not listed in the table above, the Pixel Manager only purges the cache. If one of those tools breaks tracking, add the exclusions below manually.

What breaks tracking, and what doesn't

Not every optimization is a problem. Excluding more than necessary costs performance for no gain.

Safe, no exclusion needed:

• Full page caching of the HTML. The Pixel Manager is built for it: cart contents and product data that can go stale are fetched from the server after the page has loaded, never baked into cached HTML.
• defer on the Pixel Manager script. Deferring only changes the load order, not whether the script runs.
• Serving the Pixel Manager files from a CDN, gzip/Brotli compression, HTTP caching of the static .js files.
• CSS optimization, image optimization, font optimization, lazy loading images.

Breaks tracking, exclude it:

• JS minification of the Pixel Manager files. The files are already minified, and re-minifying them can corrupt the bundle.
• JS combination / concatenation / bundling. The Pixel Manager loads its pixel code as separate webpack chunks on demand. If the entry script is repackaged, or the entry script is excluded while the chunks are not, the browser requests chunk file names that no longer exist and the console shows a ChunkLoadError. Always exclude the whole plugin folder, not a single file.
• Delay JavaScript until user interaction on the cart, checkout and order confirmation pages. Many buyers never click, scroll or move the mouse on the order confirmation page, so a delayed script means the purchase conversion is never sent. Delaying on other page types is usually fine.
• Removing unused JavaScript or any feature that rewrites, inlines or reorders inline script tags. The Pixel Manager's data layer is an inline script.
• Cloudflare Rocket Loader, which reorders and defers inline scripts.

The exclusion list

1. The Pixel Manager script files

The safest and most future proof rule is to exclude the whole plugin folder. Chunk file names contain a content hash that changes with every release, so a rule that names individual files goes stale.

Use the folder that matches how you installed the plugin:

Distribution	Path
Free version from WordPress.org	/wp-content/plugins/woocommerce-google-adwords-conversion-tracking-tag/
Pro version from sweetcode.com	/wp-content/plugins/pixel-manager-pro-for-woocommerce/
Pro version from WooCommerce.com	/wp-content/plugins/woocommerce-pixel-manager/

If your optimizer wants wildcard patterns, these three cover every case:

*woocommerce-google-adwords-conversion-tracking-tag*
*pixel-manager-pro-for-woocommerce*
*woocommerce-pixel-manager*

If a tool insists on concrete file names, the front end assets are:

# Free tier assets
/wp-content/plugins/<plugin-folder>/js/public/free/pmw-public.p1.min.js
/wp-content/plugins/<plugin-folder>/js/public/free/*.chunk.min.js

# Pro tier assets
/wp-content/plugins/<plugin-folder>/js/public/pro/pmw-public__premium_only.p1.min.js
/wp-content/plugins/<plugin-folder>/js/public/pro/pmw-lazy__premium_only.js
/wp-content/plugins/<plugin-folder>/js/public/pro/*.chunk.min.js

Notes:

• A Pro installation contains both the free and the pro folder and serves one of them depending on the license state, so exclude both directories.
• .p1 in the Pro entry script name is the script optimization preset. It becomes .p2 if the preset is changed through the pmw_script_optimization_preset_version filter. A wildcard such as *pmw-public* covers both.
• The WordPress script handle is pmw, for optimizers that exclude by handle rather than by URL.

2. The inline data layer

The Pixel Manager writes its configuration and the product, cart and order data into inline <script> tags. If your optimizer can exclude inline scripts, it usually matches on a unique string inside the snippet. Use:

pmwDataLayer

Older releases used wpmDataLayer. Add both if you want the rule to survive a downgrade:

window.pmwDataLayer
wpmDataLayer

3. Third party tracking libraries on the conversion pages

The Pixel Manager loads the vendor libraries from their official CDNs. On cart, checkout and order confirmation pages these must not be delayed until user interaction, otherwise conversions are lost. The most relevant ones:

googletagmanager.com/gtag/js
google-analytics.com
connect.facebook.net

Add the equivalent for the other pixels you run (for example analytics.tiktok.com, s.pinimg.com, sc-static.net, static.ads-twitter.com, bat.bing.com).

4. Endpoints that must never be cached

These are dynamic, per visitor requests. Standard WordPress caching setups already leave them alone, but if you run an aggressive edge cache, a proxy cache or a custom cache rule, make sure they are excluded:

/wp-json/pmw/v1/*
/?rest_route=/pmw/v1/*
/wp-admin/admin-ajax.php

The AJAX actions the front end uses are pmw_get_cart_items, pmw_get_product_ids, pmw_purchase_pixels_fired, and, in the Pro version, pmw_server_to_server_event, pmw_process_transient_session_identifiers and get_acr_order_data_ajax.

If you use the Google Tag Gateway with a local measurement path, that path (for example /metrics) must be excluded from page caching as well. The Pixel Manager sends no-store headers on it, but an edge cache that ignores origin headers would still break it.

5. Pages that must never be page cached

The cart, checkout and order confirmation pages must be served uncached. WooCommerce declares this itself and every mainstream caching plugin honors it out of the box, so this is only relevant for hand written cache rules or a CDN configured to cache everything.

NitroPack

NitroPack works with the Pixel Manager out of the box and is listed on our Integrations page. The Pixel Manager purges NitroPack's cache when you change settings, but it cannot register exclusions in NitroPack, because NitroPack has no filters for it. So if you do hit a problem, this is the manual procedure.

Excluded Resources (NitroPack Dashboard → Cache Settings → Cache → Excluded Resources)

Add one entry per line, using the folder of your installation:

*woocommerce-google-adwords-conversion-tracking-tag*
*pixel-manager-pro-for-woocommerce*
*woocommerce-pixel-manager*
pmwDataLayer

The first three match the script files, the last one matches the inline data layer. NitroPack accepts a full URL for external resources, a single unique line of code for inline scripts, and * as a wildcard.

Delayed Scripts (NitroPack Dashboard → General Settings → JavaScript settings → Delayed Scripts)

Delayed Scripts is an opt-in list, so the Pixel Manager is only affected if one of your rules happens to match it. Check that no rule matches pmw, pmwDataLayer, gtag, fbevents.js or one of the plugin folder names. If one does, either remove it or narrow it down.

After changing anything, purge the NitroPack cache and test in a private browsing window, otherwise you keep looking at the previously optimized HTML.

Cloudflare Rocket Loader

Rocket Loader (Cloudflare Dashboard → Speed → Optimization → Content Optimization) defers and reorders inline scripts, which can break the data layer. If tracking is broken with Rocket Loader on and works with it off, either leave it off or add a Configuration Rule that disables Rocket Loader for your shop URLs.

The Pixel Manager already adds data-cfasync="false" to its inline scripts when it detects Elementor behind Cloudflare, which is the combination that caused problems in practice.

Any other optimizer

The recipe is the same everywhere. Look for these settings and add the patterns from The exclusion list:

1. Exclude JavaScript files from minification.
2. Exclude JavaScript files from combination, concatenation or bundling.
3. Exclude the Pixel Manager from delay-until-interaction, at least on cart, checkout and order confirmation pages.
4. Exclude the inline pmwDataLayer script from inline JS optimization and from script blocking.
5. Leave defer and page caching enabled. They are fine.

Lazy loading

If your optimizer offers script lazy loading and you also use the Pixel Manager's own Lazy Load feature, the recommendation is to enable both and exclude the Pixel Manager from the optimizer's lazy loading. The Pixel Manager's lazy loader is aware of the checkout funnel and of A/B testing tools, and switches itself off where delayed loading would cost accuracy. See the FAQ for the reasoning.

Verify that it worked

1. Purge every cache layer you run, including the CDN, then open the shop in a private browsing window.
2. Open a product page with ?pmwloggeron appended to the URL and check the browser console. The Console Logger prints every event as it fires.
3. In DevTools → Network, filter for pmw. You should see the entry script and one or more .chunk.min.js files load with status 200. A 404 on a chunk means the bundle is still being repackaged somewhere.
4. Check the console for ChunkLoadError. That error is the fingerprint of JS combination or minification still being active on the Pixel Manager files.
5. Place a test order and confirm the purchase event fires on the order confirmation page. If everything fires except the purchase, the cause is almost always delay-until-interaction on that page.

If it still doesn't work, generate a debug report under Support → Debug report in the Pixel Manager and send it to [email protected] together with the name of your optimization plugin.