Shopify App Audit: What Your Apps Really Cost You

Quick answer: A Shopify app audit scores every installed app on four things: what it costs each month, how much it adds to your page weight, whether your theme or another app already does the job, and what revenue you can honestly tie to it. Divide the fee by your orders to get a cost per order, and measure weight with a before-and-after speed test on a duplicate theme. I found no ideal number of apps in Shopify’s documentation, so judge each app by money and weight, not by count. Cut what scores badly, test-remove what you are unsure about, and protect anything that feeds repeat purchases until you have checked the numbers.

Apps get installed one at a time, to fix one problem, in one busy week. Nobody installs a “remove later” reminder. If you cannot say what your apps cost in total, or what each one earns, this guide is for you.

It is a method for an owner-operated Shopify store doing roughly $150K to $1M a year, where every fixed cost is felt. It gives you a score sheet, a way to measure what each app adds to your pages, a safe order for removing things, and the checks that stop you cutting the app that quietly pays for itself in repeat orders.

The numbers in the worked examples are illustrative. I made them up to show the arithmetic, and they are not from any real store. The facts about Shopify and Google come from their own documentation, which I read on 31 October 2026. Shopify changes its admin and its rules, so treat anything marked “as at 31 October 2026” as something to re-check.

Why count is the wrong number

Search for how many apps a store should have and you will find confident numbers. Most of what I found came from agencies and app vendors that sell audits or apps, so I did not use any of it. I did not find an app-count threshold in any Shopify help page or developer page I read.

What Shopify does say is more useful. Its web performance overview states that each feature you add, including theme code, apps, images, videos and analytics, can affect performance, and that some features “can slow down your site or create unexpected behaviors”. It adds that optimising performance can “increase conversion rates”. Its page on improving store performance says: “Too many apps loading assets on your storefront can slow performance.” The word is assets, not apps. One app that loads a heavy script on every page can cost more than five that load nothing until a shopper clicks.

Shopify measures apps the same way. For apps seeking Built for Shopify status, requirement 2.2.1 says an app “must not reduce the storefront Lighthouse performance score by more than ten points.” That limit is per app and applies only to apps seeking that status. My reading is that it does not cap what several apps do together, so six apps that each stay inside their own limit can still leave a store well below where it started. Either way, the requirement is framed around a change in score, not a count of apps.

So the audit asks four questions about each app.

Step 1: Build the inventory

You cannot score what you have not listed. Make a sheet with one row per app.

Start in Settings > Apps. Shopify says this page manages your installed and recently uninstalled apps. As at 31 October 2026, each app’s about page shows billing and usage charges, privacy details, permissions, extensions and functions, and pixel status. Two things repay attention:

• Unused access. Shopify says permissions an app has not used in the last 30 days appear in an “Unused access” subsection. That does not prove the app is useless, but an app you pay for that has touched nothing in your store for a month is the first row to question. Activity is tracked only for third-party apps.
• Pixel status. An app that installs its own tracking pixel is a candidate for duplicate tracking. If two apps both report purchases, your numbers can be wrong before any optimisation starts, which is one possible reason GA4 and Shopify Analytics disagree.

Check where charges really come from. Shopify says recurring app charges are billed every 30 days and appear on your Shopify bill, and that apps billing outside Shopify are not cancelled when you uninstall them there. Look for app subscriptions on your card statement that never touch the Shopify bill.

Check the places an app can hide. Shopify says some apps add code to your theme. Shopify also says to review your tag manager and remove unused or low-value tags. Add a row for anything left in either place.

For each row record: the job it does, where it is billed, this month’s fee and any usage charges, who last used it, which pages it appears on (all pages, product, cart, checkout, emails), and whether it is an app embed, an app block or pasted code.

Use the amounts on your Shopify bill and each app’s billing card, not the price on the app’s listing, so that usage charges and your own currency are counted.

Step 2: Turn the fee into a cost per order

A monthly fee is easy to ignore because it is small next to stock and ad costs. Dividing by orders makes it comparable.

Cost per order = (monthly fee + usage charges) ÷ orders in the month.

Do the same for the whole stack: total app cost ÷ orders, and ÷ revenue. Keep time cost in mind without inventing a number: does anyone spend regular time maintaining this app?

Here is an illustrative store: 600 orders a month at an average order value of A$85, so A$51,000 a month, with 14 apps. The fees are made up.

That is A$570 a month, A$6,840 a year, A$0.95 per order and about 1.1% of revenue. The fee is the part you can count easily. Slower pages, tracking that disagrees with itself and tools nobody maintains are harder to see, and the next steps are how you find out whether they apply to you.

The money still matters, because fixed costs are the ones you pay in a slow month too. The contribution margin per order post shows what an order has to cover after product, shipping, fees and ads. An app at A$0.95 an order competes with everything else on that list.

Step 3: Measure page weight with a before-and-after test

You cannot see what an app weighs by looking at it. You measure it. Shopify publishes a method for app developers, and you can adapt it.

As at 31 October 2026, Shopify says it measures “the Lighthouse score before and after the app is installed” across three pages, weighted Home 17%, Product details 40% and Collection 43%. Its own test starts from a clean install of a supported theme with no apps, then adds the app. A store owner has a different job, which is to see what each installed app costs, so the version below is my adaptation: the same pages, weights and PageSpeed Insights scoring, but with your own duplicated theme and one app embed switched off at a time.

1. Duplicate your live theme (Online Store, the menu on the theme, then Duplicate). Shopify’s page on duplicating themes does not say whether app embed settings carry across, so open the copy in the theme editor and confirm the same embeds are on.
2. Get the preview addresses for the duplicate: its home page, one product page and one collection page. Shopify’s own method builds the product and collection addresses by pasting the page path into the copied preview link.
3. Run each URL through Google’s PageSpeed Insights and record the mobile performance score. Shopify says to average a few consecutive runs; I run each page three times.
4. Work out the weighted score: (home × 0.17) + (product × 0.40) + (collection × 0.43). If your traffic mix is very different, weight by your own page views instead, and keep the weights the same every time.
5. Turn one app embed off with the toggle in the theme editor, repeat, and subtract. Shopify says app blocks can also be removed and repositioned there. Do all this on the duplicate, never on the live theme.

Two cautions. Shopify tells app developers to average several consecutive runs because scores vary, and Google’s documentation says variability comes from things like local network availability and hardware resource contention. One run proves nothing. And this is lab data: Google describes it as collected in a controlled environment and useful for debugging, while field data is real-world experience from Chrome users over the previous 28 days. The duplicate-theme test tells you what an app weighs, not whether shoppers feel it.

Here is an illustrative result for the store above after switching off the five clear cuts from the scoring table later in this post (the scores below are made up):

That is 6.8 points in the lab. Your own result may be a small change or none, particularly if the apps you remove loaded very little. That is why you measure.

Find the culprit. Chrome’s Lighthouse documentation treats a script hosted on a different domain from the audited page as third-party, and its audit fails when total blocking time is greater than 250 ms. As at 31 October 2026 that audit has moved into a different Lighthouse insight, so the label may differ. Shopify ties slow responsiveness to code: poor Interaction to Next Paint most likely means too much JavaScript from theme, app or tag manager code, so clean up the worst offenders first.

Then check real shoppers. After a change goes live, Shopify’s web performance reports show the effect on real visitors. As at 31 October 2026:

These match the thresholds on web.dev. Shopify’s reports use the past 30 days of real user data, can lag by up to 36 hours, and keep 90 days of history. Its Over Time reports mark changes such as app installs, theme updates and new code with annotation lines, so you can line up “we removed an app” against a graph. Google’s field data uses 28 days, so the two will not match exactly.

Google says it highly recommends good Core Web Vitals for success with Search and that page experience aligns with what its core ranking systems seek to reward. It does not say good scores guarantee better rankings, and neither do I. Here, speed is mainly a shopper-experience and conversion argument.

Step 4: Find the overlaps

Overlap is where the easiest savings sit, because removing a duplicate loses nothing.

App against app. Two review widgets, two pop-up tools, two upsell apps, two tools that each report purchases. Each install made sense on the day. The old one was never removed.

App against theme. Your theme may already include something an app was installed to provide, such as a sticky add-to-cart bar, an announcement bar for a shipping message or product information tabs. Check the theme editor’s settings for each app before assuming you need it. Shopify says its Online Store 2.0 themes and the Horizon family are free and optimised for performance.

App against Shopify. Shopify says images are automatically optimised through its image CDN. If you pay for an image compression app, check what it does that the platform does not.

Score overlap 0 if nothing else does the job, 1 if the theme or another tool covers part of it, and 2 if something already does all of it. If your free-shipping bar scores 2, check the free-shipping threshold itself before you rebuild the message elsewhere, because a bar is only useful if the number behind it is right.

Step 5: Tie revenue to the app, honestly

An app’s own dashboard reports what the app wants credit for. Treat it as a lead, not proof. Use an evidence ladder instead.

Score 0, direct. You can count orders that went through the app in Shopify: subscription orders, orders containing a bundle, orders using the discount code a pop-up issues, orders where an upsell was accepted (if it tags the order or adds a line item property).

Score 1, plausible. The app sits in the buying path and shoppers use it, but you cannot isolate the orders. Reviews, chat, size charts and sticky bars usually land here. Check they are used by reading chat transcripts or watching session recordings.

Score 2, none. You cannot point to orders, and nobody can say what happens if it goes. Countdown timers, activity notifications and decorative widgets often land here. Whether a timer or activity notice is genuine is a separate question from whether it earns money. For an Australian store, read the ACCC’s guidance on false or misleading claims at accc.gov.au and take advice; this is not legal advice.

A score of 0 means orders exist, not that the app is the only way to get them. A bundle app might be replaceable by a theme feature. That is what the overlap score is for.

The holdout test for the unsure ones. When an app scores 1, switch it off on the live store for a defined window (two weeks is my rule of thumb) and compare the same metrics against the weeks before. Record the dates, traffic mix and any promotion. This is a comparison across time, not a controlled test, so a sale or a stock-out can swamp the effect of one small app, and with few orders a month the result is directional at best; the guide to A/B testing on low traffic explains why. If conversion does not move, you still have saved the fee. Do not run it in the fortnight before a sale or while you change the theme, ad creative or pricing.

Protect the apps that build lifetime value

This is where a cost-cutting audit can do damage. An app that does nothing for the first order can be the reason the second and third happen.

Subscription tools, loyalty programmes, review platforms and post-purchase and win-back messaging may have a weak first-order score but a real effect on repeat purchases. Judge them on what their customers do afterwards. Before you cut one:

1. Check the repeat rate. Compare the repeat purchase rate of customers who used the feature with similar customers who did not. The repeat purchase rate guide covers the calculation and the customer lifetime value walkthrough shows how it feeds the number you use for acquisition.
2. Watch for selection bias. Loyal customers join loyalty programmes. If members would have bought again anyway, the programme gets credit it did not earn. Compare customers acquired in the same month with a similar first order, and treat the result as a guide.
3. Think about what disappears. Removing a loyalty app removes customers’ points. Check your programme terms before you remove it, and get professional advice if members hold balances; this is general information, not legal advice. For how the designs compare, read points versus VIP tiers.

Anything that touches checkout, payments, tax, shipping rates, discounts or subscription billing needs a full test order, on a phone, with a real payment method, before and after any change. An app that scores badly on weight but handles shipping rates is a replacement project, not a deletion.

My rule: a revenue score of 0 protects an app from being cut on score alone. You still review its price and weight, and look for a lighter way to do the same job.

Score the stack

Each app gets 0, 1 or 2 on each question, so a total from 0 to 8, where higher is a bigger problem.

The fee cut-offs and weight bands are working rules of mine, not benchmarks from any source. Adjust them, then keep them the same every time you audit.

Read the total: 0 to 2, keep. 3 to 4, investigate (keep, replace or test-remove). 5 or more, cut or test-remove, unless the revenue score is 0 or the app touches checkout, in which case it is a replacement project.

Here is the illustrative store, scored. All scores are made up.

The clear cuts are the old reviews widget, the free-shipping bar, the countdown timer, the image compressor and the sticky bar once the theme setting is confirmed: A$25 + A$15 + A$14 + A$12 + A$19 = A$85 a month, A$1,020 a year, about A$0.14 per order. If the email platform’s forms replace the pop-up tool, the saving rises to A$130 a month, A$1,560 a year, about A$0.22 per order.

That is a useful saving, not a transformation. The more interesting arithmetic is the other side. At 600 orders and a 2.0% conversion rate, the store has about 30,000 sessions a month. If lighter pages lifted conversion to 2.1%, that is 630 orders, 30 more, or A$2,550 a month in revenue at A$85 each. That is revenue, not profit, so run it through your contribution margin per order before comparing it with the fee savings. I am not forecasting that: a speed change may move conversion by nothing, and I cannot promise it will move at all. The point is the comparison. Because a small conversion change can be worth more than a small fee saving, the weight test and revenue evidence deserve at least as much of your time as the fee column. Read what a good Shopify conversion rate looks like before setting a baseline, and look at mobile conversion separately.

Step 6: Remove safely, in order

1. Pick a quiet week, not the fortnight before a sale.
2. Work on the duplicate theme first. Remove the app’s embed or block, preview, and test the pages it appeared on.
3. Export what you need. Shopify warns that some apps store data you cannot recover after uninstalling. Download reviews, loyalty balances, subscriber lists and settings.
4. Test a purchase on a phone before and after.
5. Change the live theme, then uninstall from Settings > Apps.
6. Cancel anything billed outside Shopify. Uninstalling in your admin does not cancel external charges.
7. Check what was left behind. Shopify says uninstalling an app does not automatically remove its code from your theme, and complete removal may need the app developer. On a duplicate, search the code for the app’s name and file names. Remove only what you understand; a half-removed snippet can break a page worse than a leftover one.
8. Check your next bill. Shopify says uninstalling a paid app cancels future recurring charges but you might still be billed for the current billing cycle.

Shopify says you can reinstall most apps after uninstalling them, but previous settings or data might not be restored. Treat uninstalling as a one-way door for anything holding data.

Step 7: Measure the result and keep a log

An audit you do not measure is a tidy-up.

• Log every change with the date, app name and what was done.
• Compare like with like. Take conversion rate, average order value and revenue per session, split by device, for 30 days before and after, and keep the traffic sources in view because a change in ad spend moves conversion by itself.
• Watch field data. Look at LCP, INP and CLS in Shopify’s reports for the same windows and read the annotation lines.
• Check tracking. Place a test order and confirm the purchase fires once. Removing an app that carried a pixel can break your numbers, or fix them.

Then set a rule for new apps: a named owner, a job nothing else does, a way to tell if it works, and a review date. I suggest reviewing the whole stack every quarter. That is my own habit, not a rule from any source.

Key takeaways

• I found no ideal number of apps in Shopify’s documentation. It says apps loading assets can slow performance, so judge each app by weight and money.
• Score each app on fee (as a cost per order), page weight, overlap and tied revenue.
• In the illustrative example, 14 apps cost A$570 a month, about A$0.95 per order. The fee is the easy number to count; weight and revenue need testing.
• Measure weight with an adaptation of Shopify’s app-testing method: a duplicate theme, mobile PageSpeed scores for home, product and collection pages, averaged over several runs.
• Count revenue in Shopify, not in the app’s dashboard. Protect subscription, loyalty and post-purchase apps until you have checked repeat rate.
• Remove in order: duplicate theme, export data, test order, uninstall, cancel external billing, check leftover code, check the next bill.

FAQs

How many apps should a Shopify store have?

There is no official number that I could find in Shopify’s help centre or developer documentation. Shopify says apps loading assets on your storefront can slow performance, so audit by weight and revenue, not by count.

Does removing apps make a Shopify store faster?

It can, and it may not. Shopify says to remove apps that are not essential for sales, but the effect depends on what each app loaded. Average several mobile PageSpeed Insights runs on a duplicate theme with the app embed on and off, then confirm on real visitors in Shopify’s web performance reports.

Does uninstalling an app delete its code from my theme?

Not necessarily. Shopify says uninstalling an app does not automatically remove its code from your theme, and that complete removal may need the app developer. Check a duplicate theme for the app’s name and files.

Do app charges stop when I uninstall?

For apps billed through Shopify, uninstalling cancels future recurring charges, but Shopify says you might still be billed for the current cycle. Apps that bill outside Shopify must be cancelled with the developer. Check the following bill.

Which apps should I be careful about removing?

Anything in the buying path (checkout, payments, tax, shipping rates, discounts, subscription billing) needs a full test order before and after. Apps that feed repeat purchases need a repeat-rate check first, because they can look expensive on first-order numbers.

How do I know what an app really earns?

Count orders in Shopify, not in the app’s dashboard: subscription orders, bundle orders, orders with a pop-up’s discount code, or accepted upsells. If you cannot count them, run a test-remove for a defined window and compare it with the weeks before, knowing it is not a controlled test.

How often should I run an app audit?

I suggest every quarter and before any large sale, with a quick look at “Unused access” and your bill in between. That cadence is my own habit, not a Shopify rule.

Want a second pair of eyes on what your apps do to conversion?

You can run this method yourself with the tools above. We do not sell an app audit as a separate service. If you want help finding where your store loses buyers after the click, a free 30-minute diagnostic is the place to start: book the free 30-minute diagnostic or tell us about your store. We share your Shopify store on screen and name two or three conversion leaks live, and tell you whether they are worth fixing. No pitch. You can also see how our Shopify CRO service works.