To speed up a Shopify store, measure with Core Web Vitals field data from real shoppers, then fix in order of impact: unused app code, oversized images and media, heavy theme code, fonts, and third-party scripts. Most slow Shopify stores aren’t slow because of Shopify. They’re slow because of what’s been added on top of it.
Measuring speed the way Google and shoppers experience it
There are two kinds of speed data, and only one of them reflects your customers.
- Lab data is a simulated test, like the Lighthouse score in PageSpeed Insights. It runs one page load on a throttled mobile profile and swings from run to run. Good for debugging, bad as a target.
- Field data comes from real visits. PageSpeed Insights shows it at the top of the report when Google has enough traffic for the URL or origin, as a 28-day rolling window. Search Console’s Core Web Vitals report groups similar URLs, and Shopify’s admin includes a web performance report built on real visits to your store.
Google judges each metric at the 75th percentile of visits, so the slowest quarter of your shoppers decides whether you pass.
| Metric | What it measures | Good | Usual Shopify culprit |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main image or text block appears | 2.5 s or less | Oversized hero or product images, sliders, render-blocking app scripts |
| INP (Interaction to Next Paint) | How fast the page responds to taps: variant picker, add to cart, menu | 200 ms or less | JavaScript from apps, tag managers and chat widgets |
| CLS (Cumulative Layout Shift) | How much the layout jumps while loading | 0.1 or less | Images without dimensions, app banners injected late, font swaps |
Check by template, not just the homepage: home, collection, product and cart. Start with mobile product pages, because that’s where paid and social traffic usually lands. For each template, record a baseline: mobile LCP, INP and CLS, the number of third-party domains in the network panel, and the mobile conversion rate. You’ll need that baseline to prove anything later.
Speed is also one line in a broader technical SEO audit. If rankings are part of the problem, run both together.
The fix order at a glance
This ranking reflects what I typically find when auditing Shopify stores. Your baseline may reorder it, so let the data decide where you start.
| Rank | Fix | Metrics it moves | Typical effort |
|---|---|---|---|
| 1 | Remove unused apps and leftover app code | LCP, INP | Low to medium |
| 2 | Right-size the LCP image; drop sliders and autoplay video | LCP, CLS | Low |
| 3 | Fix slow Liquid and render-blocking theme JavaScript | LCP, INP | Medium to high |
| 4 | Trim fonts and load them properly | LCP, CLS | Low |
| 5 | Clean up tag managers and delay third-party widgets | INP, LCP | Low to medium |
App bloat and leftover code
Every app that touches the storefront can add JavaScript, CSS and extra network requests, often on every page, including pages where it does nothing. Ten apps that each seem light add up to a heavy page.
Uninstalling isn’t always enough. Apps built on theme app extensions (app blocks and app embeds) are removed cleanly. Older apps that edited theme files directly, injecting snippets into theme.liquid or product templates, can leave code behind that keeps loading scripts or calling files that no longer exist.
Work on a duplicate of the live theme, then:
- List every installed app with its owner, purpose and the revenue or workflow it supports
- Uninstall apps nobody can justify, and replace apps that duplicate built-in theme features such as announcement bars, swatches or size charts
- In the theme editor, switch off app embeds you don’t use
- Search theme files for
renderorincludetags, snippet files and<script>tags that belong to apps you’ve removed - Filter the DevTools network panel by domain and match each third-party request to an app you still pay for
- Move app blocks to the templates that need them instead of loading them site-wide
This is usually the highest-return hour of any Shopify speed project, because you get speed back by deleting, not building.
Images and media
On product pages, the LCP element is usually the main product image. On the homepage, it’s the hero banner or the first slide.
Shopify’s CDN resizes images and serves modern formats when the theme requests them properly. Problems start when the theme asks for images far wider than they display, skips responsive srcset markup, or treats the hero like any other image. Fix those first:
- Request the right size. Use the
image_urlfilter with a width, andimage_tagwithwidthsandsizes, so phones don’t download desktop images. - Never lazy-load the LCP image. Lazy-load everything below the fold, but load the hero or first product image eagerly with
fetchpriority="high". - Replace hero sliders with one static image. Slideshows load several large images plus their own JavaScript, and later slides rarely get seen.
- Tame video. Don’t autoplay background video on mobile. Use a poster image, and replace embedded YouTube players with a thumbnail that loads the player on click.
- Always set dimensions. Width and height, or a CSS aspect ratio, reserve space and prevent layout shift.
- Convert animated GIFs to video. GIFs are often many times larger than an equivalent MP4.
Theme code and Liquid performance
Shopify renders Liquid on its servers before sending the page, so complex Liquid shows up as slower server response, which delays everything after it.
Common culprits:
- Loops inside loops, such as iterating every product in a collection and then every variant, to build filters or badges
- Mega menus that render dozens of product images and links on every page
- Large collections rendered without pagination
- Repeated metafield lookups inside loops
The Shopify Theme Inspector for Chrome profiles Liquid render time as a flame graph, which shows exactly which snippet is slow. On the JavaScript side, look for scripts loaded in the <head> without defer, large theme bundles built on old libraries, and features you’ve disabled but still ship. Shopify’s Theme Check linter flags parser-blocking scripts and oversized assets.
Then make the refactor-or-replace call. If the theme has years of layered customizations and outdated JavaScript, a clean rebuild on a modern Online Store 2.0 theme can be cheaper than fixing it piece by piece. Consider headless Shopify only if you have reasons beyond speed; most stores don’t need it to pass Core Web Vitals.
Fonts, tag managers and third-party scripts
Fonts
Each font family, weight and style is a separate file. Two families and three or four files is plenty for most stores. Use Shopify’s font library through the font_face filter with font_display: 'swap' so text appears immediately, and preload the main body font. A system font stack is the fastest option if the brand allows it.
Tag managers and pixels
Google Tag Manager containers collect tags for tools nobody uses anymore. Audit the container and remove dead tags. Watch for duplicates: a Meta pixel installed through the sales channel app and again through GTM slows the page and double-counts conversions. Where possible, use Shopify’s native channel integrations and customer events, whose custom pixels run in a sandbox rather than directly in the theme.
Widgets
Chat, reviews, loyalty, popups, heatmaps and personalization tools are often the heaviest scripts on the page and the worst for INP. Load chat on click or after the page is idle, load review widgets when they scroll into view, and run session recording tools in time-boxed windows rather than permanently.
What you can’t control on Shopify
Shopify is hosted, so some levers aren’t yours:
- Hosting, CDN and caching. Shopify runs the servers and the CDN. They’re fast, but you can’t tune them.
content_for_header. This required object intheme.liquidis how Shopify injects its own analytics, pixel and app scripts. You don’t control what it outputs, and stripping or rewriting it breaks apps and tracking, so leave it in place.- Checkout. Checkout runs on Shopify’s infrastructure, and theme speed work doesn’t touch it. Customization happens through Shopify’s checkout editor and extensions, with more options on Plus.
- Vendor code. You decide when a third-party script loads, not how well it’s written.
- A perfect lab score. Shopify’s own scripts and throttled simulation keep many well-built stores below 100. Chasing it wastes budget. Good field data is the goal.
Tying speed changes to conversion rate
Speed is a means. The point is more orders from the same traffic, so measure it that way:
- Baseline four weeks per template: mobile field vitals, mobile conversion rate and product-page add-to-cart rate.
- Ship changes in batches and log the date and template for each one.
- Compare equal windows before and after, excluding sale weeks and launches, and check that the traffic source mix stayed similar.
- Watch leading indicators first. Add-to-cart rate and product-page exits respond faster than overall conversion rate.
- Wait for field data to catch up. The 28-day window means the full improvement takes about a month to show.
A hypothetical example: mobile product-page LCP drops from 4.0 to 2.3 seconds after removing two unused apps and fixing the hero image. Over the next four weeks, compare mobile add-to-cart rate with the previous four. If it rose while traffic mix and promotions held steady, you have a reasonable, not conclusive, link. If nothing moved, speed wasn’t the bottleneck, and the next fix is on the page itself.
When I take on Shopify development work, speed changes get the same treatment as any conversion change: a baseline, a log and a before-and-after read.
Get it built
If your store feels slow and you’re not sure which apps or scripts to blame, I can audit it and fix it. The Growth Audit is $1,500 fixed and credited if we continue. See pricing or get in touch.