Do Promotion Apps Slow Your Store? A Check

How to check whether a promotion app slows your Shopify store: what Core Web Vitals measure, where app code loads, and a before-and-after test you can run.

Ask a merchant what worries them before installing a storefront app and speed comes up before price or features. It is a fair worry: anything an app puts on your pages is code the shopper's browser has to download and run. It is also a worry you can test: you can find out whether a promotion app slows your Shopify store without taking anyone's word for it. This page is not a claim that any app, ours included, is fast or slow, and we publish no speed figures. It explains what Google's Core Web Vitals measure and what counts as good, where a Shopify app's code actually loads, what Shopify itself asks of apps that want its Built for Shopify badge, and how to run a before-and-after test on your own store so the answer comes from your pages, not from a vendor's claim. The test works for any promotion app: free gift, progress bar, upsell widget or offer launcher.

The three vitals and their thresholds

Google's web.dev documentation names three Core Web Vitals, each with a threshold for a good experience:

  • Largest Contentful Paint (LCP), loading: the page's main content should appear within 2.5 seconds of when the page first starts loading.
  • Interaction to Next Paint (INP), responsiveness: pages should have an INP of 200 milliseconds or less.
  • Cumulative Layout Shift (CLS), visual stability: pages should keep a CLS of 0.1 or less.

web.dev suggests measuring these at the 75th percentile of page loads, segmented across mobile and desktop, and that a page passes when it meets the target at that percentile for all three metrics. The percentile matters because an average hides the slow loads that real shoppers on weaker phones get.

A promotion app can touch each metric in a different way, which is a useful way to think about it, not a measurement. Code that runs on page load competes with your main content (LCP). Code that runs on a click or a cart change can delay the response (INP). A banner or bar that appears after the page has painted can push content down (CLS), which is why a progress bar needs reserved space.

Where app code loads

Shopify apps reach your storefront through theme app extensions, and the documentation separates two kinds of block.

  • App blocks render inline content inside a theme section. Merchants add them from the Apps section of the theme editor, and by default they are not added after installation.
  • App embed blocks are for floating or overlaid elements, such as chat bubbles, and for analytics or tracking pixels. Shopify says they are deactivated by default and are turned on in Theme settings under App embeds.

Both are visible and controllable. Shopify's Help Center says app embeds can be activated, deactivated and customized through the theme editor, and that app blocks can be added, removed, repositioned and customized there. That is what makes a clean test possible: you can switch an embed off and on without editing code.

Shopify's documentation also gives developers performance guidance. Files in an extension's assets folder are served from Shopify's CDN, and if several blocks reference the same JavaScript or stylesheet file it is included once per page. For app embeds it advises taking advantage of the ability to load scripts only on specific pages. It lists suggested limits of 100 KB compressed for CSS and 10 KB compressed for JavaScript referenced by the schema, and enforced limits of 10 MB for all files and 100 KB of Liquid. These are limits on what an extension may contain, not a promise of any load time, and an app that stays under them can still be slow.

One thing neither Shopify page says: what remains in your theme after an app is uninstalled. The Help Center notes only that if you change your published theme you need to re-activate apps in the new theme. After removing any app, open the theme editor and your page source and look for leftovers.

Shopify's own bar, quoted

Shopify publishes performance requirements for the Built for Shopify program. Requirement 2.2.1 for the storefront reads: "Your app must not reduce the storefront Lighthouse performance score by more than ten points." The admin requirements separate that from the app's own admin screens: at the 75th percentile of page loads, with at least 100 calls over the last 28 days, the app's LCP is 2.5 seconds or less, its CLS is 0.1 or less and its INP is 200 milliseconds or less.

That is Shopify's standard for apps in its program, quoted as Shopify's. We make no claim that we meet it. Its use here is as a yardstick for your test: a ten point Lighthouse drop is the line Shopify draws between acceptable and not for a badge, so a larger drop on your store is worth chasing.

A before-and-after test

Run this on one app at a time. The goal is a difference you can attribute, so change nothing else during the test.

  1. Pick pages. The home page, a collection page, a product page where the app shows something and the cart. The pages where the app is silent will not show an effect, and that is information too.
  2. Pick one device class. Test mobile first, since that is the harder case. Use the same device, network setting and tool for every run.
  3. Measure with the app off. If it is an app embed, deactivate it in the theme editor. If it is an app block, remove it from the section for the test. Run each page several times and write down the median.
  4. Measure with the app on. Same pages, same settings, same number of runs.
  5. Compare field data before concluding. web.dev says lab measurement is essential but is not a substitute for field measurement, because a lab test cannot reproduce the full range of devices, networks and interactions. Lab numbers tell you what the app adds on a controlled run; field data tells you what your shoppers experienced, at the 75th percentile, over a longer window. If you can see field data for your store, compare the weeks before and after installation, keeping promotions and traffic mix as similar as you can.
  6. Decide on the metric that moved. A change in LCP points at load-time code. A change in INP points at code that runs on interaction. A change in CLS points at content that appears late.

Write the result in a table with the page, the metric, the value with the app off, the value with it on and the difference. If a change is within the spread between your own repeat runs, you have not measured an effect.

What to ask an app before installing

Choosing a free gift app covers how to compare apps in general. Add these performance questions to that list, each one grounded in the facts above:

  • Does the app use an app block, an app embed, or both, and on which pages does its script load?
  • Are its files served from Shopify's CDN, and how large are they compressed?
  • Does it reserve space for what it injects, so nothing shifts when it appears?
  • What does it leave in the theme when it is removed?

An answer you can test beats an answer that sounds good. Shopify discounts vs an app covers what you can do without installing anything, and upsell popup vs inline shows how placement changes what a widget costs the page.

Building a progress bar

A progress bar is the offer where layout shift is most likely to matter, since it appears in the cart and updates as items change. Open the Progress bar template, which the app describes as "Show how close the cart is to a reward." Before you turn it on, record the baseline for your cart and product pages. After it is live, repeat the same measurements and read CLS and INP first. Free shipping progress bar covers the copy and thresholds.

Sources

Build this offer from the “Progress bar” template.

Requires: Growth plan or higher.