Apps can slow loading, delay clicks, or make the page jump. So can themes, large images, tracking tags, and custom code. Your goal is to find a cause you can control without breaking something that helps the store.
1. Start with the symptom, not the app count
Open Shopify’s performance summary from Online Store → Themes, or search the Reports list for Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Record the weak metric, device type, affected page group, and date range.
Shopify’s current report uses real-user data, can connect trend changes with app installs, theme updates, and new code, and may lag by up to 36 hours. That makes it better for direction and change history than for an immediate after-click result.
Official source: Shopify web performance reports ↗
“Product pages on mobile moved from Good to Poor INP after August 4” is testable. “We have too many apps” is not.
2. Fix the test pages and conditions
Choose one representative home page, product page, and collection page. Save the exact URLs. Use the same browser profile, viewport, throttling, cache setting, and test location for every comparison. Run each page several times and compare the median—not the best or worst result.
This page set follows Shopify’s own storefront-app testing model, which measures home, product, and collection pages before and after an app change. Shopify weights product and collection pages more heavily in its app-performance calculation, so do not let a fast homepage hide a weak shopping path.
Official source: Shopify storefront performance testing ↗
3. Record the requests before you diagnose them
- Open the storefront page in Chrome.
- Open DevTools and select Network.
- Enable Disable cache while DevTools is open.
- Reload the page and interact with the feature you are testing.
- Filter for JS, then review Domain, Size, Time, and Initiator.
- Save a sanitized HAR only if you need to share or compare the trace; review it before sending.
Chrome can show what started a request, what it depends on, how long it took, how large it is, and which JavaScript called it. That is much more useful than guessing from a file name.
Official source: Chrome DevTools Network reference ↗
(() => {
const currentHost = location.hostname;
const rows = performance.getEntriesByType("resource")
.map((entry) => {
const url = new URL(entry.name);
return {
host: url.hostname,
type: entry.initiatorType || "other",
transferKB: Math.round((entry.transferSize || 0) / 1024),
durationMS: Math.round(entry.duration),
path: url.pathname.slice(0, 90)
};
})
.filter((row) => row.host !== currentHost)
.sort((a, b) => b.transferKB - a.transferKB);
console.table(rows);
return rows;
})();This reads information already visible in your browser and prints a table on your screen. Nothing is sent to MerchantTrim or anyone else. A web address gives you something to investigate; it does not prove that one app caused the problem.
4. Work out where each request comes from
Make a short table with the host, file path, initiator, page, likely source, and how confident you are. Compare it with current and old apps, theme embeds, theme code, pixels, tag managers, and cookie tools.
A service handled the request
Match vendor, product, path, and initiator
Theme code started the request
Search the duplicate theme and recent edits
A theme extension may control loading
Disable only in a safe test and repeat
The change correlates with the result
Repeat and check the real-user trend
A third-party web address does not always identify an app, and a large download is not automatically the worst problem. If you are unsure where a request comes from, mark it as unsure.
5. Make one change you can reverse
Use a duplicate theme or a quiet testing window. Disable one app embed, integration, or optional feature—not everything at once. Test the same pages in the same conditions. If the app can load only on selected pages, try that before removing it.
For weak INP, Shopify specifically points merchants toward excessive JavaScript from theme code, app code, or third-party/tag-manager code. The correct action is to clean up the verified offender, not assume every installed app participates in the storefront.
Official source: Shopify performance troubleshooting ↗
6. Decide whether the app is still worth it
Speed is one part of the cost. Also include the subscription, setup, upkeep, overlap with other apps, difficulty of leaving, and the sales or staff time the app can prove it creates. A slightly slower app may still be worth keeping. An unused or duplicated app usually is not.
7. Remove without creating a second problem
Before uninstalling, export needed data, list dependent workflows, note app-managed inventory, confirm whether billing occurs outside Shopify, and read the developer’s removal instructions. Shopify warns that some app code can remain in a theme and that app data or settings may not return after reinstalling.
Official source: Shopify app uninstall guidance ↗
Put the speed result beside the bill.
Record the owner, cost, purpose, dependencies, and whether each app stays or goes.
Questions merchants ask
Does every external script come from a Shopify app?
No. Themes, analytics pixels, tag managers, consent tools, Shopify services, and apps can all create external requests. Use the request initiator, installed-app list, theme search, and vendor documentation together.
Can one Lighthouse run prove an app is slow?
No. Lab results vary. Repeat the same page and conditions, compare medians, and use Shopify's real-user Web Vitals report when enough traffic exists. Treat a score change as evidence to investigate, not a verdict by itself.
Should I uninstall the heaviest script immediately?
Usually not. First confirm the owner, business job, dependencies, data export, billing path, and a reversible test. A large resource may be valuable, and a small script can still create costly main-thread work.
Disclosure and limits
This guide contains no affiliate links. It is an editorial diagnostic method, not a substitute for a qualified developer working on production theme code. MerchantTrim does not receive your console output, HAR files, store URL, or test results.