I have watched the same store get slower without anyone shipping a “performance project.”
A merchant launches on a clean theme. Lighthouse looks fine. Then marketing installs a reviews app. Ops adds a loyalty widget. Someone wants a popup. Another popup. A chat bubble. An upsell drawer. Six months later the homepage feels heavy, mobile LCP is ugly, and the brief becomes “we need a faster theme.”
Often you do not need a new theme. You are paying the Shopify theme tax: every app that injects a script, a stylesheet, or a Liquid snippet into templates you already pay for in load time.
I call it a tax because it is recurring, rarely itemized in the SOW, and it compounds. This is the audit I run before anyone blames Liquid or buys another speed app.
What the theme tax actually is
Shopify themes start relatively lean. The bill arrives when third-party apps and custom sections all assume they own the page.
Typical tax contributors:
- App embed blocks that load on every template, not only the one that needs them
- Legacy script tags in theme.liquid that predate Online Store 2.0 embeds
- Review widgets that hydrate a carousel of images above the fold on collection pages
- Loyalty, wishlist, and “recently viewed” scripts fighting for the main thread
- Chat and marketing popups that race the first paint
- Tracking pixels stacked for ads, analytics, and “just one more” experiment
None of these feel expensive in isolation. Together they fight for bandwidth, CPU, and layout stability. On a mid-range Android phone on a Karachi or Lahore 4G connection, that stack is the difference between a product page that sells and one that bounces.
I do not open with “your theme is bad.” I open with: which scripts run on which templates, and which of them earn their place.
App scripts: the invisible SOW line
When a client asks for an app, the conversation is usually about features and monthly fee. The speed cost is missing.
An app that “just adds a badge” may still:
- Register a global embed
- Pull a remote JavaScript bundle on every page
- Query storefront APIs or inject Liquid that loops products
- Add CSS that forces layout work on first paint
I ask three questions before I approve an install on a store I maintain:
- Does this need to load on every template, or only product / cart / checkout-adjacent?
- Can we use a native Shopify feature, a metafield, or a small custom section instead?
- If we keep the app, can we disable the embed and load it only where the merchant actually uses the UI?
Merchants are often surprised that an app can stay installed for admin workflows while its storefront embed is turned off. That single toggle has recovered more LCP than some “speed optimization” retainers I have seen quoted.
If you want a blunt revenue framing later, I am building a page speed revenue calculator for exactly this conversation — convert, bounce, and ad spend against a slower mobile experience. Until that ships, treat every new embed as a performance change request, not a free checkbox.
Liquid weight is real — but it is not the only story
Liquid gets blamed because developers can see it. Nested loops, heavy section settings, and rendering mega-menus three times are real. I still fix those.
What I push back on is the myth that rewriting every snippet will beat removing three chat-and-popup competitors. Profile first:
- Network waterfall: which third-party hosts dominate transfer size?
- Main-thread time: which scripts parse and execute before interaction?
- Template weight: which Liquid loops run on collection and search when a cached fragment would do?
A theme with slightly “heavier” Liquid and a strict app policy often beats a “lightweight” theme that invites fifteen embeds. Theme marketing pages rarely list the tax you will add after launch.
The speed bill nobody puts in the SOW
On kickoffs I used to estimate theme work as theme + apps + QA. Now I add an explicit line: performance budget and app audit.
That line covers:
- Baseline lab and field metrics before we touch design
- A list of embeds mapped to templates
- A kill / defer / replace recommendation per app
- A budget for image sizes, font files, and above-the-fold sections
- Retest after each install so the tax does not creep back in during UAT
Without that line, the merchant experiences the tax as “the developer made it slow.” With that line, the merchant sees tradeoffs: this reviews app costs $X/month and Y KB of JavaScript on every PDP.
I would rather have that argument in week one than after Black Friday creatives are live.
A practical audit sequence I reuse
When someone sends me a “store feels slow” Loom at midnight Karachi time, I do not start by swapping themes. I run this sequence:
1. Inventory embeds and legacy scripts
Theme settings → App embeds. Then theme.liquid and layout files for leftover script tags. Export the list into a simple table: app, loads on, needed for, owner.
2. Measure one template at a time
Homepage, collection, PDP, cart. Merchants often optimize the homepage while the money pages stay bloated. Field data (CrUX / Search Console) beats one Lighthouse screenshot from a developer’s fiber connection.
3. Cut before you compress
Defer or remove unused embeds. Lazy-load below-fold review carousels. Replace a full wishlist app with a lighter pattern if engagement is low. Compress images after you stop downloading three hero videos automatically.
4. Re-benchmark with the same methodology
Same device class, same throttling profile, same URLs. Otherwise you will celebrate noise.
5. Write the policy into the retainer
New app requests go through the same checklist. Otherwise the tax returns the week after you leave.
When a new theme is the right move
Sometimes the theme really is the problem: abandoned code, inaccessible sections, a frankenstein of three freelancers’ work. Migration can be justified.
I still do the tax audit first. Migrating a messy theme and fifteen embeds into a shiny new theme without governance just relocates the tax. Hydrogen and headless deserve their own go/no-go (I cover that later in this series). For most Online Store 2.0 merchants, discipline beats a rewrite.
What I tell merchants on the call
If you remember one line from this post, make it this: apps are product decisions with a performance receipt.
Ask your developer — or ask me — to show the waterfall with embeds on and off. Price the monthly app fee and the speed cost. Keep a written budget for scripts per template. And if someone promises a magic speed app that fixes everything while leaving every popup intact, treat that promise the way you treat “AI will replace your support team next week.”
I build and maintain Shopify storefronts from Karachi with that discipline baked into the estimate. If your store collected apps faster than it collected conversions, start with the theme tax — not another theme demo.