Skip to main content

Audit and remove third-party scripts

Audit and remove unused apps, tracking pixels, and third-party scripts. This is the highest-impact optimization for improving responsiveness and overall performance.

Anchor to WhyWhy

Performance degrades through "death by a thousand cuts": marketing adds a tracking pixel, a developer adds analytics, a merchant installs an app, the feature becomes unneeded, but the code still executes. This process repeats over months and years, gradually degrading site speed.

Each third-party script adds main-thread work. The browser has a single main thread responsible for layout, painting, and running JavaScript. Every script competes for time on that thread. The cumulative effect hits multiple Core Web Vitals:

  • INP: Scripts that run during customer interactions block the browser from responding. Even scripts that run in the background compete for main-thread time during interactions.
  • FCP: Render-blocking scripts delay the first paint entirely. The browser can't paint until it finishes parsing and executing blocking scripts.
  • LCP: Scripts that delay resource discovery push back the LCP image or text. Tag managers that inject additional resources create dependency chains that delay rendering.
  • TBT: Long tasks from third-party scripts directly increase Total Blocking Time, which correlates with INP in the field.

Anchor to HowHow

Anchor to Step 1: Inventory all scriptsStep 1: Inventory all scripts

Run a Lighthouse Treemap audit to visualize all JavaScript on the page. This shows every script, grouped by origin, with the byte size of each. List all third-party origins and note the size of each.

Open the Coverage tab in Chrome DevTools (More tools > Coverage). Reload the page and check the coverage report. Scripts with high percentages of unused code are candidates for removal. Red bars indicate code that was downloaded but never executed.

Coverage results are specific to the page you record: a script that looks unused on the home page might do real work on a product page. Run Coverage on representative templates, such as the home page, a collection page, and a product page, before you conclude that a script is unused.

Anchor to Step 2: Verify each script is still neededStep 2: Verify each script is still needed

Check with marketing and stakeholders to confirm each script still serves a purpose. Common sources of bloat include:

  • Analytics: Multiple providers tracking the same metrics, or a tag manager loading tags that duplicate built-in Shopify analytics.
  • A/B testing tools: These typically inject blocking JavaScript that delays rendering for every visitor to serve tests that run on a small percentage of pages.
  • Chat widgets: Live chat scripts often load hundreds of kilobytes of JavaScript on every page, even when the chat is rarely used.
  • Review and rating apps: Some inject scripts on every page even though reviews display only on product pages.
  • Email capture dialogs: Often load on every page even when configured to show only on specific pages.
  • Social media embeds: Third-party embed scripts, such as Instagram feeds and Twitter widgets, bring their own frameworks and tracking.
  • Marketing pixels: Retargeting, conversion tracking, and audience pixels from ad platforms.

Identify duplicates. Merchants often have two analytics providers or multiple apps that provide overlapping functionality.

Anchor to Step 3: Verify removal is completeStep 3: Verify removal is complete

Uninstalling an app from the Shopify admin doesn't always remove its code from the theme. Many apps inject <script> tags, stylesheet links, or Liquid snippets into theme files during installation. After removing an app:

  1. Search theme files for the app name or its known script domains. Check layout/theme.liquid for injected script tags.
  2. Check the snippets/ directory for files that the app created. App-generated snippets often have the app name in the filename.
  3. Look for {% render %} or {% include %} tags that reference app snippets. These might exist in section files or the layout.
  4. View the page source in the browser and search for the app's domain to confirm that its scripts no longer load.

Anchor to Step 4: Load remaining scripts conditionallyStep 4: Load remaining scripts conditionally

For scripts that must stay, limit where they run. A review widget needs to load only on product pages. A chat widget might need to load only after a delay or on specific pages.

Use Liquid template checks to control when scripts load:

{%- comment -%}
Load the review widget script only on product pages
{%- endcomment -%}
{% if template.name == 'product' %}
<script src="https://reviews.example.com/widget.js" defer></script>
{% endif %}

For scripts needed site-wide but not immediately, use defer or load them after a customer interaction:

{%- comment -%}
Load the chat widget only after the customer scrolls, on non-checkout pages
{%- endcomment -%}
{% if template.name != 'cart' %}
<script>
window.addEventListener('scroll', function() {
var s = document.createElement('script');
s.src = 'https://chat.example.com/widget.js';
document.head.appendChild(s);
}, { once: true });
</script>
{% endif %}

Anchor to Step 5: Evaluate trade-offs for remaining scriptsStep 5: Evaluate trade-offs for remaining scripts

For each remaining script, evaluate the performance cost against the feature benefit. Questions to ask:

  • Can two apps providing similar features be consolidated into one?
  • Is there a lighter alternative that provides the same functionality?
  • Does the business value of this script justify its performance cost on every page load?

This process requires organizational alignment. See the Build a sustainable performance practice guide.

Anchor to ExamplesExamples

Anchor to Block a third-party domain and measure the impactBlock a third-party domain and measure the impact

Use Network Request Blocking to measure the cost of a specific third-party script before deciding whether to remove it:

  1. Open Chrome DevTools and go to the Network panel.
  2. Reload the page and note the total transfer size and number of requests.
  3. Open the Network request blocking tab. Click the three-dot menu in the Network panel, or open the Command Menu with Ctrl+Shift+P and search for Show Network request blocking.
  4. Add a blocking pattern for the third-party domain, for example, *.analytics-provider.com.
  5. Check Enable network request blocking.
  6. Reload the page and compare.

Then go to the Performance panel:

  1. Record a page load with the domain blocked.
  2. Click the Bottom-Up tab in the summary area.
  3. Group results by URL using the grouping drop-down.
  4. Compare total scripting time with and without the blocked domain.

This gives you a concrete measurement of that domain's cost, which you can use to make a case for removal.

Anchor to Audit the snippets directoryAudit the snippets directory

After uninstalling an app, check for leftover code:

{%- comment -%}
This snippet was injected by an app that has since been uninstalled.
The render tag in theme.liquid still loads it on every page.
Safe to remove both the snippet file and the render tag.
{%- endcomment -%}
{% render 'old-app-tracking' %}

Search the snippets/ directory for files you don't recognize. Cross-reference with your installed apps list. Any snippet from an uninstalled app can be deleted, along with the {% render %} or {% include %} tag that loads it.

Anchor to TestingTesting

  • Lighthouse Treemap for JavaScript inventory and visualization. Run a Lighthouse audit, then click View Treemap to see all scripts grouped by origin with byte sizes.
  • Chrome DevTools Coverage tab to identify unused JavaScript. Look for scripts with high unused-byte percentages.
  • Chrome DevTools Network Request Blocking for measuring the impact of individual domains. Block a domain, reload, and compare transfer sizes and scripting time.
  • Chrome DevTools Performance panel to measure scripting time. Use the Bottom-Up tab grouped by URL to pinpoint specific third-party scripts consuming main-thread time.
  • Run multiple Lighthouse audits and use the median score, because individual runs vary.

Anchor to ReferencesReferences

Was this page helpful?