Shopify Speed Optimization: A Real Playbook

Your Shopify homepage achieves a score of 95 in Lighthouse. Your product page fails to close the sale. Treating Shopify speed optimization as a score project is the primary issue that leads to this disconnect. Real customers arrive at product URLs from Google Shopping, paid social, or email. Each of these pages has distinct images, apps, review widgets, and marketing scripts that do not appear on the homepage that they never visit. The score indicates that the homepage is optimized. Meanwhile, your revenue is lost on the money page.

In addition to Lighthouse, Shopify has begun to report real-user data for Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) for the 75th percentile of visits. The good-experience targets for LCP are set to 2.5 seconds, for INP to 200 ms, and for CLS to 0.1, as described in Shopify’s Web Performance Reports. These numbers reflect what your customers experience.

This guide is for merchants and operators who want a more defined hierarchical plan of action. Begin with the profit-generating pages. Use field data before lab data. Address the app and image problems that contribute the most before undertaking a rebuild.

Why Your Homepage Score Is Lying to You

Lighthouse performs a single sample under a controlled condition. This sample does not reflect every template, device, network, or app state your customers encounter. The product page almost always has a gallery, variant picker, reviews and recommendations, recommender logic, sticky add-to-cart functionality, and the last quarter’s growth team marketing scripts. The homepage rarely has all of this present.

The homepage also loads quicker, likely due to a warmer cache and simplified layout. A product page hits a more complex request chain, so the store looks fast in a lab and feels slow in a taxi.

Practical rule: Start with the slowest money-making page and not the prettiest page in the performance test.

Measure the pages shoppers actually use

Shopify’s admin now breaks performance by page type and URL. Use that before you consider opening the code editor. Check the home, collection, product, and cart pages. Don’t consider the storefront as a single blob.

• Product pages: The revenue templates. Ads, search, and social usually land here.
• Collection pages: Slow filtering, heavy grids, and app widgets can quietly kill browsing.
• Cart pages: Drawers, recommendations, shipping tools, and tracking pixels stack up right before checkout.
• Campaign templates: A one-off landing page can carry an entirely different script load than your standard templates.

The most common issue encountered in the wild is not a bug in the platform. It is third-party apps that load globally even though the functionality only needs to run on a single template. Presidio’s guide on how to remove third-party app bloat can serve as a good reference for that kind of audit.

Measuring Speed the Way Google and Shopify Do

You need both field data and lab data because they answer different questions. Field data tells you the experience of real shoppers from last week. Lab data tells you the reasons a particular URL is slow and how to fix it. If you rely on lab data only, you optimize for a robot. If you rely on field data only, you cannot debug.

According to Shopify, values pertain to the 75th percentile (p75) where the performance metric is better or equal to the reported value for 75% of visits. LCP is the time it takes for the main content of the page to load. INP is the time it takes to respond to actions performed during the visit. CLS is a measurement of how much the design of a page shifts during loading. Shopify opted to use INP instead of FID (First Input Delay) because capturing the time of the first user input during a session is a poor indication of how users perceive the rest of the session.

Google Chrome User Experience Report (CrUX) allows you to retrieve real-world origin-level data measuring user experience from actual Chrome users. The page-type reporting from Shopify is better suited to prioritization for CMS templating since it indicates which page needs to be opened first.

Give each tool one job

• Shopify Web Performance Reports: Rank fixes by page type and revenue.
• CrUX: Sanity-check real-user performance for the origin.
• PageSpeed Insights and Lighthouse: Debug a specific product, collection, or cart URL.
• RUM tools like SpeedCurve, Treo, or DebugBear: Catch regressions after releases and app installs.

For mobile testing, throttle CPU and simulate a 3G network, and not just an emulated wifi connection. Long JavaScript tasks commonly performed by mid-range mobile devices will be masked by a clean desktop run.

Tool	Data Type	Granularity	Best For
Shopify Web Performance Reports	Field	Page type and URL	Prioritizing revenue templates
CrUX	Field	Origin level	Storefront-wide health
Lighthouse	Lab	Individual URL	Debugging specific pages
PageSpeed Insights	Lab plus field where available	URL and origin	Combining diagnosis with user data
SpeedCurve, Treo, DebugBear	Field and lab	Template and release	Monitoring regressions

The outputs should be brief: a ranked list of 2 – 3 revenue templates that do not meet the p75 metrics, and a list of scripts, apps, or images that appear to be the offending party. Shopify’s own web performance improvement guide provides more insightful information on the topics of requests, caching, and lazy loading.

The Five Usual Suspects Behind a Slow Store

Slow Shopify stores rarely have a single large cause. Instead, they have many smaller causes. Amongst other things, practitioner discussions on X in recent years mentioned two common causes: oversized images and app overload. The direction of travel was confirmed by Shopify’s platform team in August of 2023, when they rolled out automatic Early Hints. Early Hints lead to an improvement of 76 ms on First Contentful Paint and 100 ms on LCP, respectively, with zero merchant effort. Therefore, the biggest issues that remain for you are the ones Shopify cannot address from their side – the media you upload and the apps you use.

Start with the expensive work

When a page looks visually complete, but feels laggy, third-party apps and marketing scripts should be your first priority. Many of these apps, including reviews, chat, upsells, analytics, loyalty, and personalization, usually load JavaScript on every template when, in reality, these features are only visible on one. This competes for network requests and blocks the main thread, which is what breaks INP. Shopify advises on web application performance to minimize requests, defer non-critical work and cache aggressively.

The theme will be your next focus. Unused sections, global CSS, large JavaScript bundles, and render-blocking assets affect every template, including the product page. A new theme will not fix this issue if the same app stack continues to inject the same scripts.

Images still matter when a product’s primary image is the LCP element. The failing pattern is almost always a 5 MB original image that is uploaded by the merchant and bypasses optimization built into Shopify. The solution can’t be to “compress all images.” Instead, make sure the browser gets the correct image at the correct size with the correct priority based on the requesting device.

Fonts and CSS can delay text rendering and cause visible shifts. Reckless use of multiple font families, excessive weights, and last-minute font file loads earn a spotlight too.

Cart and checkout extensions may be less obvious sources of trouble. Tracking pixels, custom shipping widgets, upsell offers, and completely replaced cart solutions all add burden at the exact moment the user is trying to complete an order.

Suspect	Field-Data Symptom	First Check
Apps and scripts	High INP, long interaction delays	Network panel and long tasks
Theme and Liquid	Slow rendering across templates	Rendered HTML, CSS, template assets
Product imagery	Poor LCP on product or collection pages	LCP element and image request
Fonts and CSS	Late text render, layout movement	Render-blocking requests and font swap
Cart and checkout extensions	Lag during cart interaction	Cart waterfall and extension requests

Poor responsiveness of field data nearly always points to an app rather than the theme. Poor LCP for product pages almost always points to the hero image or other page-specific assets. High CLS points to missing image dimensions and other injected content.

Prioritized Fixes You Can Ship This Week

When addressing page performance issues, don’t jump to the easiest fix. Instead, address the change that is most likely to have an impact on revenue generation.

Open Chrome DevTools and filter the Network panel by third-party domains. Take note of the unwarranted requests. Then remove unused applications from the Shopify admin. Check the theme for leftover snippets, app embeds, and script tags. This is the most common beginner-level optimization, and where speed freelancers tend to break things the most. Public Stack Overflow posts detail syntax errors in Shopify themes caused by freelancers adding speed optimization scripts and not fully cleaning their work. When in doubt, code review before going live.

For non-critical scripts, use the defer attribute where supported:

<script src=”{{ ‘marketing.js’ | asset_url }}” defer></script>

Load feature code only on the template where it is required:

{% if template.name == ‘product’ %}<script src=”{{ ‘product.js’ | asset_url }}” defer></script>{% endif %}

Do not use defer on scripts that support the most important UI interaction (add to cart, variant selection, etc.). This creates a fast page that the user cannot buy from.

Fix image priority and layout stability

Lazy-loading should not be done on the image that appears above the fold. Everything else can be lazy-loaded.

{{ product.featured_image | image_url: width: 900 | image_tag: loading: ‘lazy’, widths: ‘360, 540, 720, 900’, sizes: ‘(max-width: 768px) 100vw, 50vw’, alt: product.featured_image.alt }}

The main product image requires an eager load and fetch priority hint, as well as reserved dimensions to avoid layout shift.

<img src=”{{ product.featured_image | image_url: width: 1200 }}” width=”{{ product.featured_image.width }}” height=”{{ product.featured_image.height }}” alt=”{{ product.featured_image.alt | escape }}” loading=”eager” fetchpriority=”high”>

Lazy loading does not solve image weight, as shown on Stack Overflow by many practitioner questions. Even if lazy loading is added, PageSpeed will still flag oversized images because the byte weight remains the same. Along with lazy loading, you need to have proper dimensions, modern formats, and compression.

Liquid loops should be audited, especially ones that appear on every page. CSS should be page-specific when possible. Instead of shipping whatever the theme vendor left in place, use a build tool like esbuild or Rollup to compress theme JavaScript. More information on theme-level cleanup can be found in our guide to Shopify theme customization.

If an app, which you cannot delete, is the cause of the bloat, it is better to replace it with a custom-built feature that will be more cost-effective than purchasing a “speed” app in which more scripts will be added. This tradeoff should be considered before an app is installed. More information on this tradeoff can be found in our guide to Shopify app development.

Fix	Typical Gain	Effort
Remove unused apps and leftover snippets	Often meaningful	Low to medium
Defer non-critical scripts	Improves responsiveness	Medium
Correct LCP image sizing and priority	Improves product-page LCP	Low
Reserve space for media and widgets	Reduces CLS	Low
Split page-specific CSS and JavaScript	Reduces unused work	Medium

Warning: An individual change to Lighthouse is not enough to warrant a conclusion. Test the URL again on the same device and network types, then check on field data a week later. Self-reported leaps in Lighthouse posted to social media (e.g. “Mobile from 56 to 96”) make for nice screenshots, but make for poor evidence, as they lack the methodology and the real-user metrics.

SSR, Headless, and Shopify Plus Trade-offs

Most Shopify stores should remain on server-rendered Liquid. Shopify’s edge delivers cacheable HTML well, and a clean theme resolves more issues than a new architecture. Headless is a true response to a specific need, not a general improvement.

This assertion is reinforced by the data Shopify captured on Core Web Vitals in 2023. Traditional Liquid storefronts exceeded all three Web Vitals metrics about 59.5% of the time. Hydrogen reached 35%. Other headless frameworks dropped to about 28%. With a well-developed custom frontend, the ceiling is dramatically higher, but with average headless builds, the floor is seriously lower. If the theme is slow, considering headless is addressing the wrong issue.

The benefits of headless become apparent when complex personalization or a unique buying experience is not achievable with the Liquid architecture, or when a frontend needs to be customized or is being constantly tested. It adds a new build pipeline along with a new hosting, deployment, and performance monitoring infrastructure. Shopify Plus expands the options for the checkout and B2B experience, but will not magically improve a slow theme.

Make the architecture decision from evidence

Prior to accepting any proposal, do the diagnostics. Field data should come first. Then decide whether Liquid, apps, images, or scripts cause the delay. A good partner for a headless engagement should start there, not with a framework preference. The recommendations in vetting a headless implementation partner from Bridge Global, and Shopify headless commerce, provide context for the discussion and the band of GMV where the numbers actually matter.

This recommendation is correct and rather unexciting. Prioritize fixing theme, media, and app issues. Move to headless when you must because of other constraints.

What This Looks Like in Practice

When we worked with Broya Living, the brief was framed around improving conversion. For them, traffic was not a problem, the conversion pathway was. Shopper speed was one problem, but the better solution was knowing where shoppers were leaving the site and what work we were doing that we could remove from those pages. There were subscription products, variety packs, and a cart drawer that was built to manage recurring orders, all on templates that were doing things that they didn’t need to. We removed that work and rebuilt the product and cart flows based on shopper behavior. This resulted in an increase in conversion that has continued to rise during our five-year relationship. For most similar cases, revenue template data is a better place to start than trying to improve page scores.

Testing Checklist and Troubleshooting After Launch

Performance work on a theme does not end with a launch. New apps, a marketing campaign or a theme edit may change the request waterfall without anyone noticing during routine browsing.

• Test the revenue templates: Mobile Lighthouse on product, collection, and cart pages under throttled network conditions.
• Check field data on a schedule: Shopify’s reporting and Search Console Core Web Vitals, not only on launch day.
• Monitor releases: SpeedCurve, Treo, or DebugBear to catch regressions.
• Record changes: Tag each deployment with a short note about what changed.
• Keep rollback ready: Know how to restore the last good theme, disable an offending app, and re-measure.

Three failures show up repeatedly

An app can add a new script after installation. A previously installed script may return after a theme update from a vendor. A marketing campaign can result in a landing page deployment that carries more weight than any standard template. Instead of presuming the last good state of the configuration holds true after a modification, compare the Network panel and the theme files after the change. Our guide to continuous performance testing explains how to make this a repeatable release process, rather than a burdensome one-off audit.

When to Bring in a Partner and What to Ask For

A large Liquid refactor, repeated app conflicts, or an architectural change your team cannot own should warrant bringing in a development partner. Start with a fixed-price audit, instead of an open-ended rebuild. The $10,000+ estimates that circulate in the Shopify speed market are anchored to full engagements, not diagnostics. A focused audit should cost less and should tell you whether the bigger engagement is necessary.

Request an audit that provides measured baselines of product, collection, and cart templates. The audit should identify LCP, INP, and CLS metric violations, provide the name and script of the offending assets, and provide an implementation order. Request case studies that provide field data, and not just Lighthouse. Confirm the partner will eliminate excess scripts, apps, and code, implement monitoring prior to release, and facilitate rollbacks after release.

Tier	Scope	Deliverable	Budget
Focused audit	Field and lab review of priority templates	Baseline, findings, and action plan	$2,500 to $8,000
Theme optimization	Liquid, assets, scripts, template work	Implemented fixes and validation	$10,000 to $40,000
Headless migration	New frontend and delivery architecture	Migration, testing, and launch support	$50,000+

This article provides a deeper selection process for the recruitment of development partners for Shopify store services. It includes the real partner selection questions that differentiate a real partner from a nice PowerPoint rebuild.

---

Nothing on this page is a one-time project. Shopify will continue to ship platform improvements, and your app stack, campaigns, and theme will continue to lose alignment with what you tuned them to last quarter. Consistency beats intensity. The store that checks their revenue templates each month is the fastest. If you have to decide whether the next step is a focused audit, a theme cleanup, or something bigger, that early decision is part of what Refact’s Shopify practice is designed to answer before any code is written.