What you will learn
On this pageContentsCloseOpen
"Shopify gets slow if you install too many apps." You have read this everywhere. What you have almost certainly not read is how many is too many, or which of your apps is the problem.
So most stores guess. They uninstall a few apps that felt unnecessary, watch the speed stay exactly where it was, and give up. Others go further and remove apps that were earning money.
The missing piece is that an app's speed impact is measurable, not a matter of opinion. Shopify publishes the exact method it uses to measure it, and your admin contains a report designed to line up "the day you installed something" with "the day the numbers moved."
This article works from the Shopify Help Center and shopify.dev to separate what apps really do to performance from what gets repeated about them, and lays out a diagnosis you can run yourself. Researched on August 31, 2026.
The short version
Four things are worth knowing before you touch anything.
Apps are one performance factor, not the only one. Shopify names three as the biggest contributors to web performance on a Shopify store: your theme, your installed apps, and any third-party code you added yourself, including tag managers and the tags inside them. Before you blame apps, put your theme and your own tags on the same list.
Not every app affects your storefront. The ones that matter here load code on the pages customers see. Apps that live entirely in the admin, or that only run background jobs, are a different conversation.
A Built for Shopify badge is not a promise of zero impact. As you will see, the standard is "within a limit," and the limit is larger than most merchants assume.
You can start the diagnosis in the admin, for free. There are three stages, and the first two cost nothing but attention.
How Shopify measures an app's speed impact
It helps to borrow Shopify's own yardstick, because everything downstream depends on it.
The developer documentation on shopify.dev states plainly how Shopify evaluates an app's effect on storefronts: it measures the Lighthouse performance score before the app is installed and after, and takes the difference.
The scores from three page types are combined, but not equally:
| Page | Weight |
|---|---|
| Home | 17% |
| Product details | 40% |
| Collection | 43% |
The home page carries the least weight, which is the part worth remembering. Your storefront's front door is the home page, but the pages that decide revenue are product and collection pages, and Shopify's measurement is weighted accordingly. When you test your own store, a fast home page tells you very little.
The documentation is written for app developers, but nothing in the procedure requires developer access. You can run the same test, and later in this article you will.
What "Built for Shopify" guarantees about speed
The Built for Shopify badge is the usual shorthand for a quality app, and the App Store lets you filter search results to show only apps that have it.
On performance specifically, the published criteria on shopify.dev say this about storefronts:
Your app must not reduce the storefront Lighthouse performance score by more than ten points.
Read that as the ceiling it is: a drop of up to ten points passes. A badged app can still cost you several points, and installing several badged apps stacks those costs.
There is a second caveat. Shopify describes storefront and checkout performance as something it measures "for a subset of apps." An app that never touches the storefront is not assessed on this criterion at all, so you cannot compare two apps' speed impact by looking at their badges.
The criteria also cover performance inside the Shopify admin — at the 75th percentile, LCP within 2.5 seconds, CLS at or below 0.1, INP at or below 200 milliseconds — plus conditions on checkout speed. Admin responsiveness and storefront speed are graded separately, which is worth knowing when an app "feels fast" while you are configuring it.
Stage one: the web performance reports
Now to your store.
Shopify's admin once had something called the online store speed report. As of this research, that help page URL redirects to the web performance reports, and both the content and the nature of the measurement have changed. Plenty of guides still describe the old version, so read them against what your admin actually shows.
What the current reports do:
They use real visitors, not a test environment. The data comes from real user monitoring (RUM) and is scored against the three Core Web Vitals: loading speed (LCP), responsiveness (INP), and visual stability (CLS).
Rankings reflect the top 75% of experiences, and fall into Good, Needs improvement, or Poor:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | 2500 ms or less | 2500–4000 ms | Over 4000 ms |
| INP (responsiveness) | 200 ms or less | 200–500 ms | Over 500 ms |
| CLS (visual stability) | 0.1 or less | 0.1–0.25 | 0.25 or more |
And here is the feature this entire article is built around. The line chart in the over-time reports overlays changes you made to the store — app installations, theme updates, new code — as numbered vertical lines called event annotations. Hover over one and you see what changed.
In other words, "LCP got worse right after I installed this app" is something you can see directly on a graph. As a starting point for finding the culprit, nothing else is close in effort-to-answer ratio.
To get there, go to Analytics > Reports in your admin and open the report you want, or use the performance metric summary on the Online Store themes page to jump into the over-time reports. Viewing them requires the Reports staff permission.
A few limits shape how you use this:
- Data can lag by up to 36 hours
- Only the last 90 days are retained
- Stores in private mode (password protected) will not accumulate real user data
- Low-traffic stores swing a lot day to day; switch to a weekly or monthly filter
The 90-day window matters more than it sounds. You cannot go back and investigate an app you installed six months ago. Checking the report shortly after each new install is, in practice, the fastest diagnostic habit you can build.
Stage two: isolating a single app
Once the report points at a suspicious week, test app by app. The procedure below is Shopify's own developer testing method, used as-is.
1. Work on a duplicate theme. Never test on the published theme. Note that app embeds are not active by default when you switch to a different theme, so check that your baseline is genuinely comparable.
2. Collect three URLs. You need a home, product detail, and collection page. On the themes page, right-click View your store and copy the link address — that URL can be analyzed by external tools even while the store is password protected.
3. Turn the app off and measure. In the theme editor, use the App embeds panel to toggle the app off. For apps placed as blocks, remove the block instead. Then run each of the three URLs through PageSpeed Insights and record the mobile performance score.
4. Turn it back on and measure the same three pages.
5. Take the weighted difference. Combine the scores at 17% home, 40% product, 43% collection, then subtract the "before" figure from the "after" figure. That number is the app's impact in points.
Lighthouse scores move between runs, and Shopify explicitly recommends averaging across several consecutive tests. A three-point difference from a single run is noise, not evidence.
Running this against every installed app is not realistic, so use the event annotations to shortlist two or three candidates and test only those.
Uninstalling does not always remove the code
Suppose the test convicts an app and you decide to remove it. There is a trap here.
The Shopify Help Center states it directly in its performance troubleshooting guidance: uninstalling an app does not automatically remove its code from your theme, and full removal may require instructions from the app developer.
What separates the two outcomes is a mechanism called a theme app extension. The Built for Shopify "clean uninstall" requirement is that apps meant for the online store must build their theme-facing elements as theme app extensions. Apps built that way never inject code into theme files, and when the merchant uninstalls, the associated blocks are removed from online store themes automatically and completely.
The inverse is the problem case: an app that writes directly into your theme code can leave traces behind after removal. That is the usual explanation for "I deleted the app and nothing got faster." How to find and clear those leftovers is covered in Auditing Your Shopify Apps: What Uninstalling Doesn't Remove.
Ignore most of what third-party scanners tell you
Run a speed grader against a Shopify store and you get a long list of recommendations. The Shopify Help Center is blunt about this: many recommendations from third-party scanning tools are already implemented by Shopify or simply do not apply to Shopify stores.
Shopify provides all of the following as standard:
- A CDN (run by Cloudflare, no extra charge, assets served over HTTP/2)
- Browser caching set to one year for cacheable resources, the maximum possible
- Gzip compression on CSS, JavaScript, documents, and pages
- Image optimization, with automatic JPG compression and WebP delivery in many cases
- Automatic minification of CSS and JavaScript on request
So "add a CDN," "enable compression," and "review your server configuration" are not actionable on Shopify. What is actionable: the size and number of images you upload, the number of sections in your templates, and your apps and third-party code.
Before you remove anything
Work through this list first:
- Does a metric in the web performance reports actually sit at Needs improvement or Poor?
- Does the date the metric degraded line up with an app install in the event annotations?
- Does the app load code on the storefront, or does it stay in the admin?
- Are you testing on a duplicate theme rather than the published one?
- Are you averaging multiple measurements instead of trusting one run?
- Are you measuring product and collection pages, not just the home page?
- Is the revenue or saved labour from this app worth the points it costs?
- Does it use a theme app extension, or will code remain after uninstall?
- Do two apps in your list do the same job?
The last two get missed most often. Overlapping apps — two review widgets, two popup tools — load broadly similar work on the same pages, and neither one shows up as obviously wasteful on its own.
Summary
The order of operations:
- Read the current state in the web performance reports. Identify which of LCP, INP, and CLS is below Good. If all three are Good, cutting apps is a low-priority project.
- Match the degradation to a change using the event annotations. This is what narrows the field to two or three candidates.
- Test those candidates individually on a duplicate theme with PageSpeed Insights, weighting home 17%, product 40%, and collection 43%.
- If you remove one, verify that no code was left behind. Uninstalling severs a connection; it does not erase a footprint.
"Too many apps" is not a diagnosis. "This app, on collection pages, costs eight points" is — and once you can say that, the keep-or-cut decision makes itself.
If you want to work further upstream and decide whether you need an app in the first place, What Shopify's Native Blog Can Actually Do (And When You Need an App) covers where the built-in feature set ends. Knowing that boundary before you install is the most reliable speed optimization there is.
Primary sources
If your order confirmations arrive from [email protected] instead of your own domain, that's not a bug — Shopify rewrote it. The usual advice is 'add the CNAME records.' That's incomplete. Shopify's automatic authentication explicitly does not create a DMARC record, two DMARC records fail validation outright, adkim=s breaks alignment, deleting the CNAMEs silently resets you, and email forwarding requires the SPF TXT record Shopify otherwise tells you not to add. All five failure modes, verified against Shopify's own documentation. Researched September 1, 2026.