Est. reading time: 9 minutes

The owners who came to Shopify from WordPress remember why they left. Plugin sprawl, mystery slowdowns, an update that broke the site on a Friday night. Shopify’s pitch was a managed core nobody could break, and the pitch was honest. The server side of a Shopify store really is out of reach.

The storefront is where the old problem rebuilds itself. Apps accumulate there for the same reason plugins accumulate on WordPress. Each one solves a real problem on the day it’s installed, the install costs a click and a monthly fee, and the cost that matters (another script on every page view) never appears on an invoice. So the list only grows.

That makes the claim in the title close to literal. Shopify apps slow stores through the same channel plugins use (third-party code stacked into every page load). The difference is where the weight lands, and it’s the reason the problem hides better on Shopify.

One feature per vendor, one bundle per feature

A WordPress plugin ships PHP that runs inside every server request, plus the scripts and styles it pushes into the page. A Shopify app gets no server to run on, so everything it does to the storefront arrives as code in the page.

The classic route is a script tag (remote JavaScript that Shopify loads into storefront pages on the app’s behalf). Scope options for script tags cover the whole storefront or the order status page, so a widget used on one template still ships its script to all of them. Shopify now limits script tags to vintage themes, so on a current Online Store 2.0 theme that route is closed. The current route is an app embed, which Shopify injects before the closing head or body tag wherever it’s active. The oldest route is code pasted into the theme itself, and that one earns its own section below.

Every vendor optimizes for a widget that has to work on any theme, sight unseen. That’s why a single reviews app can ship its own framework, its own styling reset, and its own error tracking. Each bundle is defensible alone. Fifteen of them on one storefront hand a mid-range phone fifteen payloads to fetch, parse, and execute, plus a fresh DNS lookup and connection for each vendor’s CDN on a first visit.

The countermeasure starts before the install. Run the trial on a duplicated theme or a development store with the network panel open, and count what appeared (requests, kilobytes, and which templates they load on). Check the integration method while you’re in there. An app embed can be switched off from the theme editor later, and a vendor whose install guide says to paste code into theme.liquid is also telling you what uninstalling will look like.

Shopify apps slow the browser because the server is off limits

A misbehaving WordPress plugin can slow the server’s response, so every visitor waits before the first byte arrives. Shopify removes that failure mode. Page rendering happens on Shopify’s infrastructure, and apps don’t get to execute their own code inside it during a page load.

Checkout is locked down harder still. Since Shopify retired checkout.liquid, customization there runs through sandboxed extensions with limits the platform enforces, so apps can no longer stack arbitrary scripts into the purchase step.

This protection is where the misread starts. Shopify didn’t remove the cost of third-party code. It moved all of it into the browser, onto whatever device the visitor happens to be holding.

The symptom profile inverts accordingly. Server response looks healthy, uptime is perfect, the site feels quick on office wifi, and the same pages fail on a four-year-old phone over cellular, where a meaningful share of paid traffic lands.

The answer on the measurement side is field data. Shopify’s web performance reports track the three Core Web Vitals from real visitor sessions at the 75th percentile, with the summary on the Themes page of the admin and full reports under Reports. The bar for good is a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint under 200 milliseconds, and a Cumulative Layout Shift under 0.1. App payloads push the first two directly, and late-injected widgets are a standing cause of the third.

Speed feeds conversion, so those three numbers belong in the same reporting cadence as ROAS and cost per acquisition.

The apps you uninstalled are still in the theme

Deactivate a WordPress plugin and its code stops running, whatever junk it leaves in the database. Shopify splits the outcome by integration route, and one route ages badly.

Script tags clean up well. They’re scoped to the app that created them, and Shopify removes them automatically when the app is uninstalled. Apps built on theme app extensions never write into your theme’s code at all, and Shopify now requires that model for App Store apps that integrate with themes.

The trouble comes from the generation of apps that installed by editing theme files. The pattern, spelled out in Shopify’s own migration docs, was to drop snippets into the theme’s snippets directory and wire them in by modifying layout, template, or section files. Uninstalling that kind of app removes the app and leaves the theme exactly as it was. The leftover code keeps rendering, and in the worst cases keeps requesting assets from a vendor’s domain on every page view.

Shopify’s developer documentation has a name for this (ghost code) and flags it as a source of quality and performance problems that also blocks clean theme upgrades. A store that has churned through apps for a few years can be hauling code for half a dozen vendors it stopped paying long ago.

The audit is mechanical. Duplicate the live theme so there’s a safe copy, then search across files in the code editor for the names and domains of every app anyone remembers uninstalling. Read theme.liquid for includes and renders nobody can attribute, and skim the snippets directory for files named after vendors. The network panel gives the fastest tell (any request to a domain that maps to no current app is an orphaned script or a pixel nobody owns).

Remove the references, preview, publish. Then fold the same search into every future uninstall, because vendor removal instructions, when they exist at all, assume you’ll do this part yourself.

Isolate each app’s cost before deciding what stays

Aggregate numbers confirm the store is slow without saying which app is responsible. A failing LCP names the condition, and thirty installed apps give you thirty candidates, so owners either keep everything and shop for a faster theme, or purge by instinct and lose a feature that was paying for itself. Whether the theme itself deserves a share of the blame is answerable with the same tools (block every third-party domain at once, and the cost that remains is the theme’s own).

The per-app answer takes an afternoon:

1. Map every script to an owner. Open a product page with the network panel filtered to JavaScript, group the requests by domain, and label each third-party domain with the app or pixel it belongs to. Anything nobody can label joins the ghost code list from the last section.
2. Block and re-measure. Chrome DevTools can block requests by domain. Block one vendor, hard reload, and run the same lab test you ran unblocked, watching LCP and total main-thread blocking time. The delta is that app’s price on that template.
3. Toggle the embeds. For apps that integrate as app embeds, duplicate the theme, switch the embed off in the theme editor, and run the comparison against the preview link.
4. Line cost against revenue. An app with measurable weight and no revenue it can point to is finished. An app that costs real milliseconds and drives real orders becomes a conversation with the vendor about deferred loading and per-template control before it becomes an uninstall.

Lab tests are the right tool for the isolation because they’re repeatable on demand. Field data stays the verdict on whether the cleanup worked, and it aggregates over days of real sessions, so measure in the lab, ship the change, then watch the reports move.

A standing review keeps the sprawl from rebuilding

One cleanup decays because the incentive that built the list is still running. Installing stays a one-click decision made by whoever needs a feature this week, and removal belongs to nobody. Apps installed for a holiday campaign outlive the campaign, and apps installed by an agency outlive the agency.

The repair is a standing review (quarterly is enough) where every app on the list answers three questions:

• What revenue can the app point to (attributed orders, retained subscribers, a measured lift), and who on the team would notice within a week if it disappeared?
• Has Shopify absorbed the job since the install? Its own Search & Discovery app now covers storefront filtering, search tuning, and product recommendations that once required a third party.
• Could a few lines of theme code do the work? For countdown timers, sticky add-to-cart bars, and announcement banners, the honest answer is usually yes, with no vendor bundle attached.

Consolidation belongs in the same meeting. Three single-feature apps from three vendors means three bundles, three CDNs, and three chances at a conflict, and plenty of vendors now cover several of those jobs behind a single integration. Close every review with the same leftover search that closes an uninstall.

The WordPress crowd already ran this experiment, and the fix was never a better plugin. It was fewer. The same discipline ports to Shopify intact. Count the apps, price each one in milliseconds, delete the freeloaders, and search the theme for the ones that left code on the way out. The whole exercise fits inside a working day, and it removes weight that no theme swap would touch.