Shopify Performance Audit: Why Your Store Is Still Slow

Basic optimization often compresses a few images, installs a speed app, or toggles lazy-load and then stops. The store can still feel slow because the largest element, a third-party script, or the theme’s own JavaScript is the actual wait. This guide is the audit. The broader playbook is how to speed up a Shopify store. The commercial starting point is the Shopify performance hub.

Signs a Shopify store needs a performance audit

• Product pages feel slow on a phone even after images were compressed.
• The homepage score looks acceptable and the product page does not.
• A speed app is installed and Core Web Vitals in Search Console are still poor or not enough data on the templates you care about.
• The store got slower after an app, a campaign pixel, or a redesign.
• Lighthouse and real use disagree, and nobody has checked a product URL.

What a performance audit checks

The audit starts on a money template: a high-traffic product page, then the homepage and a collection if they receive ads or email. It records the largest contentful paint, the scripts that run before that paint, and which apps, fonts, and tags are on the critical path. It does not start by chasing a perfect Lighthouse score on a page nobody visits.

Largest Contentful Paint

LCP is the largest visible element in the first view, often the product image or a hero. If the page prioritizes the wrong image, or waits on JavaScript before that image can paint, compression alone will not move the metric. Google’s Core Web Vitals documentation is the definition. On Shopify, the practical question is which file is the LCP element on the product template and whether the theme preloads it.

Image delivery and image sizing

• Serve the size the slot needs. A 3000-pixel file in a 600-pixel column still costs the phone.
• Use Shopify’s image CDN widths instead of uploading display-size files by hand for every crop.
• Do not lazy-load the LCP image. Lazy-load images below the fold.
• Hero and product media should be the first candidates, not the logo.

Third-party scripts, apps, and app embeds

Apps slow stores when their scripts run on every page, including pages where the app does nothing. Reviews, popups, subscriptions, fraud checks, and personalization are common. The question is not “how many apps” but which scripts execute before the product image paints. The companion guide is do Shopify apps slow down your store.

Fonts, analytics, and tracking tags

Custom fonts that block rendering, and analytics tags that all load immediately, create the same kind of wait as a heavy app. GA4, ads pixels, chat, and heatmaps need an owner. Tags required for consent can still be deferred or reduced. Measurement setup is covered in the Shopify GA4 guide.

Theme code

Theme cost shows up as large JavaScript bundles, render-blocking CSS, sections that loop huge collections, and leftover snippets from uninstalled apps. A speed app cannot delete that code. Someone has to read the theme.

Product pages versus the homepage

Homepages are often lighter and better cached in people’s anecdotes. Product pages carry variant media, recommendations, and app blocks. Audit the product template that ads land on. A good homepage score with a poor product score is a normal finding, not a contradiction.

How to prioritize fixes

1. Fix the LCP element on the highest-traffic product template.
2. Remove or delay scripts that run before that paint and are not required for it.
3. Then fonts, then below-the-fold media, then collection templates.
4. Re-test the same URL after each change so you know what moved.

Some fixes are settings: image preview widths, an app embed turned off on a template, a font swap. Others need theme code: preload the correct image, stop a script from loading in theme.liquid, or load an app only after purchase intent. If the change touches Liquid or a global script, it is developer work. Merchandising teams should not be left to guess.

A documented example: Tennis Express

On Tennis Express, the audit focused on shoe product pages. Lab checks showed a heavy JavaScript path, third-party app CPU time, an LCP observation near 10.7 seconds on a shoe PDP, and a homepage that prioritized a banner shoppers were not seeing. Analytics tags were part of that early load. Staging Lighthouse work moved a performance score from about 25 to about 35. That staging result is not a claim of a matching production gain. The useful lesson is the diagnosis: apps and scripts, not another image-compression pass. Read the Tennis Express case study.