When a store is slow, the theme takes the blame. In most audits the theme is not the main cost — the accumulated third-party scripts are. Each was added to solve a real problem and none was ever reviewed afterwards.
The pattern is consistent enough to predict: a store with twenty apps has more third-party JavaScript than first-party, and a meaningful share of it belongs to tools nobody uses any more.
Why third-party scripts cost more than their size
A script's file size is the least of it. What matters is what it does on the main thread and when.
A render-blocking script delays everything after it. A script that runs during page load competes with the work of showing content, which is what Interaction to Next Paint measures. A script that injects elements after load moves content that is already visible, which is what Cumulative Layout Shift measures.
And every third-party script is a request to a server you do not control. If that server is slow today, your store is slow today, and nothing in your theme changes that.
Where the weight actually accumulates
Tracking pixels. Analytics, ad platforms, heatmaps, session recording. Each is small; six of them are not. Session recording tools in particular are heavy by design because they capture everything.
Review widgets that load their entire dataset before rendering. On a product page with many reviews this is often the single largest third-party payload.
Page builders. They add a runtime that has to interpret the page structure at load, which is work the theme would otherwise not do.
Chat widgets. Frequently the heaviest single item, and frequently loaded on every page rather than where support conversations actually happen.
Removed apps that were never fully removed. Apps installed as theme app extensions come out cleanly; apps that wrote directly into theme files leave their scripts behind. The app is gone from billing and still loading in the browser.
What to do about it
Start with an inventory rather than an optimisation. List every third-party request the page makes and match each to something the business actually uses. The list is usually longer than anyone expects and the matching exercise removes several items on its own.
For what remains, ask when it needs to run. A chat widget does not need to load before the page is usable — loading it on interaction, or after the page settles, costs nothing in function. The same is true of review widgets below the fold.
Consider server-side tracking for the pixels you keep. Moving conversion tracking server-side takes that work off the visitor's browser entirely, and it is more reliable now that browsers restrict client-side tracking.
Then measure with real users, not only a lab test. A single test load tells you what to fix; field data tells you whether the fix mattered.
Setting a rule that holds
The reason stores end up here is that installing an app has no visible cost at the moment of installing it. A simple rule prevents the accumulation: nothing gets installed without an owner and a review date, and anything without an owner at review time gets removed.
That is a process fix rather than a technical one, and it is the only version that survives.