Does Store Decode slow down a Shopify store?

Store Decode’s script is built not to slow down your Shopify store. It is a few KB, loads without blocking the page, starts only when the browser is idle, and changes nothing on the page. Automated checks enforce those rules on every change to the script, and you can measure the difference on your own store.

The method in plain words

The script and Shopify’s web pixel run on your visitors’ pages. The rule they are built to is simple: no section may fail to show, and no click, form or page change may fail or get slower, because of Store Decode. When in doubt, the measurement is dropped and the page is left alone. Missing some tracking data is acceptable. Breaking or slowing your store is not.

In practice that means the script waits its turn. It loads after your page’s own code, starts when the browser has nothing else to do, notes what it sees, and sends it in the background. It never writes to your page. If something goes wrong inside it, it stops itself rather than keep trying.

What it means for your store

• Your theme’s own scripts go first. The script tag is async, so it never holds up the page’s own scripts. It is not loaded at all in the theme editor.
• Scrolling stays smooth. Scroll, wheel and touch listeners are passive, so they cannot hold up scrolling.
• Clicks behave as before. The script only notes a click. It never stops a click, a form or a link, and never opens a dialog box.
• Your page stays as you built it. The script does not change your page’s markup, styles or attributes. The one exception is the preview overlay, which runs only on a signed See it on your store link from Home or Observations.
• It stays off where it should. Nothing runs in the theme editor, on password pages, in automated browsers, while you pause collection in Settings, or when the app embed is switched off.

What the script records is listed on Data privacy: what Store Decode collects.

Measure it on your own store

The automated checks under “The exact rules” prove the script behaves. They do not measure speed on your store, so measure it yourself:

1. Run Lighthouse on mobile, in a private window with no extensions.
2. Test your homepage, a collection and a product page.
3. Run each page three times with the app embed off, then three times with it on.
4. Compare the median Total Blocking Time and the performance score.

To switch it off, Pause collection in Settings stops the script on the next page load and keeps your data. Switching the app embed off in the theme editor removes the script tag altogether. Store Decode not working? shows how to switch it back on.

The exact rules

How the script runs

• When it starts. It waits for the page’s markup to be ready, then for an idle moment, with a limit of one and a half seconds.
• Scrolling. The one scroll listener runs at most once a frame. It is attached only while a tall section is on screen, and removed afterwards.
• Clicks. The script never calls preventDefault, stopPropagation, alert, confirm, prompt, document.write or a synchronous request. Its click listener runs before your theme’s handlers, so it does as little as it can there. It reads the target and, for a click on a product link or in an add to cart form, writes its own attribution cookie, which must exist before the page moves on. On a product page it also notes an add-to-cart click: its target, whether the visitor made it, and when. Everything else waits until the click has finished, so the script cannot stop or change what your theme or the browser does with it.
• Limits. It tracks at most 60 sections and 120 product cards per page, and keeps at most 20 add-to-cart clicks per page view.
• The sticky bar check. To see whether a sticky add-to-cart bar comes on screen, it watches at most five candidates. It looks for them when the page starts and once more 3 seconds later, and stops watching once one has shown. Its style reads wait until the browser has finished its own work.
• Sending. A single message is capped at 32 KB. Messages go in the background: when the page is hidden, and at most every 30 seconds while something changed and the tab is visible.

The error fuse

Every entry point of the script runs inside a guard that catches errors, and the errors are counted. After five caught errors the script stops itself, clears its timers and disconnects its observers. It stays stopped for the rest of that visitor’s tab session.

If a page changes so often that the script would have to watch it more than 600 times in a minute, it stops watching that page view. Sections that load late may then be missed, and the page is untouched.

The app embed and the pixel

The app embed adds the script tag and a few facts your store’s pages already make public. Those are bare ids and counts. A product page gets the product id, the selected variant id and the number of variants. A collection page gets its number of products, and a search page its number of results.

A build check fails if the embed prints anything else from your store. That covers prices, inventory, tags, metafields other than the app’s own, the contents of a cart or an order, and the name, email, phone or address of the person buying.

The pixel runs in Shopify’s own sandbox and cannot read or change your pages. It listens to five of Shopify’s standard events: a product added to the cart, a product removed from the cart, checkout started, checkout completed and a search submitted. A build check fails if it listens to clicks, form fields or form submits, or reads the buyer’s name, email, phone or address.

What the build enforces

• A size budget. The script has a size limit, 12,288 bytes gzipped, checked in the build. A change that goes over it does not ship.
• The shipped script is the built one. A check rebuilds the script and the preview overlay and compares them byte for byte with the files that ship. The preview overlay loads only from Shopify’s own content delivery network.
• A scan for forbidden calls. A static check fails the build if the script uses any of the calls above or writes to the page. It also fails on a scroll, wheel or touch listener that is not passive, and on a tag for an analytics service.
• A behaviour test. A test loads a theme page, starts the script, clicks a product link and the add to cart button, submits a cart form, scrolls and hides the tab. It confirms that every event reached the page’s own handlers unprevented. It also confirms that the page’s markup and styles are identical afterwards, and that only Store Decode’s own cookies were added.

See what Store Decode measures on a sample store