What 14 Shopify Pixel Audits Showed Us About Page Speed

A researcher pulled mobile PageSpeed scores on 10,205 Shopify stores in March 2026. Stores with zero analytics tools averaged 74 out of 100. Stores running three or more averaged 44. Mobile Total Blocking Time across the whole sample averaged 412ms, more than twice Google's 200ms threshold for "needs improvement." We thought those numbers sounded dramatic until we started running pixel audits on real client stores ourselves. The averages are honest. Most merchants are loading more pixels than they think, and at least one of them is firing more than once.

This is not an image-compression problem. Most of the merchants we work with have already done that round. They have shrunk their hero, deferred a few scripts, removed an app or two. Their Shopify page speed score climbed five points and then stalled. The remaining gap, the one that keeps mobile Total Blocking Time over 400ms, almost always lives in the marketing tag stack.

The first thing we open is the Network tab

Chrome DevTools, Network, filter to "JS", hard reload the homepage. Then we count.

The three filenames we look for first: gtm.js, gtag/js, and connect.facebook.net/en_US/fbevents.js. If any of them shows up more than once on a single page load, the store has a duplicate. On about half the stores we audit, Google Tag Manager appears twice. On roughly a third, GA4 appears two or three times. We have not yet seen Meta Pixel triple-loaded, but we have seen it loaded both natively through Shopify's Meta channel app and again through a GTM container the merchant set up before they installed the channel.

The double-count is rarely intentional. It is almost always residue from a previous setup that the merchant either forgot or never knew about. One audit we did last month turned up a leftover gtag tied to a Google Ads account the merchant had closed in 2024. The script was still loading on every page on every device. Nothing in the admin surfaced it. Nobody had thought to look in the network tab in two years.

The Google Channel app loads three containers, not one

The single biggest surprise we ran into early on came from Shopify's own Google & YouTube channel app. Once it is connected, it does not load one Google Tag Manager container. It loads three: one for GA4, one for Google Ads, and one for Merchant Center remarketing. Each container is the same 100KB-ish library, fetched independently from Google's CDN, parsed independently on the main thread.

A documented case from a Shopify Community thread had the four scripts loaded by that app totaling over 340KB before compression. Four scripts, four blocking parses, four execution windows on the main thread. GTM exists to do the opposite of this. The product was built so a merchant could load one container and run as many tags as they want inside it. The Google Channel app inverts that design choice and there is no setting in the app to fix it. The only fix is to remove the channel and set up GA4, Ads, and Merchant Center inside a single GTM container the merchant controls.

That is a tradeoff most solo merchants do not want to make. Setting up GTM correctly takes a few hours and some confidence in tag sequencing. The Google channel's value is that it works without that effort. We tell merchants honestly: if your Shopify page speed score is already at 70+ on mobile and you are not running paid ads at scale, the channel app is fine. If you are below 50 and the network tab shows three Google scripts, the channel is probably the heaviest single thing you can pull.

The double-load that survives every reinstall

The other recurring pattern is the Customer Events plus theme.liquid double-fire. Shopify's Web Pixels Manager runs GA4 in a sandboxed worker thread, off the main thread, when the Google & YouTube app is connected. That part is good. It is the kind of architecture page-speed advice has been asking for.

The trouble is what was already there before the connection got made. Most of the stores we look at had GTM injected directly into theme.liquid first, sometimes years ago by a contractor who has since left. Then the merchant installed the Google & YouTube app. Now both fire GA4 on every page. The native one runs in the sandbox. The theme.liquid one runs on the main thread. They send duplicate events to the same property. Google's Tag Assistant warns about this with the message "Your Google tag is running in a Shopify custom pixel. This may create duplicate measurement." Almost no merchant we have talked to has seen that warning, because almost no merchant routinely opens Tag Assistant.

The reinstall pattern compounds it further. If the Shopify Google channel gets uninstalled and reinstalled, the original Customer Events configuration sometimes leaves a stale tag in place that the new install does not overwrite. We have seen GA4 properties receiving duplicate events from three independent sources at once: native Customer Events, the merchant's GTM container, and a leftover from a previous app install nobody remembers doing. If you have reinstalled the Google channel even once in your store's history, assume there is residue and look for it.

What we usually pull, and what we leave alone

We do not strip a pixel stack down to nothing. The point of the audit is to keep what is earning its keep and pull what is not. The pattern we follow:

Hotjar comes off first when there is no active optimization project running. The 10K-store analysis shows it as the single worst tool for mobile score, dropping the average by 11.5 points. If the team is not watching session replays this week, Hotjar is sitting on the main thread for nothing. Pulling it is the cleanest single move we make on most audits.

Klaviyo's popup script gets deferred or moved to a scroll-trigger. Klaviyo itself stays. The forms add value; the popup script that loads on first paint on every page does not. Klaviyo's own help docs describe a defer pattern, and the Shopify Discord's #performance channel has working examples. We use one of those.

Microsoft Clarity and Triple Whale we leave alone unless the team admits they do not open the dashboards. Both are tools we like and recommend. Both are also heavy. If a merchant pays for one and looks at it weekly, that is their call. If they pay for it and have not logged in since November, the script is loading anyway and we say so.

The native Meta channel app stays for most stores, because Customer Events runs the pixel in the sandbox. The exception is when the merchant is already running server-side tracking through Stape. In that case the native app is sending duplicate browser-side events to Meta's Conversions API on top of the server-side ones, and we usually pull the native app off. We will say honestly that we have not tested every server-side tool against every channel app. Stape is the one we have worked with most. If you are on a different server-side stack, your match-rate math may differ.

The setting Shopify flipped in January and didn't email about

On January 13, 2026, Shopify changed the default for marketing pixels to "Optimized" mode for every store. The new default throttles data sent to ad platforms when Shopify's own heuristic decides the platform is not "driving results." This was a defaults change, not a notification email. Plenty of merchants did not notice for weeks. One r/shopify thread the day after the change had a merchant talking to Support and being told that "Optimized has been the standard for years," which the changelog directly contradicted.

This matters for Shopify page speed indirectly. Throttled data means Meta and Google's algorithms see fewer signals, which can drag conversion rates down, which puts pressure on merchants to install more pixels to compensate, which lands you back at this article's opener. It also matters more directly because Optimized mode adds its own evaluation layer to every pixel fire. We have not seen a clean controlled test of whether the layer measurably increases TBT, and we are not going to claim it does without one.

There is genuine disagreement in the threads following the change about whether to keep Optimized or switch back to Always On. The case for Optimized is privacy compliance and reduced data sharing with third parties. The case for Always On is consistent ad-platform signal during slow weeks. We have watched a few of our merchants try both and the only honest answer we have right now is: if your Meta event match quality is above 8.5 and you can see it dipping in the two weeks after the switch, flip back to Always On and monitor. If you cannot see a difference, leave Optimized on for the privacy benefit. We do not have a stronger claim than that yet, and anyone who tells you otherwise is guessing.

If your Shopify page speed numbers are stuck below 50 on mobile and you have already done the obvious cleanup, this whole pile is where the next twenty points usually live. We have written about the related app-script problem on mobile if your stack is heavier on apps than on tracking. If you are staring at your network tab right now and not sure what is safe to remove, the first 15 minutes with a help1 expert is free and that is plenty of time to walk one homepage with you.

Tracking accumulates the way clutter does in a room you have stopped looking at. A pixel here for a campaign that ran in 2023, a tag there from a contractor who left in February, a Shopify app you reinstalled once and never thought about again. A store gets slow one well-meaning install at a time, with nobody ever deciding to make it happen.