WordPress 6.8 turned on Speculative Loading by default for every logged-out visitor — which means your Meta Pixel, GA4, TikTok Pixel, and any WooCommerce plugin-based events are now firing on pages the browser prerenders in the background, even when the user never clicks through. Chrome data shows speculative loading already runs on over 11% of page loads globally (Perfmatters, 2026), and the feature shipped to more than 50,000 WordPress sites via the feature plugin before being merged into core (Make WordPress Core, 2025). The fix isn’t turning the feature off. The fix is moving tracking to the server.

Why Your Meta Pixel Is Now Firing Without a Visit#

Speculative Loading uses the browser’s Speculation Rules API to prefetch or prerender pages the user is predicted to visit next. Prefetch downloads the HTML. Prerender goes further — it fully renders the page in an invisible tab, executes all the JavaScript on that page, and fires any tracking pixels or events embedded in it (Perfmatters, 2026).

If that prerendered page contains Meta Pixel’s base code, a GA4 page_view, a TikTok Pixel, a LinkedIn Insight Tag, or a WooCommerce tracking plugin hook, those events fire the moment the browser decides to prerender. The user doesn’t have to click. The prediction is enough.

Your analytics data now includes events for pages nobody actually visited.

The WordPress.org documentation itself acknowledges this in a single line on the Speculative Loading plugin page — prerendering can affect analytics and personalization, and client-side scripts should be delayed until the prerender is activated. That one sentence is the most important caveat in the 6.8 release, and most WordPress performance tutorials skip right past it.

What Kinds of Events Break

• Meta Pixel PageView: Fires on render, regardless of whether the user activates the page.
• GA4 page_view: Sends a hit to Google Analytics with no real user behind it.
• TikTok Pixel, LinkedIn Insight Tag, Bing UET: Same pattern — they fire on script load.
• WooCommerce plugin-based purchase events: Any plugin that fires a pixel on the thank-you page can trigger on a prerender, creating the same class of problem as those phantom purchases in GA4 from thank-you page refreshes.
• Ad-platform algorithms: Meta and Google then optimize against this degraded signal, quietly serving ads to phantom audiences.

How Prerendering Turns a Hover Into a Pageview#

WordPress 6.8 exposes three eagerness levels for speculative loading, and each one makes the ghost-event problem worse (WordPress.org plugin documentation):

• Conservative (default for logged-out users): Prefetch or prerender triggers on click. Lowest eagerness, lowest ghost-event rate.
• Moderate: Triggers on hover or pointer-down. Weston Ruter’s comparison tests showed a 98.2% reduction in Largest Contentful Paint when combining prerender with moderate eagerness (Perfmatters, 2026). It also multiplies the number of prerendered pages dramatically.
• Eager: Triggers as soon as the rule is observed — links that enter the viewport or match predictive patterns. Strongest performance gain, largest tracking inflation.

The Speculation Rules API is supported in Chromium-based browsers (Chrome, Edge, Opera) from version 121 onwards (Kinsta, 2026). Safari and Firefox ignore the rules silently, which means your tracking inflation is browser-specific. Your GA4 data is now distorted in a way that correlates with your visitors’ browser mix — and there’s no UI anywhere that warns you.

Spotting Ghost Events in Your GA4 Today#

You don’t need to guess whether prerendering is inflating your numbers. Here’s a quick diagnostic you can run on any WooCommerce store today:

• Look at page_view without engagement: In GA4, compare page_view counts against user_engagement events on the same pages. Prerendered pages produce pageviews with zero engaged time.
• Look for impossible session durations: Sessions with multiple pageviews but under two seconds of engagement are suspicious. A prerendered page fires the view, but the user was never there to interact.
• Reconcile WooCommerce orders against GA4 purchases: If GA4 is showing materially higher conversion counts than your WooCommerce admin, you’re almost certainly seeing pixel fires from prerendered checkout or thank-you pages.
• Check bounce patterns by browser: If Chromium browsers show a different page_view-to-engagement ratio than Safari or Firefox, prerendering is the likely culprit — remember, Safari and Firefox silently ignore the API.

This isn’t a small leak. Any store running moderate or eager speculative loading is pushing double-digit percentages of inflated events into its ad platforms.

You may be interested in: Does Server-Side GTM Actually Beat Ad Blockers?

Fixing It Without Killing the Performance Win#

The tempting response is to disable Speculative Loading and go back to the old behavior. That’s the wrong trade. The feature exists because it’s a genuine user-experience win — pages load almost instantly, Core Web Vitals improve, and SEO benefits follow. Turning it off to protect tracking means paying a performance tax that hurts conversions more than the tracking cleanliness is worth — the same dynamic that already makes GTM a drag on your WooCommerce store in the first place.

The real problem isn’t the WordPress feature. The real problem is that client-side tracking was always guessing at reality by watching the browser. Ad blockers (roughly 31.5% of global users, Statista 2024) already broke it once. Safari’s 7-day cookie cap broke it again. Speculative Loading is the third strike — and it’s the clearest one, because now the pixel fires even when there is no user.

Server-Side Events Don’t Care About the Browser

A server-side tracking pipeline fires events based on what happened on the server — an order was placed, a form was submitted, a cart was updated. None of those things happen when Chrome prerenders a page in the background, because the prerender never touches your server’s order-creation flow. The event only fires when a real visitor causes a real server-side action.

The question isn’t whether to disable Speculative Loading. The question is whether your tracking should keep pretending the browser is your source of truth.

Transmute Engine™ is a first-party Node.js server that runs on your own subdomain (e.g. data.yourstore.com), fed by the inPIPE WordPress plugin that captures real WooCommerce events. Because it fires on server-confirmed actions — real purchases, real form submissions, real cart updates — speculative loading, ad blockers, and ITP restrictions simply aren’t in the signal path.

Key Takeaways#

• WordPress 6.8 enabled Speculative Loading by default for logged-out users, and it now runs on millions of WordPress sites.
• Prerendering executes the full JavaScript on a page, which fires Meta Pixel, GA4, TikTok Pixel, and WooCommerce plugin events even when users never click through.
• The WordPress.org documentation itself warns about analytics impact — one line most performance tutorials skip entirely.
• Ghost events distort ad-platform signal, and Meta and Google then optimize against inflated data, reducing effective ROAS.
• The durable fix is server-side tracking that fires on real server actions — not disabling a performance feature that benefits every real visitor.

Frequently Asked Questions#

Fix the root cause, not the symptom — start with first-party server-side tracking at seresa.io.