Shopify Page Speed Optimization: A Developer's Checklist

Most Shopify speed advice stops at “compress your images and delete some apps.” That’s fine as a starting point, but it won’t get a mature theme from a mediocre PageSpeed Insights score into genuinely fast territory. The gains that matter, the ones that show up in Core Web Vitals and in how a store actually feels to use on a mid-range Android phone, come from the theme code itself, the render-blocking resources it loads, and the third-party scripts stacked on top of it.

This is a working checklist, written the way we’d actually work through a theme audit: from the highest-impact structural issues down to the smaller cleanup items. It assumes some comfort with Liquid, browser dev tools, and reading a waterfall chart. If you’re a merchant rather than a developer, you can still use this to brief whoever builds your theme, or to sanity-check work that’s already been done.

Work through it roughly in order. Structural issues (render-blocking JS, unoptimised Liquid, bloated app embeds) tend to have far more impact than fine-tuning further down the list, so there’s little point polishing font-display strategy on a theme that’s still shipping 400KB of blocking JavaScript on every page.

Step 1: Baseline the store properly before touching anything

Before any changes, get a clean, repeatable read on where the store actually stands.

Shopify’s own online store speed report (Shopify admin → Online Store → find “Speed” under your theme, or Analytics reports depending on your plan) gives a Shopify-normalised score benchmarked against comparable stores. It’s a decent sanity check, but treat it as directional, it’s not the same methodology Google uses for ranking signals.
Google PageSpeed Insights (pagespeed.web.dev) is the closest proxy to what Google’s Core Web Vitals scoring actually sees, because it pulls both lab data (Lighthouse) and, when there’s enough traffic, real-user field data from the Chrome User Experience Report (CrUX).
Lighthouse in Chrome DevTools for repeatable lab testing during development, throttle to “Slow 4G” and mid-tier mobile CPU, not the default desktop settings, because that’s closer to how most Australian mobile shoppers actually experience the store.
WebPageTest.org for the detail the others don’t give you: a full waterfall, filmstrip view of what’s rendering when, and the ability to test from specific locations and connection speeds.

Test the homepage, a representative collection page, and a representative product page, they often have very different bottlenecks. Run each test three times and take the median; a single run can be noisy.

While you’re baselining, screen-record or note down what the filmstrip shows: is the layout mostly stable and just slow to paint text and images, or is content jumping around as fonts, images and app widgets pop in at different times? These are different problems with different fixes, and the filmstrip view in WebPageTest (or the Performance panel in Chrome DevTools) is the fastest way to tell them apart before you start changing code.

Step 2: Audit the theme code itself

Find render-blocking Liquid includes

Open the theme’s theme.liquid and check what’s loading in <head> before the visible content. Any {% render %} or {% include %} (legacy syntax) that pulls in a snippet doing heavy computation, nested loops over collections, metafield lookups across every product, will hold up first paint if it’s not scoped to only the templates that need it.

Move snippets that are only used on specific templates (e.g. a mega menu builder, a countdown timer) out of the global layout and into template-specific sections where possible.
Check for {% for %} loops that iterate over full collections or all_products unnecessarily, these can silently blow out server response time on stores with large catalogues.
Watch for repeated metafield or linklist lookups inside loops; hoist them outside the loop where the logic allows it.

Defer and async-load JavaScript

Any <script> tag in theme.liquid or section files that isn’t needed to render above-the-fold content should carry defer (executes after HTML parsing, in order) or async (executes as soon as it’s downloaded, no order guarantee).
Scripts tied to below-the-fold functionality, reviews widgets, related-products carousels, chat launchers, should be loaded on interaction or on scroll-into-view rather than on initial page load, using IntersectionObserver or a simple scroll listener.
Avoid inline <script> blocks scattered through sections where possible; consolidate into as few deferred bundles as is practical for the theme’s build process, to reduce the number of separate parser interruptions.

Remove unused CSS

Most stock and purchased themes ship far more CSS than any individual page uses, styles for sections, blocks, and layout variants that this particular store never enables.

Use Chrome DevTools’ Coverage tab (Cmd/Ctrl+Shift+P → “Show Coverage”) on the homepage, a collection page, and a product page to see the percentage of loaded CSS that’s actually applied.
Strip out styling for unused sections, discontinued app widgets, and legacy theme features that were never removed from the stylesheet.
Where the theme architecture allows it, split CSS so template-specific styles only load on that template rather than being bundled globally.

Set a font-display strategy

Custom fonts are a common, easily-fixed cause of layout shift and delayed text rendering.

Use font-display: swap (or optional for non-critical fonts) in @font-face declarations so text renders in a fallback font immediately rather than staying invisible while the custom font downloads.
Preload the primary heading and body fonts with <link rel="preload" as="font"> if they’re critical to the above-the-fold experience.
Limit the number of font weights and styles loaded, many themes load four or five weights when the store only visibly uses two.

Step 3: Audit third-party scripts and app embeds

This is usually where the biggest, easiest wins live, because it doesn’t require touching theme code at all.

List every app installed and cross-reference against what’s actually used. Trial apps, replaced apps, and “we might use this later” apps often keep injecting script tags long after anyone stopped using the feature.
Check Online Store → Themes → Customize → App embeds for embeds that are toggled on but not genuinely needed on every page.
Open the Network tab and filter by JS on a cold load to see which third-party domains are firing scripts, review widgets, upsell tools, tracking pixels, chat widgets, personalisation engines. Each one is a separate DNS lookup, connection, and often a render-blocking or main-thread-blocking payload.
Move what you can from Shopify’s Additional Scripts / Google Tag Manager into deferred, conditional loading rather than firing everything on every page load regardless of whether that page needs it.
Replace duplicate functionality. It’s common to find two or three apps doing overlapping jobs (two reviews apps, two upsell apps) left over from testing.

Every script you remove is one less thing competing for main-thread time during page load, which is exactly what Core Web Vitals metrics like Interaction to Next Paint are measuring.

Step 4: Images and CDN handling

Serve images through Shopify’s CDN with the image_url / image_tag Liquid filters and appropriate width/height parameters rather than hardcoding oversized source images.
Use srcset and sizes so browsers download an appropriately sized image for the viewport rather than a single large master image everywhere.
Set loading="lazy" on below-the-fold images, but never on the largest above-the-fold image (usually the hero or first product image), lazy-loading that one delays Largest Contentful Paint rather than helping it.
Explicit width and height attributes (or aspect-ratio in CSS) prevent layout shift as images load in.

If image weight is your single biggest issue, it’s worth reading our companion piece on Shopify image optimisation in more depth, it’s a big enough topic to deserve its own checklist.

Step 6: Re-test properly and watch for regressions

Once you’ve worked through the checklist, re-run the same tests from Step 1, same tools, same pages, same throttling settings, so the before-and-after comparison is genuinely apples-to-apples. A few things worth checking specifically at this stage:

Re-test on mobile throttling, not just desktop. It’s common to see a solid desktop improvement mask a smaller (or even negative) mobile result, particularly if a “fix” involved adding more JavaScript to lazy-load something that used to render eagerly.
Click through the theme customiser and check every section variant, not just the default homepage layout. Removing “unused” CSS or deferring a script can quietly break a section that only appears in a specific layout combination you didn’t happen to load during testing.
Check app functionality end to end, add to cart, apply a discount code, submit a review, after any script-loading changes, since deferring or reordering scripts can change the order apps expect their dependencies to load in.
Re-check Cumulative Layout Shift specifically, since it’s the metric most likely to regress from image or font changes even when overall load time improves.

Keep a simple before-and-after record of your test results for each template. It’s useful for tracking progress over time, and it’s the first thing worth having on hand if you ever bring in outside help to continue the work.

Step 5: Where a technical audit becomes a specialist job

Everything above is doable by a competent developer working methodically through a theme. Where it gets genuinely difficult is when the fixes start conflicting with each other, deferring a script breaks an app’s initialisation order, or removing “unused” CSS turns out to affect a section that’s only visible in a specific theme customiser layout you didn’t test. At that point, you’re not doing speed optimisation anymore, you’re doing regression testing across every template and device combination the store supports.

This is exactly the point at which it’s worth bringing in a specialist rather than continuing to chase diminishing returns solo. Nexly’s Shopify performance optimisation work is built around this kind of structured theme-and-script audit, going through the store section by section, measuring the actual impact of each change against Core Web Vitals rather than guessing, and making sure a speed fix on desktop doesn’t quietly break something on mobile.

FAQ

How long does a full Shopify speed optimisation typically take?
It depends heavily on theme complexity and how many apps are installed, but a thorough audit-and-fix pass on a mid-sized store, covering theme code, scripts, and images, commonly takes a couple of weeks of focused work rather than a single afternoon. Stores with heavily customised themes or large catalogues take longer.

Will deleting apps actually make my store faster?
Often, yes, but not always, it depends on whether the app injects scripts globally or only where it’s actively used, and whether it was loading synchronously or deferred. Uninstalling an app doesn’t always remove every trace of its script tags cleanly, so it’s worth checking Additional Scripts and theme code afterwards.

Does Shopify’s own platform speed limit how fast a theme can be?
Shopify’s checkout and core platform infrastructure is generally fast and outside merchant control, so most of the speed variation you see between stores comes from theme code, apps, and third-party scripts, not the platform itself. That’s good news, because it means the fixes are genuinely in your control.

Is Lighthouse score the same as my Core Web Vitals score in Google Search Console?
No. Lighthouse gives you lab data from a single simulated test run, while Core Web Vitals in Search Console (and PageSpeed Insights’ field data) reflects real visitor experiences over the past 28 days. A theme can score well in Lighthouse and still show weaker field data if real visitors are on slower connections or older devices than the lab test simulates.

Should I optimise for mobile or desktop first?
Mobile, in almost all cases. Most Shopify stores see the majority of their traffic on mobile devices, and Google’s ranking systems primarily use mobile page experience. A theme that’s fast on desktop but sluggish on a mid-range Android phone is optimised for the wrong audience.

Ready for a proper look under the hood?

If you’ve worked through this checklist and want a second set of eyes, or simply don’t have the time to do a full theme audit yourselves, a Shopify audit is a straightforward way to get a clear, prioritised list of what’s actually slowing your store down. Alternatively, book a call with our team and we’ll talk through what a performance project would look like for your specific theme and app stack.