What we keep seeing is this: Shopify teams often chase speed with isolated tricks, while the biggest wins are still sitting in plain view inside the theme, the app stack, and the first viewport.
Shopify’s own performance documentation frames the problem correctly. Storefront web performance is affected by your theme, installed apps, third-party code, images, and even how your collections are structured. Shopify also gives merchants a real-user performance view that compares a store’s Core Web Vitals to other stores in a similar sales-volume range (Shopify Help Center, Shopify Help Center).
Google’s thresholds are still the operating target: LCP 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less (web.dev, web.dev, web.dev). And web.dev’s 2025 Core Web Vitals data makes one thing especially clear for ecommerce teams: 42% of sites still miss the LCP threshold, 73% of mobile pages have an image as their LCP element, and only 15% of pages that could benefit are currently using fetchpriority for those images (web.dev).
So the answer is not “make Shopify faster” in the abstract. The answer is to fix the exact things that control the first meaningful render, the main-thread workload, and the stability of the layout on the templates that drive revenue.

What a real Shopify speed project should fix first
A good speed project is not a homepage-only exercise.
If the home page gets all the attention, merchants usually miss the places where Shopify performance problems do more commercial damage:
- collection pages with heavy merchandising sections
- product pages with gallery logic, reviews, recommendations, and app widgets
- search or predictive-search overlays
- campaign landing pages with oversized media and third-party scripts
This is also how Shopify evaluates storefront-app impact in practice. Shopify’s App Store documentation says Shopify measures performance impact across home (17%), product detail (40%), and collection (43%) templates when testing storefront apps (Shopify App Store best practices).
That weighting is useful even outside app reviews. It reflects where stores tend to earn or lose speed credibility in real journeys.
Start with the data Shopify already gives you
The most practical first move is to stop treating performance as a blind guessing exercise.
Shopify already gives merchants two useful sources:
- the store performance report in admin, which uses real-user data
- the theme and storefront development tools in Shopify.dev, including Theme Inspector
That matters because lab tests are still useful, but they do not replace field data. If your performance report says the store is lagging on product and collection pages, it is not enough to celebrate a single Lighthouse run on the homepage.
Before you change anything, define:
- which template is slowest in field data
- which metric is actually failing first
- which page elements are above the fold
- which apps or embeds are present on those templates
If you skip that step, you usually end up optimizing the wrong thing.
The 9 fixes that move Shopify Core Web Vitals most often
1. Find the slow template before you start deleting code
The first mistake is assuming the worst page is obvious.
Often it is not.
A collection page with a big hero, filter UI, badges, quick-add, and merchandising blocks can be slower than the home page. A product page with several app blocks can be much worse than either. Start with the templates that actually drive revenue and look at them individually.
This is also why our broader ecommerce tech stack audit checklist matters. Performance problems are often ownership problems in disguise.
2. Fix the LCP image before touching smaller details
web.dev’s Core Web Vitals dataset is blunt here: the LCP element is very often an image. On Shopify stores, that usually means:
- the hero image
- the featured collection image
- the first product image
- the main campaign banner
If that image is too large, rendered late, lazily loaded above the fold, or injected after other scripts finish, the whole page feels slow even if the rest is acceptable.
On Shopify, the practical priorities are:
- make the first viewport image discoverable in the initial HTML
- avoid lazy loading it
- use the right dimensions, not a huge original file
- preload it only when it is genuinely the above-the-fold hero
3. Stop lazy loading above-the-fold media
This one still appears on too many themes.
Shopify’s image_tag documentation says that if you do not apply preload, then loading is automatically set to lazy for images in sections further down the page. It also explicitly says you shouldn’t lazy load images above the fold (Shopify.dev).
That means merchants should not blindly add lazy loading everywhere in the name of performance. On Shopify, the wrong image getting lazy-loaded can directly delay LCP.
4. Reduce third-party app and script weight before rewriting theme code
Many slow Shopify stores do not primarily have a Liquid problem. They have a frontend payload problem.
That payload usually comes from:
- review widgets
- upsell tools
- popups
- analytics layers
- heatmaps
- chat tools
- A/B testing scripts
- loyalty widgets
The apps may all be individually defensible. The combined stack is where stores get into trouble.
If that sounds familiar, read this article together with our Shopify app bloat audit guide. The two problems often sit on the same pages.
5. Use Theme Inspector to find slow Liquid sections
Some speed problems live in the server-rendering path, not just the browser.
Shopify’s Theme Inspector exists for a reason. It helps you profile Liquid rendering so you can identify slow sections, loops, snippets, and data access patterns inside the theme (Shopify.dev).
This matters when:
- a collection template assembles too many section blocks
- a product page loops through media or variant logic inefficiently
- snippets are being re-rendered more often than necessary
- theme code is making expensive assumptions about the catalogue
If you only inspect DevTools waterfalls and never inspect Liquid rendering, you are only seeing part of the problem.
6. Simplify heavy hero sections, sliders, and storefront chrome
Shopify storefronts get slow in very ordinary ways:
- oversized hero banners
- autoplay sliders
- layered announcement bars
- animation-heavy sections
- multiple popups competing for first paint
The problem with these elements is not only their individual weight. It is that they often sit in the exact part of the page that influences LCP and visual stability most.
If the goal is better Core Web Vitals, decorative complexity at the top of the template is usually the first thing to challenge.
7. Reserve media space so the page does not jump
CLS is still one of the easiest metrics to worsen accidentally.
Shopify gives developers a good default here. The image_tag filter adds width and height attributes based on image dimensions and aspect ratio by default, which helps reserve space on the page (Shopify.dev).
That means merchants and developers should be suspicious of theme code that bypasses those defaults unnecessarily or injects media without reserved dimensions.
Common CLS offenders on Shopify include:
- banners inserted after load
- review widgets expanding late
- sticky bars entering without reserved space
- variant media that swaps dimensions unpredictably
8. Cut long main-thread tasks to improve INP
INP is where “the page looks loaded” stops being enough.
Google’s current INP guidance says the target is 200ms or less. On Shopify storefronts, poor INP usually comes from JavaScript that competes with the user’s first real interaction:
- opening variant selectors
- filtering a collection
- opening quick-add drawers
- interacting with predictive search
- dismissing popups
If the page has a lot of client-side logic, the browser may not respond quickly even when the visuals seem ready.
The practical fix is not “remove all JavaScript”. It is:
- reduce unnecessary script execution on initial load
- defer non-critical widgets
- challenge duplicate front-end jobs from apps
- simplify interaction-heavy components
9. Re-test after every theme or app change
Shopify speed does not stay fixed just because a team did one cleanup sprint.
Apps get added. Theme sections expand. Marketing wants one more popup. A campaign template ships with different media assumptions. Suddenly the store is slower again.
That is why performance rules need to survive after the audit:
- do not add an app without testing template impact
- recheck Core Web Vitals after theme changes
- review collection and product templates separately
- protect the first viewport from new script and media weight
If the process is not ongoing, the speed gains rarely last.
Where Shopify stores usually lose the most time
When you step back, the recurring pattern is simple.
Stores usually lose the most time in one of three places:
The first viewport
The wrong hero, the wrong loading strategy, the wrong section order, or too much decorative overhead.
The app layer
Too many storefront scripts fighting for the same template.
The template architecture
Too many blocks, too much conditional logic, or too much work happening before the page becomes usable.
This is why speed projects work better when they are tied to actual template ownership and page-type performance, not just an abstract “improve site speed” ticket.
EcomToolkit’s Take
Our view is simple: the fastest Shopify stores are usually not the ones using the most clever optimization hacks. They are the ones with the least chaos in the first viewport and the least unnecessary code on product and collection pages.
The weak pattern is when teams treat speed like a one-time technical cleanup and then keep adding widgets, scripts, and heavy sections with no performance guardrails. That almost always recreates the same problem a month later.
If you want the practical default, use this order:
- fix the slowest revenue-driving template
- fix the LCP image and above-the-fold media behaviour
- reduce script weight from apps and frontend widgets
- profile slow Liquid sections
- keep retesting after every storefront change
That sequence is not flashy, but it is the one that actually holds up.
Final checklist for Shopify speed optimization
- start with real-user data, not only a homepage Lighthouse run
- identify the slowest product or collection template first
- make the LCP image discoverable and properly sized
- never lazy load the true above-the-fold image
- challenge third-party scripts before rewriting theme code
- profile slow Liquid sections with Theme Inspector
- simplify heavy hero sections, popups, and sliders
- reserve media space to prevent layout shift
- reduce long main-thread tasks to improve INP
- re-test after every app install, theme release, or campaign launch
If you are going deeper on the same topic, the next useful reads are our Shopify app bloat audit guide, our article on Shopify image optimization for faster product and collection pages, and our earlier guide to best Shopify apps for lean stores.