arrow_backBack to Blog
PerformanceFebruary 5, 2026schedule3 min read · 681 words

Your Shopify Store Is Probably Slow

N7

No7 Engineering Team

Growth Architecture Unit

Performance — Your Shopify Store Is Probably Slow — illustration

We audit a lot of Shopify stores. The same issues come up again and again. The good news is most of them are fixable without rebuilding your entire site.

The Usual Suspects

App Bloat

Every app you install can add JavaScript to your storefront. Some add a lot. That free reviews app? Probably loading 200KB of JavaScript on every page. The chat widget? Another 150KB. That countdown timer you used once? Still loading.

Check your apps. Uninstall anything you're not actively using. For the ones you keep, check if they're loading on pages where they're not needed.

Unoptimised Images

We regularly see product images that are 5MB each. Your customers don't need 4000x4000 pixel images on a product grid. Use appropriate sizes, serve WebP format, and lazy load anything below the fold.

Theme Cruft

Themes come with features you might not use. Carousels, mega menus, animation libraries—if you're not using them, they might still be loading. A theme audit can identify what's being loaded unnecessarily.

Quick Wins:

  • check_circleAudit installed apps: Remove unused ones, check impact of remaining ones
  • check_circleCompress images: Use TinyPNG or similar before uploading
  • check_circleLazy load: Images, videos, and embeds below the fold
  • check_circleReview third-party scripts: Analytics, chat, tracking pixels
  • check_circleFont loading: Limit custom fonts, use font-display: swap

How to Measure

PageSpeed Insights is a starting point, but real user data matters more. Check your Core Web Vitals in Google Search Console. Look at your analytics for mobile vs desktop performance—mobile is usually worse and that's where most of your traffic probably comes from.

When to Rebuild

Sometimes the theme is fundamentally the problem. If you're on an old theme that wasn't built with performance in mind, incremental fixes only go so far. A rebuild on a modern theme (or headless) might be the better investment.

What We Do

Our performance audits identify exactly what's slowing your store down, with prioritised recommendations based on impact and effort. Sometimes it's an afternoon of cleanup; sometimes it's a bigger project. Either way, faster stores convert better.

The Audit Process We Actually Follow

"Your store is slow" is not actionable. A useful audit produces a ranked list of fixes with effort estimates. Our rough template:

  1. Baseline in both lab and field. Lighthouse tells you what could go wrong; Chrome UX Report (CrUX) tells you what actually does.
  2. Identify the LCP element. Almost always a product or hero image. If the browser is discovering it late, preload it. If it's too big, downsize it.
  3. Find the main-thread blockers. Chrome DevTools Performance panel, looking for long tasks > 200ms. Most are third-party scripts.
  4. Attribute cost per app. Disable apps one by one on a staging theme and measure. Some apps cost 5-10 Lighthouse points on their own.
  5. Ship in priority order. Highest-impact-lowest-effort fixes first. Do not start with a full rebuild.

App Bloat Patterns We See Most Often

The Usual Offenders

  • Review widgets that load on every page even when reviews aren't visible — often easy to scope to PDPs only.
  • Chat/messenger scripts that boot on page load instead of on first scroll or interaction.
  • Three overlapping analytics stacks — GA4 + a tag manager + a "universal" tracker + a CDP, all firing the same events.
  • CRO tools left installed years after the last test ended, still waking up on every request.
  • Countdown and urgency timers that rely on page-level JS bundles large enough to noticeably hurt INP.

The fix is rarely "remove all apps." It's "defer them until they're needed." Loading on requestIdleCallback or first user interaction is usually enough.

Mobile Is Where It Matters

Most traffic is mobile, most mobile traffic is on mid-range Android over a real 4G connection, and that environment is far harder than whatever Mac you're testing on. We run final tests using Chrome DevTools' Slow 4G throttling on a mid-tier CPU profile. If the site passes Core Web Vitals there, it'll pass almost anywhere. If it fails, no amount of code cleanup on the desktop profile will save you. We dig deeper into this in our mobile PageSpeed optimisation guide.