Exclude SlimStat From Caching and Minification

Use Client tracking with a full-page cache. The browser can send a tracking request even when the page itself comes from cache; Server mode cannot record a request that never reaches WordPress PHP.

Static tracker JavaScript can be cached normally. Tracking responses must reach WordPress and must not be replaced with cached pages. Exclude JavaScript from an optimization only when testing shows that optimization prevents it from working.

Set Client tracking and refresh cached pages

1. Open SlimStat → Settings → General.
2. Set Tracking Mode → Client, then save.
3. Clear your page cache and CDN page cache so visitors receive the current tracker settings.
4. Visit a page from a private window, following your site’s consent flow.
5. Confirm a new eligible visit in SlimStat → Real-time → Access Log.

Consent and exclusions still apply. A missing row does not, by itself, identify a cache problem.

Check the script actually served

The usual local file is wp-content/plugins/wp-slimstat/wp-slimstat.min.js, but inspect the page’s Network panel before writing an exclusion rule:

• SlimStat 6 removed the Enable CDN setting, so the tracker is always served from your own site. On SlimStat 5 the setting could load it from a versioned jsDelivr URL instead.
• Ad-Blocker Bypass uses a site-specific /{hash}.js path, which a rule containing wp-slimstat.min.js will not match.
• A renamed plugin directory or WordPress installed in a subdirectory can also change the URL.

SlimStat provides the tracker with the inline SlimStatParams configuration. An optimizer must preserve that configuration and its execution order. Delaying the tracker until a click can miss visitors who leave without interacting.

Temporarily turn off the suspected script optimization, clear caches and repeat the same eligible test visit. If that resolves the issue, exclude the actual tracker URL from the affected minify, combine or delay option and retest with other optimizations enabled. Normal browser caching of the JavaScript file can remain enabled. See the JavaScript parameters filter.

Keep tracking endpoints dynamic

Tracking Request Method chooses the preferred browser endpoint:

These are examples; use the URL sent by your installation. Ensure your cache, firewall and proxy allow the relevant POST requests to reach WordPress. Do not cache tracking responses or redirect them to a login, challenge or HTML error page.

The tracker can try another available transport after a network or protocol failure. An explicit tracking rejection, such as a consent or exclusion decision, must not be treated as a reason to bypass that decision. The bypass route is available only when configured.

Verify the result

Inspect the request payload and response, then check the Access Log. HTTP 200 alone does not prove a pageview was stored: a tracking response can contain a rejection code. Compare the same consent state and exclusion settings in each test.

If the script is missing, inspect the generated page and cache contents. If it loads but no request leaves the browser, inspect JavaScript errors and blocking. If the request reaches WordPress but no row appears, use the tracker diagnostic checklist. Compare Client and Server modes before changing modes.