If your Shopify store feels slow and the theme is not obviously to blame, open the product page in Chrome DevTools, go to the Network tab, filter by JS, and sort by size. On most stores we audit, somewhere between six and twelve of the top fifteen JavaScript files come from apps, not from the theme. That is the answer to shopify app scripts slowing site: the theme is usually fine, and the render-blocking weight is a stack of review widgets, pixels, popups, chat bubbles and wishlist scripts that each seemed harmless on the day it was installed.
The fix is boring and it works. Delete what nobody uses, move analytics into Shopify's pixel sandbox, defer the rest until after first paint, and check for orphan code left behind by apps you uninstalled two years ago. Below is the category-by-category version, because "remove unused apps" is advice you have already heard and ignored.
First, measure the blocking, not the app count
App count is a vanity metric. We have seen stores with 24 apps score better than stores with 9, because most of those 24 never touch the storefront. What matters is how much JavaScript executes before the largest element on the page paints, and how much of that JavaScript is parsed on the main thread.
Three checks, in this order:
- Run PageSpeed Insights on a product page and a collection page, then open the Treemap under the JavaScript audits. It groups bytes by file, so app bundles are named and obvious.
- In Lighthouse, read Reduce the impact of third-party code. It gives you main-thread time per origin. An origin holding the main thread for more than 250ms is a problem you can name.
- View source on the storefront and search for
scripttags withoutdeferorasync. Anything blocking in the<head>that is not the theme's critical CSS or Shopify's own scripts is a candidate for deletion.
Do this on a throttled connection with 4x CPU slowdown. Your customer in Coimbatore is on a ₹12,000 Android over 4G. Your MacBook on office fibre tells you nothing.
The three ways app code gets onto your storefront
Understanding the delivery mechanism tells you what you are allowed to touch.
Hardcoded snippets. The app's install flow edited theme.liquid, product.liquid or a section file and dropped a snippet in. This is the worst kind, because uninstalling the app does not remove it. You can delete these yourself from the theme code editor.
ScriptTag API. The app registers a script that Shopify injects into every page automatically. You cannot see it in the theme files and you cannot remove it without uninstalling the app or asking the vendor. Shopify has been steadily pushing developers away from this approach toward app embeds and the pixel sandbox, which is a good thing for page weight.
Theme app extensions. App blocks and app embed blocks that appear in the theme editor with an on/off toggle. You control where they render and whether they render at all, and when you uninstall the app, the code goes with it. This is the model you want your vendors on.
A theme app extension is not automatically fast. Being loaded from Shopify's CDN inside an app embed does not stop a 180 KB review bundle from being 180 KB. What extensions give you is control: a toggle, a scope, and clean removal. That is worth a lot when you are trying to isolate which script costs you a second.
The nine app script categories that block render
1. Review widgets
Usually the single heaviest storefront app on a D2C store. The widget loads a JS bundle, its own CSS, sometimes its own web font, then fetches reviews over the network and injects star ratings into the DOM. On a collection page showing 24 products, that can be 24 rating badges rendered client-side after paint, which is a layout shift generator as well as a weight problem.
Fix: render the star rating from metafields in Liquid so the badge is in the HTML at first paint, and lazy-load the full review list with an IntersectionObserver when the reviews section scrolls into view. Most review apps expose an average rating and count as metafields specifically so you can do this. If yours does not, that is a reason to switch.
2. The pixel and analytics stack
GA4, Meta, Google Ads, TikTok, Pinterest, Clarity, a heatmap tool, and often two GTM containers because someone added one and forgot. We routinely find four separate copies of Meta's pixel firing on the same page, two from apps and two from the theme.
Fix: move everything into Shopify's Customer Events pixels, which run in a sandboxed worker off the main thread. Then delete the theme-level duplicates. This is the highest-leverage single change in the list, because it takes tracking off the critical path without losing a single event. Audit conversions for a week after, in the ad platform not just in Shopify, before you tear out the old tags.
3. Popups and email capture
Klaviyo, Omnisend, Privy and the rest all ship a fairly large SDK, and it typically loads on every page even though the popup fires once per session after 8 seconds. The whole point of the delay is that the popup is not urgent. The script should not be either.
Fix: load the SDK on the first of scroll, mousemove, touchstart or a 3-second requestIdleCallback. You keep the popup and lose it from the critical path. Keep the form endpoint server-side if the app supports it, so subscribers still capture if the script never loads.
4. Live chat and WhatsApp widgets
A chat widget that nobody clicks on a page nobody complains about is pure cost. Facebook's SDK is the usual offender when the widget is a Messenger or WhatsApp bubble.
Fix: build a facade. Render a static button in HTML and CSS, and only load the real widget script when the button is clicked. First click costs the user about a second. Every other visitor pays nothing. For a plain WhatsApp handoff you do not need an app at all: https://wa.me/91XXXXXXXXXX in an anchor tag is one line of HTML and zero JavaScript.
5. Social proof notifications and trust badges
The "someone in Pune just bought this 4 minutes ago" toast. It loads a script, polls an endpoint, and animates a box over your content.
Fix: delete it. We have never seen a clean test where this class of app paid for its own weight, and Indian shoppers in particular read them as fake. Trust badge images belong in the theme as an inline SVG sprite, not as an app.
6. Wishlist apps
Frequently the app that drags jQuery back into a theme that had already removed it. Check the treemap. If jQuery is in your bundle and your theme is Dawn-based, an app put it there.
Fix: if wishlist saves are low, remove it. If it earns its place, insist on a version that uses customer metafields and defers, or have the feature built into the theme against the Customer Account API. A wishlist is a save button and a list page. It does not need 90 KB.
7. Currency and geolocation switchers
Third-party currency apps were necessary in 2018. Now Shopify Markets handles multi-currency natively, and the app version usually blocks render while it does an IP lookup, then rewrites every price on the page.
Fix: Markets plus the native country selector. This one is usually a straight delete, and it removes a nasty flash of wrong prices at the same time. Relevant if you sell into the UAE and India from one store.
8. Upsell, bundles and cart drawer apps
The stacking problem lives here. A cart upsell app, a post-purchase app, a bundle app and a free-gift app, all four listening to cart events, all four re-rendering the drawer. On a store like this the cart drawer opening takes 900ms and merchandising conflicts cause the wrong discount to apply about once a week.
Fix: one app for cart logic, and the offer markup rendered inside the theme's own drawer rather than injected over it. Bundles are often better as Shopify's native bundles or a fixed-price product with a Liquid-built kit selector. If you are already paying for four apps here, custom work on the cart is usually cheaper within a year. Purpose-built app work makes sense when the off-the-shelf combination has become the bottleneck.
9. Search and filter apps
These hurt most because they hurt collection pages, which is where most paid traffic lands. The usual pattern: the app ships render-blocking CSS to style the filter sidebar, then hydrates the product grid client-side, so the grid appears twice and LCP moves to whichever paint wins.
Fix: the filter UI must be server-rendered from Shopify's native filtering, with the app handling the query rather than the paint. Ask any vendor you are evaluating whether their filters render in Liquid or in JavaScript. The answer decides your collection page LCP.
Orphan scripts: the ones you are paying for and not using
Apps uninstalled without cleanup leave snippet includes and script tags behind. The snippet file is gone, so Liquid throws a silent error, or worse, the script tag still resolves and fetches a JS file from a vendor CDN that now 404s after a DNS lookup and a full TLS handshake. We find this on roughly half of the stores we look at that are more than two years old.
Search your theme for {% render ' and {% include ', list every snippet name, and compare against the snippets folder. Then search for every external domain in the theme and check each one against your installed app list. Anything you cannot account for goes, on a duplicated theme first.
What deferring nine scripts is actually worth
Here is the arithmetic we use to decide whether the work is worth booking, using round numbers from a typical mid-size apparel store on a Dawn-based theme.
Say the product page ships 620 KB of compressed JavaScript, of which 400 KB is app code. You delete three apps (social proof, currency switcher, wishlist) worth 150 KB, move pixels into the sandbox for another 90 KB off the main thread, and defer the popup SDK and chat facade for 100 KB more. Net removal from the critical path: 340 KB.
On a throttled 4G profile at roughly 1,600 kbps effective throughput, 340 KB is 2,720 kilobits, so about 1.7 seconds of transfer time you no longer spend before paint. Separately, mid-tier Android devices parse and compile compressed JavaScript at roughly 1ms per KB, so that is another 340ms of main-thread work gone. Those overlap, so you do not get 2 seconds back. In practice a 3.2s LCP lands somewhere near 1.6s, and Total Blocking Time drops from four figures to under 300ms.
Check the numbers yourself against your own treemap. If your app JS is 90 KB total, close this tab and go work on your product photography instead, because speed is not your problem.
Deferring app scripts without breaking checkout
Rules we hold to, learned the hard way:
- Never defer anything that touches the cart, checkout, or a payment method. Razorpay and COD verification flows in particular fail in ways nobody reports, they just do not convert.
- Test the defer on a duplicate theme with the app vendor's script loaded on interaction, then confirm events in the vendor dashboard, not in the browser console. Console silence is not proof.
- Partytown looks like the answer to everything on this list and is fragile in production. We use it sparingly, and never for anything that writes cookies or reads consent state.
- If you strip a duplicate Meta pixel, watch attributed revenue for seven days before you touch the second one. Removing two at once means you cannot tell which one mattered.
- The single highest-return conversation is with the app vendor. Ask when they are shipping a theme app extension version. Some already have one behind a settings toggle nobody enabled.
Do the audit before festive season, not during it
September and October are the wrong months to be pulling scripts out of a live theme. Traffic is climbing, your ad spend is committed, and any drop in attributed conversions gets blamed on the speed work whether or not it caused it. Do this in the quiet weeks, keep the old theme published until you have a week of clean data on the new one, and record before-and-after PageSpeed for both a product and a collection URL so the comparison survives someone's memory.
If you want the ongoing version of this rather than a one-off cleanup, our SwiftStore app scans a store's PageSpeed, fixes the mechanical issues and tracks the score as you add and remove apps, which catches the case where a new install quietly puts 120 KB back onto your product page. The deeper structural work, server-rendered filters, cart logic moved into the theme, review badges out of JavaScript, sits with our speed engineering team.
A 90-minute version you can run today
- PageSpeed Insights on one product and one collection URL. Screenshot the treemap.
- List every app-owned JS file over 30 KB. Name the app next to each one.
- For each app on that list, check the last 30 days: how many customers used the feature? Your apps report and your session recordings will tell you. Wishlist and social proof usually fail this test.
- Duplicate the theme. Delete the failures. Re-run PageSpeed.
- Move pixels into Customer Events. Delete the theme-level duplicates.
- Defer the popup and put a facade on chat.
Steps 1 to 4 need no developer. Steps 5 and 6 need someone comfortable in Liquid and the pixel API, which is either your in-house person or a Shopify developer on a short engagement.
Send us your product page URL through the free audit form and we will tell you which of the nine categories is costing you the most, with the byte counts. That part takes us about twenty minutes and you can act on it whether or not you hire anyone.