Shopify · June 12, 2023
How to Speed Up Your Shopify Store
Speeding up a Shopify store comes down to four levers: starting from a well-built Online Store 2.0 theme, optimizing images, trimming app and script bloat, and monitoring Core Web Vitals over time. Fix the theme foundation first — everything else is much easier after that.
By Polo Themes
Speeding up a Shopify store comes down to four levers, roughly in order of impact: start from a well-built Online Store 2.0 theme, optimize the images doing most of the work on your pages, keep app and third-party script count under control, and track Core Web Vitals so you know whether changes are actually helping. None of these fixes is exotic — the hard part is usually the first one, because a slow theme puts a ceiling on how fast everything else can be.
A common mistake is treating speed as an app problem — installing a "speed booster" app on top of a theme that was never built with performance in mind. That approach can help at the margins, but it can't fix a theme that renders bloated markup, loads render-blocking CSS for sections you don't use, or ships unoptimized JavaScript on every page. This guide walks through the real levers, in the order they tend to matter, so you can prioritize your time.
Why Store Speed Matters Beyond "It Feels Slow"
Speed affects two things merchants actually care about: conversion and search visibility. Shoppers abandon slow pages, especially on mobile, and every extra second of load time is a chance for someone to bounce before they've even seen your product. On the search side, Google's Core Web Vitals are part of how pages are evaluated for ranking, and a genuinely slow storefront is working against itself in both channels at once. The good news is that the fixes overlap — making a page faster for Core Web Vitals almost always makes it feel faster to a real shopper too.
Start With the Theme: Your Performance Ceiling
Every other optimization you make sits on top of your theme's foundation. If the theme itself ships excessive CSS, deeply nested markup, or JavaScript that runs on every page regardless of whether it's needed, you're optimizing around a structural problem rather than solving it.
Why Online Store 2.0 architecture matters
Shopify's Online Store 2.0 (OS 2.0) framework introduced JSON templates and app blocks, which changed how sections and apps attach to a page. Themes built properly on OS 2.0 can load only the section-specific CSS and JavaScript a given page actually needs, rather than shipping one enormous stylesheet and script bundle to every page on the store. A theme that technically supports OS 2.0 but was ported over without rethinking its asset loading won't get much of that benefit — the architecture only helps if the theme was actually built to take advantage of it.
What a well-built theme looks like under the hood
A handful of technical choices separate a fast theme from a slow one: minimal render-blocking CSS in the head, JavaScript that's deferred or loaded only for the sections present on the page, clean semantic markup instead of deeply nested wrapper divs, and section settings that don't force a full page reflow every time a merchant toggles an option in the theme editor. We build our own Shopify themes — including Optics, Medical, Wosa, Course Whiz, Electronix, and Groxery — around these principles specifically, because a theme's underlying code quality is the single biggest lever a merchant has over baseline speed, and it's the one lever that's hardest to fix after the fact with an app.
Why switching themes is sometimes the real fix
If you've optimized images, trimmed apps, and are still seeing poor Core Web Vitals scores, it's worth asking honestly whether the theme itself is the bottleneck. Retrofitting years of section customizations, custom liquid, and app integrations onto a fundamentally heavy theme has diminishing returns compared to starting from a theme that was fast from day one. This is especially true for merchants who've inherited a store from a previous developer and aren't sure what's actually happening in the theme code.
Optimize Your Images
Images are usually the single heaviest asset type on a Shopify page, and they're also the easiest win once you know where to look.
Compress before you upload
A camera or design tool export is rarely web-optimized straight out of the box. Compress product photos and banner images before uploading them to Shopify, and prefer modern formats like WebP where your workflow supports it — Shopify serves images through its CDN and will handle some transformation automatically, but starting with a smaller source file still matters.
Size images for where they'll actually render
A 4000-pixel-wide hero image served into a 400-pixel-wide thumbnail slot wastes bandwidth and slows the page down for no visual benefit. Shopify's responsive image handling helps here when a theme is built to use it correctly, serving appropriately sized versions for different viewports — but it depends on the theme requesting the right sizes in its markup, which is another place theme quality shows up.
Use lazy loading, but don't lazy-load everything
Lazy loading images below the fold is a genuine win — it keeps the browser from downloading images the shopper hasn't scrolled to yet. But the largest image visible when the page first loads (often the hero banner or main product photo) should load eagerly and be prioritized, not lazily, since it's usually what Core Web Vitals measures as your Largest Contentful Paint. A theme that lazy-loads indiscriminately, including above-the-fold images, can actually hurt this metric rather than help it.
Watch video and animated content too
Autoplay hero videos and animated GIFs look impressive but are some of the heaviest assets a page can carry. If you use video, host it efficiently, keep file sizes reasonable, and make sure it isn't blocking the rest of the page from rendering while it loads.
Audit Your Apps
The Shopify app ecosystem is a major strength of the platform, but every installed app is a potential drag on speed, and the effect compounds as apps accumulate.
Why app count adds up faster than merchants expect
Many apps inject their own JavaScript and CSS into every storefront page, not just the pages where they're actually used. A reviews app, an upsell app, a live-chat widget, and a currency converter can each add their own scripts to every page load, even on pages where none of that functionality appears. Individually each addition might be small; together they add up to noticeably slower pages, and the effect is rarely obvious from looking at any single app in isolation.
- Audit installed apps regularly and remove anything you're not actively using — a trial app left installed after the trial ended is a common source of dead weight.
- Check whether an app supports OS 2.0 app blocks, which let it load only on the templates where its block is actually placed, rather than injecting scripts globally.
- Compare apps that solve the same problem — reviews, upsells, subscriptions — and consolidate to the leaner option rather than running two overlapping tools.
- Ask whether functionality can be handled natively by the theme instead of by an app — a well-built theme like our Optics or Wosa themes builds common merchandising features directly into sections, reducing the need for an extra app entirely.
Manage Third-Party Scripts
Beyond apps installed through the Shopify admin, most stores also carry third-party scripts added manually or through tag managers — analytics tools, marketing pixels, chat widgets, A/B testing tools, and heatmap trackers.
Audit what's actually running
It's common for a store to accumulate tracking scripts over years of different marketing initiatives, with some left behind long after the campaign or tool they supported was retired. Periodically review everything loading through your theme's tracking settings or a tag manager, and remove anything that isn't tied to an active, valued use case.
Defer and load asynchronously where possible
Scripts that don't need to run immediately — most analytics and marketing tags — should be deferred or loaded asynchronously so they don't block the browser from rendering the visible page first. A script tag placed carelessly in the head without an async or defer attribute can hold up everything below it, even if the script itself is small.
Be selective with chat widgets and pop-ups
Live chat widgets and pop-up tools are useful for conversion but are also some of the heavier third-party scripts a store commonly runs, since they often load their own UI framework in addition to the widget itself. If you use one, check whether it can be configured to load only after the page is interactive, rather than as part of the initial page load.
Monitor Core Web Vitals
Speed work is only useful if you can tell whether it's working, and Core Web Vitals give you a consistent, standardized way to measure that over time rather than guessing from a subjective sense of "it feels faster."
The three metrics that matter most
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element — usually a hero image or main product photo — to render. Cumulative Layout Shift (CLS) measures how much visible content jumps around as a page loads, often caused by images or ads without reserved space, or by fonts loading in and reflowing text. Interaction to Next Paint (INP) measures how responsive the page feels when a shopper actually clicks or taps something, which matters heavily on product pages with variant pickers and add-to-cart buttons.
Where to check them
Google's PageSpeed Insights and the Core Web Vitals report in Google Search Console are the two most accessible places to check these metrics for free, and both distinguish between lab data (a simulated test) and field data (real visitor measurements), which can differ meaningfully. Field data is the more honest signal since it reflects actual shoppers on actual devices and connections, including the slower ones.
Make it a recurring check, not a one-time fix
Store speed tends to degrade gradually as merchants add products, images, sections, and apps over time, rather than breaking all at once. Building a habit of checking Core Web Vitals monthly — especially after a theme customization or a new app install — catches regressions while they're small and easy to trace back to a specific change.
Putting It All Together
If you're starting from scratch or considering a rebuild, the highest-leverage decision is the theme itself, because it sets the ceiling everything else operates under. From there, image optimization and app/script discipline are ongoing habits rather than one-time projects — a store that's fast at launch can quietly slow down over a year of well-intentioned additions. Whether you're running our Optics theme for an eyewear store, Medical for healthcare, Wosa for fashion, Electronix for electronics, Groxery for grocery, or using Course Whiz for an e-learning storefront, the same discipline applies: a solid OS 2.0 foundation, lean imagery, a short app list, and a habit of checking the numbers rather than assuming they're fine.
Frequently Asked Questions
What's the single biggest thing that slows down a Shopify store?
Most commonly it's a combination of a heavy theme foundation and unoptimized images, since images are usually the largest assets on the page and the theme controls how efficiently everything else loads around them. If you can only fix one thing, start with whichever of those two is furthest from ideal on your store.
Will installing a "speed" app fix a slow Shopify store?
It can help at the margins — some speed apps handle image compression or lazy loading reasonably well — but it can't fix a structurally heavy theme or remove the need to actually audit and reduce your app and script count. Treat speed apps as a supplement to good foundations, not a replacement for them.
How often should I check my store's Core Web Vitals?
A monthly check is a reasonable baseline for most stores, with an extra check any time you make a meaningful change — a new theme customization, a new app, or a redesigned page template. Catching a regression early, while you still remember what changed, makes it far easier to trace and fix.
Does switching to a faster theme mean losing my current design?
Not necessarily. Many merchants can recreate their existing look using a faster theme's built-in sections and styling options, since OS 2.0 themes are generally more flexible with layout than older theme generations. It's worth treating a theme switch as an opportunity to rebuild cleaner rather than assuming it means starting your design over from nothing.