Shopify speed: theme, apps or third-party scripts?

Is it the theme, the apps or the third-party scripts?

On a slow Shopify store, the cause usually sits in one of three layers you control. They are the theme, the apps, and third-party scripts such as tags and pixels. A fourth layer, the Shopify platform, is shared by every store and mostly out of your hands. You find the guilty layer by measuring the same page twice: once as it is, and once with the outside scripts blocked.

We did exactly that on four public storefronts on November 11, 2026. Two were Shopify’s Dawn and Horizon theme demo stores, and two were live stores running themes built on Dawn. On the store with the most outside scripts, blocking them cut lab Total Blocking Time from 6,291 ms to 1,129 ms. The theme demos, with no outside scripts at all, still showed a 4-second and a 9-second LCP. So both layers matter, and the measurement tells you which one to fix first.

If you would rather have someone run this diagnosis for you, our website speed optimization service covers Shopify stores. Theme rebuilds sit with our Shopify development team.

What can a store owner control on Shopify, and what not?

Shopify runs the servers, so a big part of speed is out of your hands. Its developer docs describe what the platform does on every store:

• Pages are rendered by Shopify’s storefront renderer and served through a CDN backed by Cloudflare.
• Requests use HTTP/3 and TLS 1.3.
• Early Hints tell the browser about render-blocking files before the HTML arrives, with no theme change needed.
• On most pages, Shopify streams the HTML in two parts. Everything above {{ content_for_header }} reaches the browser first.

Shopify also injects its own scripts through content_for_header. On the Dawn demo store we saw the web pixels manager, a performance kit script and prefetches of checkout files. You cannot remove those from a theme, so they belong in the “platform” column of any diagnosis.

What you do control falls into three groups:

The four layers behind a slow Shopify page

Shopify sets one public bar for themes. A theme in the Theme Store needs an average Lighthouse performance score of at least 60 across the home, product and collection pages. That bar covers the theme with demo content, not your store with your apps.

How did we measure four public storefronts?

This is lab data, not field data. It shows what a simulated mid-range phone on a slow 4G connection sees on one homepage load. It does not show what real shoppers experienced. Here is the method, so you can repeat it:

• Tool: Lighthouse 13.6.0 from the command line, Chrome 157 in headless mode, on a Windows 10 desktop.
• Settings: performance category only, mobile form factor and screen emulation, Lighthouse’s default simulated throttling.
• Runs: 3 runs per page and setting, reporting the median. All runs took place on November 11, 2026, between 02:57 and 03:18 UTC.
• Pages: the homepage of each store, named here only by URL.
• Blocking: for the live stores, we collected every outside domain from the three baseline runs. We added the app files Shopify serves from cdn.shopify.com/extensions/, then ran three more times with all of them passed to --blocked-url-patterns.
• Sorting requests: a small script put each request into one bucket. The buckets were theme files, media, app extensions, third-party domains and Shopify platform files, such as the web pixels manager and checkout prefetches.

npx lighthouse https://www.deathwishcoffee.com/ --preset=perf --form-factor=mobile \
  --screenEmulation.mobile --output=json --output-path=store-a-blocked-1.json \
  --chrome-flags="--headless=new" --quiet \
  --blocked-url-patterns="*://www.googletagmanager.com/*" \
  --blocked-url-patterns="*://static.klaviyo.com/*" \
  --blocked-url-patterns="*cdn.shopify.com/extensions/*"   # ...77 patterns in total

The four stores were theme-dawn-demo.myshopify.com (Dawn 15.0.0), theme-horizon-demo.myshopify.com (Horizon 4.4.0), www.deathwishcoffee.com and www.brooklinen.com. We read the theme names from each page’s Shopify.theme object. We have no relationship with any of these stores, and a homepage test says nothing about how they convert.

What did the two Shopify demo themes show?

The demo stores run a stock theme with no apps and no outside tags. They show what the theme and the platform cost on their own.

Lighthouse 13.6.0, mobile, simulated throttling, November 11, 2026

Three things stand out:

1. Platform files outweigh the theme. On the Dawn demo, Shopify’s own files came to 832 KB, about 10 times the theme’s 77 KB. About 508 KB of that was checkout code prefetched during the homepage load. No theme setting removes it.
2. Horizon’s slow LCP is a bandwidth problem, not a big image. The hero image is an 82 KB PNG. In Lighthouse’s breakdown, 8.1 of the 9.1 seconds was “resource load duration”. On a simulated slow connection, that image shares bandwidth with about 2.9 MB of other downloads, including 583 KB of prefetched product and collection pages. From the Lighthouse trace we could not tell whether the theme or a platform script started those prefetches.
3. Single runs mislead. Dawn’s blocking time ranged from 452 to 1,379 ms across three identical runs. As a control, we ran Horizon three more times with only one Shopify asset host blocked. Its median TBT moved from 370 to 381 ms, while single runs spread from 293 to 596 ms. Treat differences smaller than that spread as noise.

What did third-party scripts cost on a live store?

The first live store, www.deathwishcoffee.com, loaded files from 63 outside domains on its homepage. They included tag managers, ad and analytics pixels, email and SMS tools, reviews, subscriptions, loyalty and fraud tools. Blocking them gave the clearest result in our test:

One caution applies to all six runs on this store. Each carried Lighthouse’s warning that the page loaded too slowly to finish within the time limit. Lighthouse still returned every metric, but scripts that load very late may be undercounted, in both columns.

Blocking time is the number to watch here. Lighthouse cannot measure Interaction to Next Paint on a page load, but long main-thread tasks are what make taps feel slow. Removing the outside scripts took away more than 11 seconds of simulated main-thread work.

The theme was not off the hook, though. With every outside script blocked, LCP was still 5.3 seconds and the score only reached 47. So this store has two jobs: trim the tags, then work on the theme and its images.

What did blocking miss?

About 1,371 KB of third-party traffic survived the block. Every byte of it came from inside iframes, not from the page. The store loaded 14 custom web pixel sandboxes, which are iframes Shopify creates at /web-pixels@.../custom/.... The tags inside them kept loading Google Tag Manager, TikTok, Microsoft Clarity and LinkedIn scripts.

Lighthouse’s URL blocking did not reach requests made inside those sandboxes in our runs. So the “blocked” column understates what the outside scripts cost. If you use custom pixels in Shopify’s Customer events settings, test with those pixels switched off as well. Blocking domains alone will not cover them.

What if Lighthouse cannot finish the test?

The second live store, www.brooklinen.com, went one step further. All six runs carried the same time-limit warning, and here Lighthouse could not compute a score at all. Lighthouse waits for the network to go quiet, and this page never did. The runs logged about 700 requests each. The first one included 169 calls to the store’s own Storefront API, 43 review-widget calls and 6 video files. Without a quiet period, Lighthouse returns no performance score and no Total Blocking Time.

The paint metrics still came through. Median First Contentful Paint went from 4.22 s to 1.92 s with the outside scripts blocked, and LCP from 11.76 s to 8.42 s. Third-party transfer on the page dropped from 1,827 KB to 273 KB. Treat these as rough numbers: each run stopped at a different point, so the byte totals are not comparable.

If this happens on your store, the warning is itself the finding. Look for polling, autoplay video and widgets that keep fetching data after the page has loaded.

How do you diagnose your own Shopify store, step by step?

You do not need our scripts to repeat this. Chrome DevTools, PageSpeed Insights and Shopify’s own tools cover every step.

# Baseline, then the same page with the outside domains blocked (repeat each 3 times)
npx lighthouse https://your-store.example/ --preset=perf --form-factor=mobile \
  --screenEmulation.mobile --output=json --output-path=base-1.json

npx lighthouse https://your-store.example/ --preset=perf --form-factor=mobile \
  --screenEmulation.mobile --output=json --output-path=blocked-1.json \
  --blocked-url-patterns="*://static.klaviyo.com/*" \
  --blocked-url-patterns="*://www.googletagmanager.com/*"

Which fixes belong to which layer?

Once you know the layer, the fix list is short. These are the changes we would test first, in this order:

First fixes by layer, from our measurements and Shopify’s theme performance guidance

Change one thing at a time and re-run the three-run median. Then wait 28 days and check the Chrome UX Report or the Web Performance dashboard, because real visitors are the result that counts. If the fix list keeps growing after a migration, the steps in our website migration checklist help you measure before and after a platform move.

Limits: what this guide does not cover

• Lab data only. We tested one homepage load per run with simulated throttling. We did not pull field data for these stores, and lab numbers do not predict their real Core Web Vitals.
• Homepages only. Product, collection and cart pages load different apps and were not tested.
• Four stores, three runs each. That is enough to show the method and large effects, not to rank themes or stores. Differences smaller than the run-to-run spread are noise.
• No store access. We have no admin access to any of these stores, so we did not disable apps, change pixels or run Theme Inspector on them. The diagnosis steps for your own store come from Shopify’s documentation.
• Blocking is not removal. Blocking a script can break features that depend on it, and it missed scripts inside custom pixel sandboxes. The real cost of an app is only known after you remove it in a test theme.
• Visitor region. Some stores load different tags by region and consent status. Shoppers elsewhere may get a different set of scripts.