How to Improve Shopify Website Performance (2026)

If your Shopify store feels slow, the fix is usually more specific than it looks. Shopify already handles a lot of the performance work for you, so speeding up your store comes down to the handful of things you actually control. The trick is knowing which things those are, and which ones matter most.

This guide takes a practical approach. It sorts every fix by who actually controls it, ranks them by real impact on your Core Web Vitals, and stays honest about the box Shopify puts you in. Let us start with what actually moves the needle.

The prioritized fix list

Read this table first. Everything below is detail on these rows, ordered highest impact first.

Fix	Who can do it	Effort	Main CWV it helps	Typical impact
Compress and resize hero/product images, serve WebP	Owner	Low	LCP	High
Set explicit width/height on images and embeds	Developer	Low	CLS	High
Audit apps, remove ones you do not use	Owner	Medium	INP, LCP	High
Remove leftover app code after uninstalling	Developer	Medium	INP, LCP	High
Defer or async third-party and tracking scripts	Developer	Medium	INP	High
Cut homepage bloat (sliders, autoplay, pop-ups)	Owner	Low	LCP, CLS, INP	Medium-High
Preload the LCP image, add resource hints	Developer	Low	LCP	Medium
Replace autoplay GIFs with MP4 video	Owner	Low	LCP	Medium
Lazy-load below-the-fold images only	Developer	Low	LCP	Medium
Move to a lightweight OS 2.0 theme (Dawn/Horizon/Sense/Craft)	Owner	High	LCP, CLS, INP	Medium
Remove unused CSS/JS, use system fonts	Developer	High	INP, LCP	Medium

Notice what is not on the list: enabling a CDN, turning on caching, minifying core Shopify assets, gzip compression, or “optimizing” checkout. Those are not your job. Here is why.

What Shopify already does (stop optimizing it)

A lot of generic “speed up your website” advice was written for self-hosted WordPress, where you control the server. On Shopify, you do not. Shopify has already made these decisions for you:

• Global CDN. Every Shopify store serves assets through a CDN by default, so you do not install one and cannot swap it. Advice telling you to “set up a CDN” is written for a platform that is not Shopify.
• Server caching and compression. Shopify handles page and asset caching and serves compressed responses automatically. There is no server config for you to tune.
• Asset minification for platform assets. Shopify minifies and bundles a lot of its own delivered assets. You can still ship bloated theme code, but the platform layer is handled.
• Checkout. On non-Plus plans, checkout is Shopify’s own hosted flow. You cannot meaningfully re-engineer it for speed, and you should not try.

If a checklist spends three bullets telling you to enable caching, add a CDN, and turn on gzip, you are reading a generic article that does not understand Shopify. Skip those steps. No toggle in your admin changes them.

While we are correcting old advice, two more myths are still ranking on Google today. AMP is not a live Shopify performance strategy. Google dropped AMP as a requirement for Top Stories and its ranking boost, so building AMP pages for speed points chases a signal that no longer exists.

FID is gone too. First Input Delay was replaced by Interaction to Next Paint (INP) as a Core Web Vital in March 2024. If a guide still lists FID as one of your three vitals, it is out of date. Your three are LCP, CLS, and INP.

First, measure honestly

Before you change anything, get a baseline. Use a few tools together:

• Shopify’s own Web Performance report (Analytics > Reports). It gives a Shopify speed score based on Lighthouse, averaged across your home, product, and collection pages.
• PageSpeed Insights. Run your homepage and your top product page for both lab data and, if you have enough traffic, real-user field data.
• Lighthouse (in Chrome DevTools) for a single-page deep dive with a specific fix list.
• GTmetrix for a waterfall view of which requests are slow and in what order.

Now the part nobody warns you about. Your Shopify speed score and your PageSpeed Insights score will not match, and that is normal. Shopify averages several page types with its own weighting, while PageSpeed scores one URL at a time.

So do not chase a single number across two tools that measure differently. Pick one tool, make your changes, and re-measure in that same tool. If you want to monitor website performance over time instead of spot-checking, track the same pages on a schedule.

There is a deeper split worth understanding: lab versus field. PageSpeed and Lighthouse simulate a single load, but real visitors are the ones Google actually measures. To see that, you need real user monitoring, a small script that records Core Web Vitals from real sessions.

This is where WebYes real user monitoring fits: it tracks LCP, CLS, and INP broken down by page and by device, so you can spot that your product pages pass on desktop but fail INP on mobile. The honest catch is that field data needs the script installed and enough real traffic to be meaningful, so it complements the lab tools above rather than replacing them.

Set your expectations correctly too.

Shopify itself takes the pressure off the number. Its own guidance says there is no such thing as a perfect speed score, and that the score is not directly correlated to real-world speed because it leans toward page structure and content. What actually counts as good to Google is passing Core Web Vitals on at least 75% of your page loads.

But as one Shopify developer who says they have analyzed hundreds of stores put it, a mobile PageSpeed score around 50 is completely normal for a Shopify store.

Shopify ships a lot of storefront JavaScript for cart, search, and personalization. A green 90 on mobile is rare and usually not where your energy should go. Aim to pass Core Web Vitals in the field, not to win a lab beauty contest.

Diagnose what is actually slow

Once you have a baseline, find out which pages fail and why. Run PageSpeed Insights and Lighthouse on your worst offenders, usually the homepage and heavy product pages. Read the “Opportunities” and “Diagnostics” sections, which name the specific culprit: an unoptimized image, render-blocking JavaScript, or layout shift from an element without dimensions.

If you manage several Shopify URLs or want the failing checks pulled together in one place, the WebYes performance scan runs a Lighthouse-style audit on the URLs you give it. It surfaces which pages fail Core Web Vitals and page-speed checks, shows what is causing them, and returns suggestions to fix them. You can use it instead of Lighthouse as it can help you scan multiple pages in one go.

What you control, part 1: owner-level fixes (do these in admin today)

You do not need a developer for any of this. You need your Shopify admin and twenty minutes.

1. Fix your images (the single biggest owner-level win)

Images are almost always your LCP element, so an oversized hero image is directly setting how slow your store feels. Agencies uploading a 4MB PNG hero is a real, common problem that store owners report over and over.

Do this:

• Compress every image before upload. A free tool like Squoosh is named repeatedly by Shopify developers because it works and it is quick. Aim for under 100KB per image, and closer to 50KB for smaller ones.
• Convert to WebP. It is dramatically smaller than PNG or JPEG at the same visual quality, and Shopify can serve it.
• Do not upload a 3000px image to display at 600px. Resize to roughly the size it will actually show.

Shopify also lets you request a resized version straight from the image URL with the width parameter:

https://cdn.shopify.com/s/files/1/xxxx/product.jpg?width=800

That asks Shopify’s CDN for an 800px-wide version instead of the full-resolution original. Your theme uses this automatically for responsive images, and it is worth knowing when you paste images into pages or emails. Properly sized, well-described images help speed and image SEO at the same time.

2. Audit your apps and delete what you do not use

Apps are the number one cause Shopify developers blame for slow stores, and it comes up in nearly every thread. Every app you install can add JavaScript, CSS, and third-party requests, often on every page rather than just the page where you use the feature.

Go to your Apps list and be ruthless. Developers who run app audits routinely report that around 90% of apps can be ditched. Ask of each one: does this drive revenue, and does it justify the weight it adds?

A review app, a currency converter, three different upsell apps, an abandoned analytics tool: each is loading code. Uninstall the ones you are not actively using. That leads directly to the fix nobody checks.

3. Be careful with all-in-one “speed booster” apps

This sounds backwards, so pay attention. Store owners repeatedly report that all-in-one speed apps made things worse, not better. In one recurring account, an optimization app a previous developer installed was injecting its own JavaScript on every page and adding almost two seconds to mobile LCP.

The nuance that matters: single-purpose, run-once tools are fine. A bulk image compressor that processes your library and that you then uninstall does its job and leaves. The problem is the apps that stay resident and inject script on every page load in the name of “optimizing.”

So if you already run one and your scores are poor, try removing it and re-measuring. You may find your “speed app” was the tax.

4. Cut homepage bloat

Your homepage is usually the heaviest page and the first impression. A few common offenders hurt all three vitals at once:

• Sliders and carousels. They load every slide’s image up front and shift layout as they initialize, and most visitors never see slide three. Replace with a single strong hero.
• Autoplay video backgrounds. Heavy, and they compete with everything else for bandwidth at the worst moment.
• Pop-ups that fire on load. They inject content, cause layout shift, and delay interactivity.

You can toggle most of these off in the theme customizer without touching code.

5. Replace autoplay GIFs with MP4

A short animated GIF is often several megabytes. The same clip as an MP4 is a fraction of the size and looks better. If you have a looping product animation as a GIF, re-encode it as a muted, looping MP4 for a real weight win.

What you control, part 2: developer-level fixes (needs theme code access)

These need someone comfortable in your theme’s Liquid, CSS, and JavaScript. They are where the deeper gains live once the owner-level wins are done.

1. Remove leftover app code after uninstalling

This is the most repeated piece of advice from Shopify developers, and the one almost nobody does. As one put it, leftover app code after an uninstall is the biggest win nobody checks.

When you uninstall an app, Shopify removes the app, but code the app injected into your theme often stays behind. App embeds can usually be toggled off in Theme Settings. But hard-coded snippets, <script> tags in theme.liquid, and leftover .liquid files frequently persist, so you keep paying for apps you removed months ago.

Have your developer search the theme for orphaned app snippets, script tags, and includes tied to apps you no longer run. Diff the theme against a clean copy of your base theme if you can. This alone can noticeably cut script weight and improve INP.

2. Watch out for page builders

Page builders like GemPages, Shogun, and PageFly come up repeatedly as prime offenders. They give you drag-and-drop flexibility and, in exchange, often ship heavy markup and their own JavaScript runtime on the pages they build.

Here is the diagnostic, straight from a Shopify dev: load the same product on a native theme template and compare Lighthouse. If the native page is much faster, you have found the bottleneck, and you now know the price the builder charges.

The common advice is to stay 100% native until there is a clear business reason not to. Whether the design flexibility is worth 20 mobile points is your call, but at least make it with the number in front of you.

3. Defer and async third-party and tracking scripts

Analytics, pixels, chat widgets, review scripts, and A/B tools are render-blocking if they load synchronously in the <head>. Every one that blocks pushes back interactivity and hurts INP.

Have your developer add defer or async so they do not block rendering:

<script src="https://example.com/tracker.js" defer></script>

Use defer for scripts that need the DOM, since they run in order after parsing. Use async for independent scripts like some analytics pixels. Where Shopify supports it, use the Customer Events / Web Pixels sandbox for tracking instead of dropping raw script tags into the theme.

4. Preload the LCP image and add resource hints

Tell the browser what matters most. Preloading your LCP image, usually the homepage hero, gets it fetched earlier:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Add preconnect hints for critical third-party origins you know you will need, so the connection is warm before the request:

<link rel="preconnect" href="https://fonts.example.com" crossorigin>

Do not preload everything, though. Preloading ten things is the same as preloading nothing. One hero image and one or two genuinely critical origins.

5. Handle lazy loading correctly

Native lazy loading is a one-attribute win for below-the-fold images:

<img src="product.webp" loading="lazy" width="800" height="800" alt="...">

Two rules people get wrong. Only lazy-load below the fold, because images visible on first paint should load eagerly. And never lazy-load your LCP hero image, since deferring the exact image that defines your LCP makes LCP worse.

That last one is the most common lazy-loading mistake. If anything, your hero gets fetchpriority="high", not loading="lazy". For CLS, always set explicit width and height (or a CSS aspect-ratio) on images, videos, and embeds so the page does not jump as things load.

Good news: most OS 2.0 themes built on Dawn already do this. Shopify devs point out that v2.0+ themes use the Liquid image tag, which serves responsive images and lazy loading by default. Confirm your theme actually uses it rather than raw <img> tags added by past edits.

6. Trim theme code

The deeper theme work, in rough order of payoff:

• Remove unused CSS and JavaScript. Old sections, disabled features, and past app leftovers accumulate, and Lighthouse’s “Reduce unused JavaScript/CSS” points at the worst files.
• Load sections conditionally. Do not ship product-page scripts on the homepage; split code so each template loads only what it uses.
• Use system font stacks where you can. Custom web fonts add requests and can delay text rendering. If brand fonts are required, subset them and use font-display: swap.
• Minify custom theme code you or an app added. Shopify handles its own platform assets, but code you wrote is on you.

One real example of why this matters: a developer found a section that loaded almost the entire product catalog just to show four items. Bad section code is invisible until you go looking.

Choosing a lightweight theme

If you are on an old vintage theme, moving to a modern Online Store 2.0 theme is a real gain, because these are built for performance from the start. Shopify’s own Dawn, Horizon, Sense, and Craft are lightweight and fast by default, and devs note that Dawn is one of Shopify’s faster defaults.

But be honest about effort. Re-theming is a high-effort project: you rebuild templates, re-add customizations, and re-test everything. Do the owner-level image and app fixes first, and only migrate themes if your current one is genuinely old and bloated.

Mobile is where you win or lose

Most Shopify traffic is mobile, and mobile is where scores are worst. Phones have slower CPUs and often slower connections, so everything above matters more here.

A few mobile-specific reminders:

• Test on a real phone on cellular, not just your desktop on office wifi.
• Mobile LCP is dominated by that hero image, so compress it, size it correctly, serve WebP, and preload it.
• Mobile INP is dominated by JavaScript, so every deferred script and removed app helps the phone stay responsive to taps.
• Set your target on mobile field data, since that is what Google ranks on.

Test after every change

Change one thing, re-measure, then keep or revert. This is how you catch a “fix” that made things worse, like that speed-booster app. Batch changes make it impossible to know what helped.

So work in a loop: baseline, one change, re-test in the same tool, note the delta. Slower going, faster results.

One warning before you hire anyone

If you decide to pay someone to speed up your store, know one pattern first. Some “speed optimization” sellers do not actually speed up your store. Store owners on Reddit describe services that inject a script that detects when PageSpeed Insights is visiting and hides other scripts from it, so the score looks great while real customers get the same store.

The simple check protects you. Open your store in an incognito window on your own phone, on cellular, and see if it genuinely feels faster. A real fix survives that test, and a faked score does not.

This is the exception, not the rule, and plenty of good developers do honest work. Just judge them on real-world feel, not on a dashboard number.

FAQ