We replaced 7 apps with 200 lines of Liquid

A storefront never gets slow all at once. It gets slow one Tuesday at a time.

One Tuesday at a time

Nobody decides to run twenty apps. You need email capture, so you install something. Reviews, another install. A chat widget before the holiday rush, and eventually a compliance banner because legal asked.

Open the admin a year later and count. 15-20 apps, which is what the typical Shopify store runs, and somewhere between 5 and 10 of them are injecting JavaScript straight into your storefront. None of them know the others exist. Each one ships its own script tag, fetches its own code from its own server, and assumes it's the only guest at the party.

We call the cleanup work app archaeology. Every layer you dig through was somebody's Tuesday.

It's never the theme

The slow-store hunt usually goes like this, and we've run it wrong ourselves. The store feels sluggish, so you blame the theme. Then the images, so you compress everything. Then Shopify itself, briefly. (We have held every one of these theories with complete confidence.)

Then you profile the page, and the waterfall is not subtle. When people measure where Shopify storefront slowdowns actually come from, app scripts account for 60-80% of them.

It was never the theme. It was the guests.

Load everywhere, forever

The mechanism is dumber than you'd guess. Older apps register through Shopify's ScriptTag API, and that API does exactly one thing: it injects a script tag into every page of your storefront. Every page. There is no scoping. You cannot keep it off the homepage or restrict it to the product pages where the widget actually lives. The browser hits the tag, stops what it's doing, downloads a file from someone else's server, and executes it. Then it does the same for the next app.

Shopify knows. ScriptTag is deprecated for new apps, and the modern replacement, theme app extensions, loads assets only on the pages where a merchant actually places them. But thousands of older apps still run on ScriptTag, and no dashboard flags which of your fifteen do. You have to go looking.

The weight is real. A store with five "lightweight" apps covering analytics, reviews, chat, inventory and compliance can be loading 300-500KB of render-blocking JavaScript on every page view.

"Lightweight" is a marketing word. Waterfalls don't read marketing.

The bill reaches revenue

Render-blocking means the browser cannot paint your page until the script has downloaded and executed. Google's own web.dev documentation calls synchronous scripts in the head of a page almost never necessary and almost always bad for performance. Apps ship them anyway, by default.

Largest Contentful Paint is the moment your main content actually appears, and Google wants it inside 2.5 seconds. Every script in the stack pushes that moment later.

When Vodafone in Italy cut its render-blocking resources, LCP improved 31% and sales rose 8%. That arrow points both ways.

The old Akamai/Gomez benchmark, still quoted across the performance literature, prices one second of delay at a 7% drop in conversion. If your app stack adds 1.5 seconds to the page, you are funding it out of your conversion rate.

The cruel part: there is no villain to fire. Past 15-20 scripts, degradation is essentially guaranteed, but the blame spreads so thin across network contention and CPU time that no single install looks guilty. Every script has a support team insisting it's lightweight. They are all technically right, and the page is still slow.

The better question

At some point we stopped asking which app was slow and started asking what each app actually does all day. That turned out to be the better question, because the honest answer for most of them is: nothing that needs a browser.

A countdown timer or a product badge is a short Liquid snippet. Liquid runs on Shopify's servers and ships plain HTML, so the JavaScript cost of those features is zero. Analytics does not need five separate apps firing scripts at your visitors either. Send the events from your backend, or consolidate them into one Tag Manager container. The data still flows. The page stops paying five times.

Some things genuinely need an app, inventory sync being the obvious one. Fine. Pick the ones built on theme app extensions, which load only where they're placed, over the ScriptTag-era ones that load everywhere forever.

Seven apps, two hundred lines

We've run this end to end: 7 apps replaced with roughly 200 lines of custom Liquid plus server-side GTM. The apps did real work. The work just never needed to happen in the browser.

And the headroom is bigger than most operators expect. Research on third-party script optimization puts the removable share of that JavaScript at 40-70% within a normal optimization window. Read it from the other direction: that is how much avoidable bloat most stores are carrying right now, and they are paying conversion on all of it.

What we ask now

Before any install: does this need to run in the browser at all? For anything already installed: does it load on every page or only where it's used, and is it render-blocking or deferred? And when no single app looks guilty, stop interrogating apps and measure the stack as a whole, because past a certain count nothing has to look guilty.

You'd be surprised how rarely anyone has asked.

Apps are convenient and they solve real problems. Neither fact deletes the tax. The stack was built one install at a time, and it comes apart the same way.

One Tuesday at a time.

If you'd rather measure the tax than guess at it, our Infrastructure Stress-Test inventories every render-blocking script on your storefront and hands back a remediation roadmap in priority order.

Sources

1. The ScriptTag resource (legacy) - shopify.dev - Official ScriptTag API documentation explaining the onload event and global loading behavior.

2. Optimize Largest Contentful Paint - web.dev - Google's official guidance on LCP optimization, thresholds (2.5s target), and the performance impact of render-blocking resources and synchronous scripts.

3. Load Third-Party JavaScript - web.dev - Web.dev article on the performance costs of third-party scripts, including network congestion and main-thread blocking.

4. Configure theme app extensions - shopify.dev - Official documentation comparing theme app extensions to ScriptTag, detailing page-scoped loading and performance benefits.

5. Third-Party Scripts Slowing Shopify? Fix the #1 Speed Killer (2026) - ThunderPageSpeed - Analysis of app-script impact on Shopify storefronts, including the 60-80% attribution to slowdowns and per-store app counts.

6. Vodafone: A 31% improvement in LCP increased sales by 8% - web.dev - Case study detailing server-side rendering optimizations, LCP improvements, and measured business impact on sales conversion.

7. How To Reduce The Impact Of Third-Party Code: A Guide - DebugBear - Strategies for identifying and reducing third-party code impact, including async loading, lazy loading, and vendor management.