Shopify page speed optimization that does not regress in six weeks

The standard advice is correct and insufficient: remove unused apps, compress your images, choose a lighter theme.

Teams do all three, post the Lighthouse screenshot, and six weeks later the score is back where it started. Not because the advice was wrong, but because nothing in the process prevented the next app install from undoing it.

Performance is not a project. It is a constraint, and constraints need enforcement.

Why Shopify stores regress specifically#

Three mechanisms, all of them normal business activity.

Apps inject scripts globally. Most Shopify apps add their JavaScript to every page whether or not the page uses the feature. A review widget needed on product pages loads on checkout and the blog too. Ten apps is ten global scripts, and the person who installed the tenth had no way to see what it cost.

Uninstalling does not always clean up. App scripts frequently survive in the theme after removal, particularly when they were added via theme edits rather than script tags. Stores routinely carry code for apps they stopped paying for.

Theme edits accumulate. Every small change ships without anyone measuring the delta, and the regressions are individually invisible and collectively fatal.

None of these are mistakes. They are what happens when there is no feedback loop.

Start by measuring the right thing#

Lighthouse in your browser is a lab test on your laptop on your connection. It is useful for diagnosis and useless as a target.

What matters is field data: Core Web Vitals from real visitors, which Google actually uses. Look at the 75th percentile, not the average, because the average hides the tail where your slowest 25% of customers live.

For a Shopify store, LCP on product and collection pages is the number that correlates with revenue. That is where the buying decisions happen.

The usual suspects, in order of payoff#

The hero image. On most themes the LCP element is the first product or banner image. It should be correctly sized for the viewport, in a modern format, preloaded, and never lazy loaded. Lazy loading the LCP element is the single most common self inflicted wound in Shopify performance, and it is a one line fix.

App scripts on pages that do not need them. Audit which apps inject globally and restrict them by template where the app allows it. Where it does not, decide whether the feature is worth its cost on every page.

Third party tags. Analytics, chat, pixels, A/B testing. Each one was added by someone with a good reason and nobody has ever removed one. Review the list quarterly and load what remains asynchronously.

Fonts. Self host, subset to the characters you use, and preload the one that renders above the fold. Font loading is a frequent cause of layout shift, which is a separate Core Web Vital people forget to look at.

Theme JavaScript. Most themes ship features you do not use. Removing dead code is real work with real payoff, and it is the item most likely to be skipped.

Then set the budget, which is the part that lasts#

Everything above is a project. This is the mechanism.

Pick two thresholds and enforce them automatically on every change:

• Total JavaScript shipped on the critical templates, measured in KB.
• LCP on product and collection pages, measured in a controlled lab run.

Wire them into your deployment process so that a change exceeding either one fails the build. Not a warning in a report nobody opens. A failure that stops the deploy.

That is the only version of a performance budget that survives a year. It converts performance from something a person has to remember into something the system will not let you forget. On the CMS builds we ship, the stated targets are under 1.2 seconds LCP and a median Lighthouse of 98, and they hold because exceeding them is not possible without someone deliberately raising the threshold.

The discipline generalises. It is the same reason a redirect map gets tested with assertions rather than spot checks: a rule a human has to remember is a rule that gets forgotten on a busy week.

Give app installs an owner#

The technical control needs a process control beside it, and it is a small one.

Installing an app should require someone to check the budget afterwards. If the store is over, either the app goes or something else does. That is a two minute conversation when the rule exists and a six month argument when it does not.

What good looks like#

Under 1.5 seconds LCP at the 75th percentile on product pages, JavaScript on the critical path measured in tens of kilobytes rather than hundreds, and a build that refuses to ship a regression.

If the store is being rebuilt or replatformed rather than tuned, the budget belongs in the new build from the first commit, alongside the redirect map that protects the rankings you already have. Retrofitting a budget onto a store that has drifted for two years is a harder project than starting with one.

Frequently asked questions#

How many Shopify apps is too many?#

There is no count. What matters is how much JavaScript they add to your critical templates. One badly behaved app can outweigh eight lightweight ones, so measure the payload rather than the list length.

Why did my Shopify speed score drop after we fixed it?#

Almost always an app install or a theme edit that shipped without anyone measuring the delta. Without a budget enforced in the build, there is nothing to catch it, and each regression is individually invisible.

Does page speed actually affect Shopify sales?#

It affects rankings directly through Core Web Vitals, and it affects conversion on mobile where slow product pages are abandoned before they render. Measure LCP on product and collection pages at the 75th percentile, because that is where buying decisions happen.

Should I switch to a headless Shopify build for speed?#

Only if the storefront genuinely needs it. Headless removes the theme constraint and adds real engineering cost and ongoing maintenance. Most stores reach good numbers on a well built theme with a budget enforced, and that is a far cheaper place to arrive.