This post is about Shopify: its apps, its theme files and the speed report in its admin. It takes one part of our online store launch checklist, speed, and applies it to a store that is already live and feels slow.
The short answer
An app that shows something on your storefront, or tracks what shoppers do there, adds code to the page. Four patterns are worth checking first:
- scripts in the page’s head that the browser must finish before it can show anything;
- scripts for an app that shows on one page but that load on all of them;
- chat, video and social feeds loading at the same time as the first image;
- code left in the theme by apps you no longer use.
The fix is not to delete apps at random.
First, check that the store is really slow
Before you touch an app, find out whether your shoppers see a slow store, or only a test tool does.
A lab score and what real visitors get
A score from PageSpeed Insights or Lighthouse is a lab test: one simulated visit, on one simulated phone, at one moment. It is good for finding causes. It is not what your shoppers get. Google’s own guidance says lab measurement “is not a substitute for field measurement”, and a lab tool cannot measure how fast the page answers a tap at all, because nobody taps (web.dev).
What real visitors get is in your Shopify admin, in the Reports list. The reports use real user data, for mobile and desktop: the summary on the Themes page covers the past 30 days, the reports themselves let you choose the time range, and the data can be up to 36 hours late (Shopify Help Center). They break the numbers down by page type and by page address, and the chart marks changes such as app installs and theme updates, so you can see whether a drop lines up with a new app. A new store may have no data yet, and a store with little traffic sees bigger swings.
The three numbers Google looks at
Google’s Core Web Vitals are three measurements of real visits. Each has a line for “good”, judged at the 75th percentile of page loads, on mobile and desktop separately (web.dev). In plain terms, three page loads in four have to meet it.
| Measure | What it tracks | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest image or text block on the first screen has rendered | Within 2.5 seconds |
| Interaction to Next Paint (INP) | How long the page takes to respond after a tap or click | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the page jumps while it loads | 0.1 or less |
App scripts can hurt all three. Shopify’s theme guide says JavaScript, “whether your own theme code or scripts from installed apps”, runs on the same thread the browser uses to draw the page and respond to input, and it names app-injected content as one of the common causes of layout shift (Shopify developer docs).
Why a theme scores well in a demo and badly after launch
A theme’s demo store has none of your apps, none of your tracking and none of your catalogue. Shopify tests themes for its Theme Store on a benchmark store (Shopify developer docs), and its guide for app developers measures each app from a clean theme with no other apps installed (Shopify developer docs). Each app can pass that test alone. Your store runs all of them at once, on your real catalogue, and Shopify’s theme guide warns that a theme that is fast on 10 products can be slow on 100.
That is why our checklist measures speed on the finished store, with the apps on and the cookie banner showing (Speed and visual stability). Its Speed and access pack goes further and measures layout shift in a fresh session where the consent banner has not been dismissed. A team that tests in a browser that dismissed the banner weeks ago never sees the jump every first-time visitor sees.
How app scripts slow a store down
Shopify lists three ways an app can reach your theme (Shopify Help Center):
- an app block, which you place in a section of a page;
- an app embed, which you switch on in the theme editor, and which can float over the page or add code that shoppers never see;
- code the app injects straight into your theme files.
You can see the first two in the theme editor and switch them off there. The third you can only find in the code.
Scripts that hold up the page
A plain script tag in the page’s head, with no async or defer, makes the browser stop, download the script and run it before it carries on. The page stays blank until each one has downloaded and run. Shopify’s guide names render-blocking stylesheets and scripts in the head as the usual reason the first paint is late, and tells theme developers to remove or defer app scripts that block the page (Shopify developer docs).
The difference is one word in the tag. The first line holds up the page; the second lets it appear first:
<script src="https://app.example.com/widget.js"></script>
<script src="https://app.example.com/widget.js" defer></script>
Shopify recommends defer for scripts the page does not need straight away, and async only for independent third-party scripts whose order does not matter. Do not add either blindly. A script that other code expects to have run first can break when it is deferred. Shopify advises duplicating the theme before you edit its code (Shopify Help Center); make the change in the copy and test the app there before you publish it.
Scripts on every page for an app that shows on one
The example in our checklist is a reviews or upsell app that loads its whole bundle on the home page and the cart, where it shows nothing, and Shopify’s own guide to auditing scripts makes the same point about review apps (Shopify developer docs). Two things make this happen.
Code an app writes into theme.liquid lands on every page that uses it, because layouts are the base of the theme “through which all templates are rendered” (Shopify developer docs). And Shopify injects an app embed, once you switch it on, before the closing head and body tags of the page. Its developer can limit it to certain templates (Shopify developer docs); if they have not, and its code does not check the page itself, it loads on every page.
Chat, video and feeds competing with the first image
A live chat widget, an embedded video, a social media feed or a store locator map is heavy, and none of it is what the shopper came to see first. Loaded with the page, it competes with the first image for the phone’s bandwidth. Our checklist keeps these out of the network log until the visitor clicks a placeholder, such as a still of the video or a chat button that loads the real widget (Speed and visual stability). Shopify agrees on chat: deferring a chat widget until the shopper interacts “is a real improvement” (Shopify developer docs).
The first image needs the opposite: Shopify’s guide says never to lazy-load it, and to mark it with fetchpriority="high" (Shopify developer docs).
Code left behind by apps you uninstalled
Uninstalling an app turns off its features. Its code is another matter. Shopify’s Help Center says some apps add code to your theme that is not removed automatically when you uninstall them, and asks you to check the app’s listing or contact its developer for extra steps before you do (Shopify Help Center).
Apps built on Shopify’s theme app extensions do not edit theme code (Shopify developer docs). The leftovers are code written into the theme files, by the app during installation (Shopify developer docs) or by hand from its setup instructions (Shopify Help Center): a script tag that still loads from the old app’s server, a snippet that still renders, a pixel that still fires. Each one is work for the shopper’s phone that does nothing for you.
A short audit you can do yourself
You need the Shopify admin and Chrome.
- List every app and app embed, and the pages each one is needed on. Installed apps are in Settings > Apps. App embeds are in the theme editor, under the App embeds icon in the sidebar (Shopify Help Center). Next to each, write the page types it is needed on: every page, product pages, the cart, or none.
- Search the theme code for uninstalled apps’ names. The Uninstalled tab in Settings > Apps lists the apps that were removed (Shopify Help Center). In Online Store, open Edit code on a duplicate of your theme and use the search button in the left sidebar, which searches all theme files at once (Shopify Help Center). Search for each name, and look hardest in
theme.liquid, the other layout files and the snippets. - Check the network log for requests to removed apps’ domains. Open your home page, a collection, a product and the cart in Chrome, open DevTools, go to the Network panel and reload. Type
domain:in the filter box and DevTools suggests every domain it has seen on the page (Chrome for Developers). A domain that belongs to an app you no longer have is a leftover. - Run the free checkup for scripts, outside hosts, blocking scripts and image attributes. The store checkup reads one page’s HTML. It counts the script files and the outside hosts they come from, names the scripts in the head with no
asyncordefer, and finds images without a width and height, and images after the first 3 that are not lazy-loaded. It marks the scripts worth a look from 6 outside hosts or 30 script files, and blocking scripts a problem from 3. It gives no score and runs no speed test; the one thing it times is how long your page takes to start arriving at our server, measured once and not in a shopper’s browser. Scripts that other scripts add later are not in its count, so the network log in step 3 can show more. - Watch the speed report over the following weeks. Shopify’s data can run up to 36 hours behind, and a store with little traffic swings from day to day, so one day after a change tells you little. Group the report by week, as Shopify suggests when the numbers swing, and compare the page types you changed.
Keep, limit, delay or remove: what to do with each app
With the list from step 1 in front of you, every app gets one of four answers.
| Answer | When it fits | What it means on Shopify |
|---|---|---|
| Keep | The app sells or runs the business, and loads only where it shows | Leave it, and check it again when its settings change |
| Limit | It is needed on some page types, not all | Use its block only on the templates that need it, ask the developer to limit its embed, or wrap its theme code in a template check |
| Delay | It is something the shopper may never open: chat, video, a social feed, a map | Load it when the visitor clicks a placeholder, not with the page |
| Remove | Nobody can say what it does for sales, or the theme or another app already does its job | Uninstall it, follow the developer’s removal steps, then search the code and the network log again |
When an app’s code sits in the theme, the template check is short. template.name is the type of the page being shown (Shopify developer docs), so a script that only the product page needs can be wrapped like this:
{% if template.name == 'product' %}
<script src="https://reviews.example.com/widget.js" defer></script>
{% endif %}
Apps that raise the score without making the store faster
Some speed optimisation apps and services make a store score well without making it faster. Shopify’s developer docs describe the tricks: spotting Lighthouse by how it identifies itself and serving it a stripped page, holding scripts back until the first scroll, which test tools rarely do, and painting an early element that covers the screen so the hero image no longer counts as the largest paint (Shopify developer docs). That last one is served to every visitor, so it fools the report in your admin too. Real shoppers get none of the benefit, and the added code can make the store slower. Shopify says it has removed most of these apps from its App Store, and that the same techniques are now sold as speed services.
The same page gives a quick check:
- Run PageSpeed Insights on the page, then Lighthouse in Chrome DevTools in an Incognito window. If the scores differ by 20 or more points, the store is likely affected.
- Look at the screenshots PageSpeed Insights takes. A page that looks broken there is affected.
- Compare with the web performance report in your admin. Shopify notes that real visitors usually get a faster store than the lab test does, not a slower one.
The rule behind it is one line on that page: “Core Web Vitals are proxies for the experience, not the experience itself.” A change that helps shoppers almost always shows up as the page painting sooner or responding sooner. A score that moves on its own proves nothing.
When the theme is the problem, not the apps
Not every slow store is an app problem. Shopify’s Theme Inspector for Chrome shows how long each part of your theme’s Liquid takes to render, as a flame graph. Shopify says apps and customisations to theme code can slow a store down, and that slow Liquid delays the server’s response, so the page starts rendering later (Shopify developer docs). The usual causes it names are loops that grow with the catalogue, such as nested loops and metafield lookups inside loops (Shopify developer docs).
Two more signs that the theme is the cause, both from our checklist:
- the hero is a slideshow, an autoplaying video or a JavaScript gallery, so the largest paint waits for the script that runs it;
- images arrive far larger than a phone shows them, because the theme does not ask the CDN for the right width.
A sprint fixes what is there; a redesign rebuilds the page types themselves. If the review shows the foundation is the problem, we will tell you a sprint is not enough, and redesign, move platforms or fix what you have walks through that choice.
What a fix costs
A quick-fix sprint is from $700 and takes one to two weeks. Slow pages caused by apps nobody uses any more are on the list of what a sprint usually fixes. It runs in three steps. First a free store review: a 15-minute call, then written notes, and the apps and scripts that load before anything appears are one of the things it looks at. Then an agreed list, with a fixed price for the fixes you pick. Then the fixes, each checked on phones and desktop, with a short report on what changed. Every project is priced individually, and the sprint’s price is a starting point.
When speed is a goal of a new build or a redesign in its own right, the scope adds our Speed and access pack of 25 checks: a speed budget agreed up front and measured per template, a wider set of devices, and accessibility checks beyond the basics (the pack). The pack is priced with the scope. Redesigns and builds are from $1,500. The Milla case puts our part in one line: besides building the store, we worked on how fast it loads.
What nobody can promise
No one can promise you a number in Shopify’s report before the work is done. The report comes from your real visitors, on their phones and their networks, and the apps you add next month count too. What a sprint promises is the work on the agreed list, not a number. If someone guarantees you a score, read the section on fake speed apps again.
