Shopify Speed Optimization: 5 Proven Fixes for Faster Stores

A slow Shopify store rarely has one problem. It usually has a heavy hero image, eight apps that each load their own script, a theme section that loops over every variant of every product and a font that causes the page to jump as it loads. Each item looks small, and together they push load time past the point where visitors leave.

The good news is that Shopify’s own developer documentation lays out exactly where the time goes and what to do about it, and most fixes do not require rebuilding the store.

This guide to Shopify speed optimization follows that documentation and adds what we see when we audit stores. We cover how to measure properly, how to fix images, Liquid code, JavaScript, apps, fonts and layout shifts, and how to avoid the shortcuts that make scores look good without helping customers. Where we quote specific guidance, it comes from Shopify’s theme performance best practices.

Why Shopify speed optimization matters

Speed affects what visitors do and how search engines see your store. Google’s Core Web Vitals measure three things: Largest Contentful Paint (LCP), how quickly the main content appears; Interaction to Next Paint (INP), how quickly the page responds when someone taps or clicks; and Cumulative Layout Shift (CLS), how much the layout jumps around. Shopify’s documentation notes that Core Web Vitals are measured on mobile by default, so mobile performance is theme performance.

It also points out that Time to First Byte (TTFB) and First Contentful Paint (FCP) help you find the cause of a slow LCP. Google explains the metrics on web.dev.

For a store, slowness has practical costs: shoppers abandon pages that appear late or jump while they are about to tap, and a slow, unstable checkout path loses orders. Speed also supports advertising performance, since landing pages that load faster tend to convert better, though the size of the effect varies by store.

Step 1: Measure before you change anything

Guessing wastes time. Set a baseline first:

• Test the pages that matter: home, a collection, a product page and the cart, not just the home page.
• Use real data where possible. Field data from real visitors, available through Google’s tools, shows what customers experience. Lab tests such as Lighthouse are useful for diagnosing.
• Use Shopify’s tools. The documentation recommends running the same Lighthouse benchmark Shopify uses and the Shopify Theme Inspector for Chrome, which shows the slowest Liquid lines so you can find problems before optimising.
• Record the numbers for LCP, INP, CLS and TTFB on mobile.
• Test on a throttled mobile connection, since many shoppers are not on fast Wi-Fi.

Write the results down. After each change, test again, so you know what helped.

Step 2: Fix the largest image first

For most stores, the LCP element is a hero image or the main product image, so this is the best place to start. Shopify’s guidance is specific:

• Never lazy-load the LCP image. Apply lazy loading only to images outside the initial viewport.
• Mark the LCP image with high fetch priority, which Shopify describes as a one-line change with measurable gains. See web.dev on fetch priority.
• Do not hide the LCP image behind fade-in animations, which delay it even after it has loaded.
• Use real image elements for hero content, not CSS background images, so the browser finds them early.
• Use responsive images with srcset and sizes, through the theme’s image tag helper.
• Give images width and height, or use the helper that adds them, to prevent layout shift.
• Use separate mobile and desktop hero images with the picture element where the art direction differs, so only the right one downloads.

Also compress and size your uploads sensibly. A 6000-pixel photo displayed at 800 pixels wastes bandwidth even if the platform resizes it.

Step 3: Tame your Liquid code

If TTFB is high, the cause is often in your theme’s Liquid. Shopify’s documentation says loops nested across products, variants or options grow quadratically with catalogue size, and calls this the most common cause of high TTFB. Practical fixes:

• Avoid nested loops over products, variants and options. Restructure, or pre-filter the data.
• Move metafield access outside loops, and use theme settings for static data.
• Load only the variant data needed for the first render.
• Keep pagination under 25,000 objects, and use the loop limit when you only need the first few products in a collection.
• Assign repeated filter results to variables instead of recalculating them.
• Use the section index to apply different loading approaches above and below the fold.

Shopify notes that compounding small Liquid improvements can save roughly 25 to 50 milliseconds of TTFB on complex themes. Use the Theme Inspector to find the slow lines first, so you spend time where it counts.

Step 4: Audit your apps and scripts

Apps are the most common source of slowness we see. Each can add JavaScript, CSS, requests to external servers and layout changes. Shopify’s advice is direct: audit and remove anything that is not earning its performance cost, including apps, tracking pixels and theme code. A few practical steps:

1. List every app and every third-party script. Include pixels and chat widgets.
2. Find the worst offenders. Shopify points to the idea that about 20 percent of scripts cause 80 percent of problems, and suggests using Lighthouse’s treemap and DevTools coverage to find them.
3. Remove what you do not use. Uninstalling an app does not always remove its leftover code from the theme, so check the theme files and clean up.
4. Defer or delay non-critical scripts. Use defer for non-critical scripts, and async only for independent third-party scripts where order does not matter.
5. Identify render-blocking scripts, those that stop the browser from parsing HTML, and remove or defer them.
6. Remove anti-flicker snippets when no A/B test is running.
7. Be wary of “speed” apps. Shopify advises avoiding apps that cheat Lighthouse and PageSpeed tests instead of improving real performance.

Before you add any new app, ask what it loads, where and whether it is worth the cost.

Step 5: Render the essentials in HTML

Shopify recommends rendering essential content, such as product information, hero content and navigation, in Liquid and HTML, not with client-side JavaScript. When key content depends on a script, it appears later, and INP and LCP suffer. Also:

• Build the DOM for drawers, filters and dialogs only when first opened. Do not construct hidden interface elements at page load.
• Load modules on interaction. Use dynamic imports inside event listeners so code loads when someone actually uses a feature.
• Start data requests early, as soon as the script runs, instead of waiting for later events.

What to check on each page type

Different pages fail in different ways, so check them separately:

• Home page. Usually carries a hero image, a slider or video and several apps. Look for an eager-loaded hero, no autoplaying heavy media above the fold and few third-party scripts.
• Collection pages. Watch Liquid loops, product card images, filters and infinite scroll. Make sure card images are sized correctly and that only those below the fold are lazy-loaded.
• Product pages. Typically the heaviest: gallery, variant selectors, reviews, upsell and badge apps. Check the main image, the variant JavaScript and review widgets that inject content late.
• Cart. Check the cart drawer, shipping estimators and upsells, all of which add scripts and requests.
• Blog and content pages. Often forgotten. Check image sizes and embedded media.

Common culprits and quick wins

A Shopify speed checklist

• Baseline for LCP, INP, CLS and TTFB on mobile, for home, collection, product and cart pages.
• LCP image eager-loaded, high priority, sized and not animated in.
• Responsive images with width, height, srcset and sizes.
• Nested Liquid loops removed, metafields moved out of loops.
• App and script audit complete, unused apps and leftover code removed.
• Non-critical scripts deferred, render-blocking scripts fixed.
• Essential content rendered in HTML, with hidden UI built on demand.
• Fonts self-hosted or system fonts, with fallback adjustments.
• Space reserved for app-injected content.
• Preload limited to one or two resources.
• Theme Check run before each deployment.
• Monthly performance review scheduled.

Remember that speed work is never finished. New apps, campaigns, banners and content all add weight over time. Put the monthly check in a calendar, keep a simple log of changes and their effect, and give one person responsibility for it. Stores that do this stay fast; stores that treat speed as a one-time project drift back to slow within a year.

Frequently Asked Questions