Shopify Theme Speed: What Actually Moves the Score

Every Shopify speed guide opens with image compression, and for most stores it is close to irrelevant. Shopify already serves images through its own CDN with sensible defaults. Compressing them further produces a small gain on a problem that was not the constraint.

The weight that actually holds Shopify stores back is code the merchant added — app scripts, tracking pixels, fonts, and theme features nobody uses any more. This is a guide to finding and removing that, in the order that produces the largest gains.

Look at what your store actually requests

Before any advice applies, you need to see what your storefront loads. This takes five minutes and replaces guesswork with a list.

Open a product page in Chrome, open DevTools, go to the Network tab, filter to JS, and sort by transfer size. You now have a ranked list of every script the page loads and what each one costs. Do the same on your homepage and your cart, because they differ.

What you are looking for:

• Third parties you do not recognise. These are almost always apps, and sometimes apps you no longer use.
• Scripts loading on pages where their feature does not appear. A review widget on your blog. A popup app on the cart. This is the single most common finding.
• Duplicate functionality. Two apps both doing analytics, two both doing reviews.
• Anything large enough to be surprising. A single script over a few hundred kilobytes deserves justification.

This list is your work queue. Everything else in this article is about acting on it.

App scripts are the main event

For most Shopify stores, app JavaScript is the largest controllable cost on the page. Each app is individually defensible; collectively they are why Core Web Vitals sit in the amber.

The specific failure is scope. Apps commonly load globally rather than only where they are used, because global loading is simpler for the vendor and invisible to the merchant. Nothing appears broken, so nobody investigates.

Three actions, in order of return:

Remove apps you are not using. Trialled and abandoned apps are the easiest win and almost every store has some. Check the pricing page in your admin against the features actually live on your storefront.

Check what uninstalled apps left behind. This is the one merchants miss. Uninstalling an app does not always remove its code from your theme, particularly for older apps that injected snippets directly rather than using theme app extensions. Stores routinely carry the weight of tools they stopped paying for years ago. Search your theme files for references to apps you no longer have.

Scope the apps you keep. Some apps allow you to limit which templates they load on. Where they do, use it. Where they do not, weigh the feature against a cost you pay on every page.

That last point matters. Removing a script you cannot identify is how a store loses its conversion tracking three days before a campaign.

Fonts block your largest element

Fonts are the most underestimated cost, because they are small in bytes and expensive in timing.

A custom font must download before text rendered in it becomes visible. On most storefronts the largest visible element is text — a headline, a product title — so font loading directly delays largest contentful paint, which is a Core Web Vital.

A theme loading four weights of a heading family plus four of a body family is loading eight files to render a page that visibly uses three of them. The remedies are straightforward:

• Load only the weights you use. Audit which weights actually appear. Most designs use two or three.
• Use font-display: swap so text renders immediately in a fallback and reflows when the font arrives. Visible fallback text beats invisible correct text.
• Choose a fallback that matches metrically, so the swap does not shift the layout and cost you cumulative layout shift.
• Consider system fonts for body copy. Unfashionable, free, and instant.

Images, properly this time

Images are not usually the constraint, but there are two image problems that genuinely cost you, and neither is compression.

Missing dimensions. An image without width and height attributes gives the browser no way to reserve its space, so the page shifts as it loads. This is cumulative layout shift, it is a Core Web Vital, and it is one attribute away from fixed.

Everything loading eagerly. Images below the fold should load lazily. Images above it should not — lazy-loading your hero image delays the very element the score measures.

The distinction matters: the fix is not "lazy-load everything", which is a common and counterproductive over-correction.

Theme features you do not use

Themes ship with features for the widest possible market, and you are paying for all of them.

Mega-menu code on a store with six collections. A currency converter for a store selling in one currency. A quick-view modal nobody opens. Product-page video support on a catalogue with no video. Each is a small amount of JavaScript and CSS, and collectively they are a meaningful fraction of theme weight.

This requires developer time and carries risk, so it belongs after the app audit rather than before it. But on a heavily customised store carrying years of accumulated features, it is often the second-largest win available.

Measure the right thing

Two distinctions that change what you should act on.

Field data over lab data. A lab test runs on a simulated connection from a test location. Field data comes from your actual visitors, on their actual devices and connections. When they disagree, the field data is what your customers experience and the lab score is a diagnostic. Chrome's Core Web Vitals report and Search Console's page experience data are field sources.

Core Web Vitals over composite scores. A single number blends several things and moves for reasons you cannot act on. Largest contentful paint, interaction to next paint and cumulative layout shift each point at a specific cause, which makes them actionable in a way a composite score is not.

What you cannot fix, and should stop trying to

Some of what a Shopify score reports is not yours to change, and effort spent there is wasted.

Shopify's own scripts. The platform loads its own JavaScript for checkout, analytics and various storefront behaviours. You cannot remove it, and audits that flag it are reporting a fact rather than an opportunity.

Server response time. Time to first byte on Shopify is a platform concern. If yours is genuinely poor, the cause is almost always an app making a slow synchronous call during page generation, not Shopify being slow — so the fix is still an app fix.

Third-party pixels the business requires. Marketing platforms need their tags. You can load them more carefully, defer them, or consolidate duplicates, but a business running paid acquisition cannot remove its tracking to win points. The honest move is to make them as cheap as possible and accept the remainder.

Knowing which category a finding falls into is what separates a useful audit from a list of complaints. An audit that tells you to remove Shopify's checkout script is not an audit worth acting on.

Do it in this order

1. Measure, on a product page, with field data where available.
2. Remove apps you are not using, and delete what previous ones left behind.
3. Scope the apps you keep to the templates that need them.
4. Fix fonts — weights, display, fallback metrics.
5. Fix image dimensions and lazy-loading boundaries.
6. Strip unused theme features, with developer help.
7. Re-measure, and check conversion alongside speed.

Steps two and three are usually most of the gain, which is why they come before anything requiring development work.

For the wider storefront picture including theme choice and redesign decisions, see storefront and design. App selection and the weight different categories add is covered in Shopify apps, and the SEO consequences of page speed in SEO and AI search.