· Matt Proctor · Shopify · 7 min read
The Shopify Apps Killing Your Store's Performance (And How to Find Them)
Every app you install adds JavaScript that loads on every page. The damage is cumulative and invisible — until your Core Web Vitals collapse and conversions follow.
Last year we were looking at a Shopify store’s Largest Contentful Paint score and something didn’t add up. The theme was clean. The images were optimized. The hosting was Shopify’s CDN — same as everyone else. But the LCP was hovering around 4.2 seconds, and a section of the homepage was visibly jumping as the page loaded.
We traced it to a Trustpilot widget.
Not a badly-coded one. Not a broken one. Just a widget doing exactly what it was designed to do — loading a trust badge on every page, every time, whether the user was going to see it or not. The script was creating white space above the fold while it waited for the API call to resolve, then pushing content down when it loaded. Classic cumulative layout shift. And it was happening on every page of the site.
The merchant had installed Trustpilot because a competitor had it and it seemed like a good idea. It probably is a good idea. The implementation just needed work. But that’s the thing about app bloat — no single decision is obviously wrong. It’s the accumulation that kills you.
Why “async” doesn’t mean free
When developers say a script loads asynchronously, they mean it doesn’t block the initial HTML parse. That sounds safe. In practice, it means the script loads in parallel with your page content — still consuming bandwidth, still competing for network priority, still potentially blocking render if it modifies the DOM.
Shopify apps inject their JavaScript through the theme’s <head> or via app blocks in the template. Some are well-behaved: they defer heavy work until after the main content loads, only run on specific pages, and handle their API calls gracefully when the network is slow. Most are not that careful. They were built for the average store, not yours.
Here’s what accumulates when you install a few common apps:
- Review app (Loox, Judge.me, Yotpo): loads review widget scripts on every product page
- Loyalty app (Smile, LoyaltyLion): loads account overlay on every page
- Live chat (Gorgias, Tidio): loads chat widget on every page
- Upsell app (ReConvert, Zipify): loads post-purchase scripts on every page
- Subscription app (Recharge, Bold): loads subscription UI on every product page
- Pop-up app (Privy, Klaviyo): loads intent-detection logic on every page
- Trust badge app: loads badges, often with an external API call
Each one is a few hundred milliseconds. Put six of them together and you’re looking at two to three seconds of rendering overhead on a mid-tier mobile connection — which is how a significant portion of your customers are shopping.
The SKU problem nobody warns you about
App performance issues aren’t always about script weight. Sometimes they’re about data compatibility.
A client came to us after spending weeks trying to get their Trustpilot reviews to display correctly. The integration looked set up right. The widget was on the product page. But reviews weren’t matching to the right products — they were either missing or showing reviews for the wrong items.
The issue was SKU format. Their Shopify products used a specific internal SKU structure. The Trustpilot product catalog used a different identifier. The widget couldn’t reconcile the two without custom logic that Trustpilot’s native integration simply doesn’t include.
“Native integration” is one of the most misleading phrases in the Shopify ecosystem. It means the app has built a connection between their system and Shopify’s API. It does not mean that connection will work seamlessly with your specific data structure. It was built for the average store. If your catalog has unusual SKUs, complex variant logic, or custom metafields, you will probably hit an edge case that requires developer intervention.
We ended up building a lightweight middleware script that mapped their SKU format to what Trustpilot expected. It took a few days of development time that wasn’t in the original budget, because nobody told them to budget for it.
How to audit your own app performance
You don’t need a developer to run the first pass. Here’s a practical process:
Step 1: Baseline your current scores. Run your homepage, a collection page, and your best-selling product page through PageSpeed Insights. Record the LCP, CLS, and FID scores for mobile. These are your before numbers.
Step 2: Go to your theme editor. In Shopify admin, go to Online Store → Themes → Customize. In the left sidebar, look at your app embeds and app blocks. Note every third-party integration that’s active.
Step 3: Disable apps one by one. In your Shopify admin, go to Apps. For each non-critical app, you can temporarily toggle off the app embed without uninstalling the app. Disable one, run PageSpeed on the same pages, compare.
Step 4: Check network requests. Open your store in Chrome, open DevTools (F12), go to the Network tab, filter by “Script.” Reload. You’ll see every JavaScript file that loaded, where it came from, and how long it took. Sort by size. Any script over 100KB from a third-party domain is worth investigating.
Step 5: Look at the waterfall. In the Performance tab of DevTools, record a page load. The waterfall shows you what loaded in what order. Long blocking periods before the first paint are usually caused by render-blocking scripts or large synchronous network requests.
The checklist: what every app should prove before it stays
Before any app stays on your store long-term, it should pass these questions:
- Does it load on every page, or only where needed? A live chat widget on product pages makes sense. On the checkout confirmation page, it’s dead weight.
- Does it load synchronously or defer to after render? Check the script tag in your theme —
deferorasyncattributes are a good sign. No attributes means it’s potentially render-blocking. - What’s the external API dependency? If the app makes a network call to an external service on page load, that service’s latency becomes your latency. Does the app handle API failures gracefully, or does it leave broken elements on the page?
- Does it actually affect your conversion rate? Not “probably” or “should.” Does it? If you can’t measure the lift it provides, you can’t justify the performance cost.
- Has anyone benchmarked it against your LCP? Run PageSpeed before and after enabling the app on a staging theme. If LCP goes up by more than 200ms, you need a specific reason to keep it.
When to optimize vs. when to rebuild clean
If you’re dealing with three or four apps causing performance problems, optimization is usually the right call. Identify the offenders, work with a developer to lazy-load the worst ones, and move on.
If you’re dealing with eight or more apps, a heavily customized older theme, and LCP scores above 4 seconds, you’re probably at the point where incremental optimization is fighting a losing battle. You patch one problem and find another. The underlying structure of the theme isn’t equipped to manage the script load you’ve accumulated.
In that situation, a rebuild is usually cheaper than it looks. A clean theme with proper app management strategy from the start performs better, costs less to maintain, and doesn’t require a developer to dig through years of accumulated customizations every time you want to make a change.
That’s not a sales pitch — it’s the honest version of the same conversation we’ve had with several clients after spending a few days in their codebase. Sometimes the most pragmatic recommendation is to stop patching and start fresh.
If you’re not sure which side of that line you’re on, an ecommerce site audit will tell you quickly. We look at exactly this — theme health, script load, Core Web Vitals, and the specific apps creating the most drag — and give you a prioritized view of what to fix and in what order. You can see an example of this kind of performance work in our PromGirl case study.
Last Updated: March 2026
Matt Proctor
Co-Founder & Head of Technology
Matt Proctor is a co-founder of A Bunch of Creators and has spent over a decade building and scaling ecommerce businesses. As CTO and COO of Occasion Brands, he grew the company from $6M to over $60M in annual revenue, leading agile teams across product development, digital marketing, and technology. He brings that operational experience — the kind that comes from actually running stores, not just building them — to every client engagement. Matt holds a degree in computer science with a minor in English, which explains his insistence on both clean code and clear communication. Learn more about our team.
