The Shopify Speed Self-Audit: 15 Checks and Who Owns Each Fix
TL;DR
- Most Shopify stores are slow because of the theme and the apps, not the platform. Nobody is clearly responsible for either, so the slowness stays.
- This self-audit has 15 checks across four areas: baseline, apps, theme and media, and tags and ownership.
- Mark each check Pass, Fail or Not sure. The scorecard totals your results and shows which person or team owns each fix.
- Checks flagged High priority have the biggest effect on load time and conversion. Fix those first.
- A full audit takes about 60 to 90 minutes with Shopify admin access and Chrome.
Shopify is a fast platform. Most Shopify stores are not fast stores. The theme developer handed over a working build, each app vendor added one small script, the merchant installed the apps and an agency added the ad tags. Everyone did their part and the store still scores in the teens on mobile PageSpeed.
That is an accountability gap, and it is the gap this resource is built to close. It is written for store owners weighing up Shopify development in Sydney and for anyone already on Shopify who suspects the store is slower than it should be. On one store we audited, 43 apps were installed, the homepage made 127 network requests before first paint, mobile PageSpeed was 12 and conversion sat at 0.6 percent. The ads were not the problem. The site was.
Who owns each source of slowness
Speed is the sum of every decision made on the store, and each decision has a different owner. Four of the five main sources are introduced by people who are not responsible for the performance cost. That is why speed drifts.
| Source of slowness | Usually introduced by | Should be owned by |
|---|---|---|
| Heavy theme code and unused sections | Theme developer or theme vendor | The developer who customises it |
| Apps and their scripts | The merchant, one need at a time | The merchant, with developer review |
| Third-party tags (analytics, ads, chat) | Marketing team or ad agency | Whoever manages the tag container |
| Large or unoptimised images | Whoever uploads product content | The merchant, with developer guardrails |
| Leftover code from removed apps | Nobody | The developer, during an audit |
How to use this resource
Open your store in one browser tab and this page in another. Each check explains what it catches, where to look and what a clean result looks like. Choose Pass, Fail or Not sure. The scorecard at the bottom groups every Fail and Not sure by owner, so you know who to send the list to.
Record your numbers in check 1 before you change anything. Without a baseline, nobody can say whether a fix worked.
Baseline and measurement: Checks 1 to 3
Baseline recorded for three page types HighNamed owner
A store with no baseline cannot prove it is slower than launch day, or that a fix worked. Test the homepage, one collection page and one product page separately, because they load different code.
PageSpeed Insights. Run the mobile test on all three page types and record the performance score, Largest Contentful Paint and Total Blocking Time with the date. Run each twice and use the better figure, because single runs vary.
Real-visitor Core Web Vitals checked HighNamed owner
Lab tests show what could happen. Field data shows what real visitors on real devices experience, and it is the data Google uses. A store can score well in a lab test and still fail in the field.
Google Search Console, Core Web Vitals report. Check mobile first. Note how many URLs sit in Poor and Needs improvement, and which issue is named. Google’s published thresholds for a good result are an LCP of 2.5 seconds or under, an INP of 200 milliseconds or under and a CLS of 0.1 or under.
Low-traffic stores. If Search Console shows no data, use the field data section at the top of PageSpeed Insights, or note that traffic is too low and rely on lab results.
Speed re-measured on a schedule MediumNamed owner
Speed drifts slowly. A store that launches fast can be 30 points slower a year later, with no single change to blame. Regular measurement is the only early warning.
Ask who last ran the three page tests from check 1, and when. Look for a monthly entry in a report, a shared sheet or a task list.
Apps: Checks 4 to 7
Full app inventory exists HighMerchant
Most stores are over-apped by year two. An operational need comes up, someone installs an app, and it is never reviewed again. Without a list, nobody knows what is running or what it costs.
Shopify admin, Apps. List every installed app with what it does, its monthly cost, who installed it and whether anyone still uses it. Include apps that are installed but switched off in the theme editor.
Unused and overlapping apps removed HighMerchant
Every app carries a performance cost, a subscription fee and a security surface. Features that once needed an app are often built into Shopify or the theme now. Two apps doing similar jobs is a common finding.
Work through the inventory from check 4. For each app ask: is it used this month, does Shopify or the theme now do this natively, and does another app overlap it? On app rationalisation work we typically remove 30 to 50 percent of apps without losing functionality.
No leftover code from removed apps HighDeveloper
Uninstalling an app does not always remove what it added to the theme. Snippets, script tags and stylesheet references can stay behind, still loading on every page and calling a service that no longer exists. It is the least visible source of slowness, and nobody owns it by default.
Online Store, Themes, Edit code. Search the theme for the names of apps you have removed, and review the head of the main theme layout file, the snippets folder and the assets folder for references you cannot explain. Take a copy of the theme before you delete anything.
App scripts only load where needed MediumDeveloper
Many apps load their scripts on every page, even where the feature never appears. A reviews widget has no business loading on the cart page, and a size-guide app does not need to run on the homepage.
Chrome DevTools, Network tab. Reload a page and filter to third-party requests. Group them by domain and match each domain to an app. Then check the PageSpeed Insights report for the third-party code diagnostic on the same page.
Theme and media: Checks 8 to 11
Theme is lean and current HighDeveloper
A premium theme is built to suit thousands of stores, so it ships with sections, options and scripts yours may never use. An old theme can also pre-date Shopify’s current section architecture and carry years of patches.
Online Store, Themes. Note the theme name, version and last update. In the theme editor, list the sections in use against the sections the theme carries. Ask your developer whether it uses Online Store 2.0 sections and how many customisations sit on top of the original.
JavaScript does not block rendering MediumDeveloper
Scripts loaded in the page head without deferral stop the browser drawing the page until they finish. On mobile connections this is often the difference between a store that feels instant and one that feels broken.
PageSpeed Insights. Look for the render-blocking requests diagnostic. Then open the main theme layout file and check which scripts load in the head and whether they use defer or async.
Largest image loads quickly and is not lazy-loaded HighMerchant and developer
The biggest visible image, usually the homepage banner or the main product photo, is normally the Largest Contentful Paint element. If it is oversized, requested late or lazy-loaded, the LCP score suffers on every visit.
PageSpeed Insights. Open the LCP element diagnostic to see which image it is. Check its file size and whether it is requested at the size it is displayed. Images below the first screen should be lazy-loaded, but the LCP image should not be.
Fonts are limited and load efficiently LowDeveloper
Each custom font weight is another file to download, and text can stay invisible or jump when the font arrives. Stores often carry three or four weights where two would do.
Chrome DevTools, Network tab, Font filter. Count the font files on the homepage. Check the PageSpeed Insights report for a font display diagnostic and a layout shift caused by late-loading text.
Tags and ownership: Checks 12 to 15
Tag inventory is clean, with no duplicates HighMarketing or agency
Analytics, ad pixels and conversion tags usually arrive through Google Tag Manager, an app or the theme, and often through more than one at once. Duplicate tags slow the page and double-count conversions.
Google Tag Manager, Tag Assistant and your apps. List every tag firing on a product page and check that each fires once. Compare the list against the tags set up inside any apps and the theme. Remove tags for campaigns and platforms that have ended.
Chat, popup and review widgets are deferred MediumMarketing or agency
Chat boxes, email popups and review badges are heavy for what they do, and most visitors never touch them. They do not need to load before the page is usable.
Chrome DevTools, Performance or Network tab. Check when each widget loads relative to the first paint of the page. Ask the app vendor or your developer whether it supports delayed or on-interaction loading.
A named owner and a performance budget exist HighNamed owner
If nobody owns speed, nobody says no. A performance budget gives the owner something to say no with: a limit that every new app, tag or section has to fit inside.
Ask: who is accountable for our speed numbers, and what is the limit? A workable budget names a target such as an LCP of 2.5 seconds on mobile, and it is written down somewhere the team can see.
New apps and tags go through an approval step MediumNamed owner
Speed problems are mostly created one small approval at a time. A short step before anything new goes live stops the slow build-up.
Ask how the last app or tag was added. Was its speed cost measured before and after? Did anyone other than the requester sign it off? Does a review follow in a month?
Your scorecard: who owns the fixes
Mark at least one check to see which person or team owns your Fail and Not sure results.
What to fix first
If you find several failures, work in this order. It runs from the changes that cost least and gain most to the larger structural work.
| Priority | Checks | Why |
|---|---|---|
| Fix first | 1, 2, 4, 5, 6, 8, 10, 12, 14 | These set the baseline and remove the heaviest, most common sources of slowness. Apps and leftover code usually give the biggest gain for the least effort. |
| Fix this month | 3, 7, 9, 13, 15 | These tighten how scripts load and stop the problem coming back. Do them once the high-priority items are done. |
| Fix this quarter | 11 | A real but smaller gain. Add it to the next scheduled review. |
Most stores we audit can reach a mobile PageSpeed score of 85 or higher without a rebuild, through app rationalisation, theme cleanup and script deferral. A rebuild is the right call when the theme is the problem and cleaning it costs more than replacing it.
For an example of a performance budget in practice, see how Zebra Home's Shopify store held its speed. For the launch side of the same problem, read why we launch on a quiet Tuesday. If your needs go beyond what Shopify can flex to, we also build on WooCommerce development, and we recommend based on fit.
If your audit surfaces more than a few Fails, or you would like a second pair of eyes on the theme and app stack, our Shopify team in Sydney can audit the store, record a baseline and tell you plainly what is costing you.
Book a free Shopify speed audit
Frequently Asked Questions
Why is my Shopify store slow?
In most cases it is the theme and the apps, not Shopify itself. Each installed app can add scripts to every page, premium themes carry code you may never use, and uninstalled apps can leave code behind in the theme. A speed audit that covers all three usually finds the cause.
How many Shopify apps is too many?
There is no safe number, because the cost depends on what each app loads. The better test is whether each app earns its place. We have audited a store running 43 apps, and on app rationalisation work we typically remove 30 to 50 percent of apps without losing functionality.
Can I make my Shopify store faster without rebuilding it?
Usually, yes. App rationalisation, theme cleanup and script deferral often lift a store a long way. A rebuild makes sense when the theme itself is the problem and cleaning it costs more than replacing it.
Who is responsible for Shopify speed?
Whoever you name. Without a named owner, speed belongs to nobody, because the theme, the apps, the tags and the images each have a different source. Assign one person or team, give them a launch baseline to track, and give them authority to refuse additions that cost too much.
What is a good mobile speed target for a Shopify store?
Google's published thresholds for a good experience are a Largest Contentful Paint of 2.5 seconds or under, an Interaction to Next Paint of 200 milliseconds or under, and a Cumulative Layout Shift of 0.1 or under, measured on real visitors. Many stores we audit can reach a PageSpeed Insights mobile score of 85 or higher without a rebuild.
How often should I re-run a Shopify speed audit?
Re-measure monthly against your launch baseline, and run the full audit at least once a quarter. Re-check straight away after installing an app, adding a tag, changing the theme or running a major campaign.
