Why your store’s speed drops even when “nothing changed”
The feeling that you haven’t touched the site is almost always wrong. What doesn’t feel like a “site change” (installing an app, a new ad pixel, a review widget) is, from the browser’s point of view, exactly what’s slowing it down.
Apps add up and nobody’s watching
According to Hyperspeed (2026), the average Shopify store today runs on nearly 6 detectable frontend apps (median 4), with an enormous spread: from a single app to 25 on one store. The link to speed is direct: stores with 1-2 apps average a PageSpeed score of 53.2, 3-5 apps 49.8, 6-10 apps 45.2, and 16+ apps just 38.3, a drop of roughly 15 points between a lean store and an overloaded one.
Third-party scripts, meanwhile, account for an average of 44% of total page load time according to Shopify (2026, 2025 data). Nearly half of what a customer waits for isn’t your content, it’s someone else’s code.
- When an app is worth it: it solves a real business problem (e.g. checkout conversion), has measurable revenue impact, and only loads where it’s needed.
- When it isn’t: you installed it “to try out” six months ago and stopped using it, it duplicates another app, or it loads on every page when you only need it on one.
Images and theme bloat nobody notices
Apps aren’t the only culprit. Unoptimised product photos, extra sections bolted onto the theme (another banner, another carousel, another “recommended products” block), and custom code nobody cleans up afterwards, all behave the same way: negligible on their own, heavy together.
Scripts that run even when nobody’s using them
The heaviest app categories today are session recording (user behaviour capture), live chat widgets, upsell engines, and analytics tools. All of them fire JavaScript on every page load regardless of whether the customer ever interacts with them, and that blocks the browser’s main thread.
This is precisely the most common complaint on the Shopify community forum (2026): store owners describe being caught between two needs: they need the apps to run the business, but stacking them up is what kills the site. As one more experienced merchant put it in a thread, the apps themselves aren’t the problem. The accumulation of their scripts is what actually slows the site down.
How to find out what’s actually slowing your store, instead of guessing
Before you start uninstalling apps at random, it’s worth verifying it with measurement, not a hunch.
The quick app test
The simplest way to find the culprit is to temporarily disable apps (one at a time, or in groups) and re-measure speed after each change. The app whose removal boosts the score the most is very likely your main problem. It takes time, but it’s more reliable than guessing from an app’s name.
What Lighthouse shows you and what it doesn’t
A Lighthouse score is a lab test: it measures one specific page load under standardised conditions. What it won’t show you is how your actual visitors experience the site on their own phones and connections. That’s what field data is for (real user data, CrUX), and it’s field data that determines how Core Web Vitals actually scores you.
Core Web Vitals in 2026: the numbers you’re judged by today
Core Web Vitals are three metrics Google (and increasingly AI search tools) use to judge how a page actually “feels” to a user.
LCP, INP, CLS: current thresholds
According to CoreWebVitals.io (2026), these are the current threshold values:
- LCP (Largest Contentful Paint): how fast the largest visible element renders. Good: under 2.5s. Needs improvement: 2.5-4s. Poor: over 4s.
- INP (Interaction to Next Paint): how fast the page responds to a click or tap. Good: under 200ms. Needs improvement: 200-500ms. Poor: over 500ms.
- CLS (Cumulative Layout Shift): how much content “shifts” while loading. Good: under 0.1. Needs improvement: 0.1-0.25. Poor: over 0.25.
For a page to “pass” Core Web Vitals, at least 75% of your visitors need a good score across all three metrics at once, measured at the 75th percentile of real data.
Why it’s worse on mobile
According to the 2025 Web Almanac, only 48% of mobile sites meet good Core Web Vitals, versus 56% of desktop sites. For LCP alone the gap is even sharper: 62% of mobile pages score well versus 74% of desktop, and poor LCP shows up almost twice as often on mobile (13% vs. 7%). So if most of your customers shop from a phone, apps and scripts hit them harder than they hit desktop.
Why speed is measured in revenue, not just technical hygiene
Site hygiene is one thing, but the numbers are blunt about what happens to revenue:
- According to a 2026 Shopify analysis, every 100ms of extra load time costs roughly 3.5% in conversion.
- Speeding up mobile load time by 1 second, conversely, increases conversions by an average of 3% (Yottaa, 2025).
- Pages that take 4 seconds or more to load see a 22% lower conversion rate than faster pages.
- According to Conviva (2025), one in four customers abandons a purchase if it doesn’t complete within 10 seconds.
- Contentsquare (2025) found that slow content drove 53% of users to leave after the first page.
- In Clutch research, 48% of people wait no more than 10 seconds for a page to load, and 44% read slow loading as a signal the store isn’t trustworthy.
- Pages over 4 seconds have a 17-percentage-point higher bounce rate (63%) than faster ones.
- Underperforming apps reduce conversion by an average of 0.29 percentage points per app, a number that compounds with every app you add.
How many apps is “too many” apps
There’s no universal number, but you can spot where the apps-vs-speed trade-off breaks down:
- Yes, add the app: it solves a specific, measurable problem (e.g. abandoned cart, reviews on high-turnover products) and replaces an app you’d otherwise need two of.
- Yes, keep it: even after testing (app off, then measure), the score doesn’t change, but the app drives revenue.
- Consider removing it: you last opened it months ago, it duplicates another app, or it loads on every page when you only need it on one (e.g. checkout).
- Definitely remove it: after uninstalling, a “dead” script the app left behind is still sitting in your theme’s code, still slowing the site down even though the app hasn’t run in ages.
The AI-first view: monitoring instead of a one-off audit
The classic approach is to call an agency once every six months for a “speed audit”, get a PDF of recommendations, and three months later be right back where you started, because two more apps got installed in the meantime and nobody noticed.
Why a one-off audit isn’t enough
An audit is a snapshot in time. But apps get installed and removed continuously, marketing adds pixels, seasonal campaigns add extra widgets: store speed is a moving target, not a problem you solve once.
What continuous AI monitoring looks like in practice
Instead of waiting for the next six-month audit, it makes more sense to have continuous monitoring. Something that watches Core Web Vitals around the clock, not just on the day someone remembers to run a test, and automatically links a speed drop to a specific change: an app install, a theme update, a new pixel. It flags the drop before your customers notice, meaning before the slowdown has a chance to cost you revenue. And ideally it estimates the impact on conversions before you uninstall an app and find out the hard way, after the fact.
“We check once in a while whether the site is fast” versus “we know instantly when an app or an update breaks something”: that’s why it’s worth treating speed as an ongoing service, not a one-off project.
What to do now
- Run a Lighthouse test on your key pages (homepage, product, cart) and record the current score as a baseline.
- List every app you have: when you installed it, and when you last actually used it.
- Uninstall apps you don’t use and check whether they left code behind in your theme.
- For apps you’re keeping, test speed before and after temporarily disabling them.
- Set up regular Core Web Vitals monitoring instead of relying on noticing a drop yourself.
It sounds like extra work. It is, but it’s still less work than figuring out every month why revenue dropped again and nobody knows why.
Frequently asked questions about Shopify store speed
Why does my Lighthouse score keep dropping when I “haven’t changed” the site?
Most often it’s an app, pixel, or widget you added without thinking of it as a “site change”. From the browser’s point of view, it’s just another script that has to download and run, and it affects the score the same way a theme edit would.
How many apps is still fine on a Shopify store?
There’s no fixed number, but data shows a noticeable speed drop already between 3 and 5 apps compared to 1-2. What matters more is how many scripts your apps load on each page, not the bare app count.
Does site speed really affect revenue, or is it mainly an SEO question?
Both. Google uses speed as one ranking factor, but the revenue impact is more direct: 2026 data shows every 100ms of extra load time costs roughly 3.5% in conversion, and pages over 4 seconds see a 22% lower conversion rate.
How do I find out which specific app is slowing my store down?
The most reliable way is to disable apps one at a time and re-measure speed after each change. The app whose removal boosts the score the most is the prime suspect.
Is Shopify as a platform slower than other options?
The platform itself isn’t the main cause of a slow store: theme, apps, and custom code have a far bigger impact on the final score than the choice of Shopify itself.
Is a yearly speed audit enough?
A one-off audit shows you the state at a single moment, but apps and marketing scripts change continuously. Without regular monitoring, a speed drop usually only surfaces once it’s already dented revenue.
