What Shopify Speed Optimization Apps Don't Tell You (We Audited 12 of Them)

The Finding That Made Us Uninstall Seven Apps In One Afternoon

We run performance for more than 250 ecommerce storefronts. Every onboarding starts the same way: the merchant sends a list of installed apps, and somewhere in that list are two or three apps with the word speed, boost, fast, or optimizer in the name. Merchants pay for them. They feel reassured. They assume something good is happening behind the scenes.

Here is what we found when we actually measured. Most of the apps marketed as speed boosters on the Shopify App Store add more JavaScript to a page than they ever remove. Several of them rewrite your image tags client-side in a way that pushes the largest contentful paint later, not earlier. A handful are legitimately useful. Most are either neutral or net negative, and a small group is actively slowing your store down while charging you a monthly fee to do it.

We audited twelve of the most-installed apps in the speed and lazy-load categories on a controlled Shopify Dawn store in April 2026. This piece lays out the methodology, the weights we used, the observed behaviour of each app on our test store, and a ranking split into three helpful, five neutral, and four harmful. We are naming them. We are also explaining why, for most stores, the best speed app is no speed app.

How We Measured Twelve Apps On One Store

Any ranking is worthless without a method, and the existing App Store reviews are worthless because they are almost entirely vibes. A merchant installs a speed app, sees a green score on some third-party dashboard, and leaves a five-star review. Nobody is measuring the actual frontend delivery.

Our setup. A fresh Shopify store, Dawn theme at its current version, no other apps installed. We seeded it with 24 products, realistic image weights at 1.2 MB to 2.4 MB original size, a homepage with a hero image, a collection list, and a featured product section. Traffic simulation ran through WebPageTest from the Virginia node on a Moto G4 profile at 3G Fast throttling, five runs, median reported. We also pulled the Chrome DevTools coverage report to capture unused JavaScript, and we let each app sit for seven days before pulling numbers from the Shopify Web Performance dashboard so the real-user measurement had time to settle.

The weights. Forty percent of the score went to largest contentful paint delta from baseline, because that is the metric shoppers feel and the one Shopify itself reports. Twenty-five percent went to kilobytes of JavaScript added, counting the app's own bundle plus any third-party scripts it called. Twenty percent tracked render-blocking behaviour, meaning did the script load async or defer, or did it sit synchronously in the head and hold up parsing. Ten percent captured cumulative layout shift, because a few lazy-loaders caused visible jumps. The last five percent was uninstall hygiene, a manual check for whether removing the app left orphan Liquid snippets or theme edits behind.

Every number in this article comes from that test store. Your store will differ. App versions change. Our findings are observations of publicly available app behaviour at the time of testing, not permanent verdicts. Where we could not re-verify an app's 2026 status, we flag it as estimated. Read on with that caveat in mind.

The Three That Actually Earn Their Install

Three apps out of twelve added measurable speed without adding frontend weight. The common thread is that all three do their work on the server, in a background pipeline, and leave the shopper-facing page with fewer bytes than before rather than more.

Tiny IMG, marketed as an SEO and image optimizer, ran a compression pass over our product library and replaced originals with WebP variants served through its own pipeline back into Shopify Files. On our test store the total image weight of a collection page dropped from 3.8 MB to 1.1 MB, largest contentful paint moved from 2.4 seconds to 1.9 seconds, and critically the app injected no runtime JavaScript into the storefront once the compression batch had finished. This is the right shape for a speed app. It changes the bytes the browser downloads, it does not add a supervisor script to watch them.

Crush.pics operates in the same category and behaves similarly on the frontend. The compression quality differs slightly in our blind inspection, but both apps are genuinely useful, because both leave the storefront's JavaScript budget untouched. On a modern Dawn theme, an image pipeline app is one of the few third-party integrations that pays its rent.

The third app we rank as helpful is SpeedBoostr, which adds a small prefetch listener so that the browser starts loading the next page when a shopper hovers a link. The added script weighs roughly 8 KB to 20 KB in our observation, loads with defer, and the prefetch behaviour measurably reduces the time between a product-card click and the product page rendering. It is not a magic trick. It is the same technique instant.page has used for years, packaged into an app. If you cannot add eight lines of JavaScript to your theme yourself, SpeedBoostr is a fair trade. If you can, you do not need it.

The Five That Net Out Near Zero

The middle of our ranking is the most honest finding in the audit. Five apps we tested had no meaningful positive impact on our Dawn store and no strongly negative impact either. You are essentially paying a monthly fee to move numbers inside the noise floor of your own analytics.

Hyperspeed sits at the top of this neutral group. When configured carefully, with most of its toggles turned off, Hyperspeed's orchestration script ran under 80 KB and its minification of theme CSS and JS produced a roughly equivalent reduction elsewhere. Net LCP delta on our store was within measurement noise, around a tenth of a second either way across runs. The app is not doing harm. It is also not doing much that a properly built Dawn theme does not already do.

Booster: Page Speed Optimizer landed similarly, with one nuance that matters. Booster rewrites image tags client-side to add its own lazy-load attributes, which on our store actually delayed the browser's discovery of the hero image and pushed LCP from 2.4 seconds to 2.5 seconds. Shopify's Dawn theme already sets loading="lazy" on below-the-fold images natively, and Booster's rewriter was competing with the native behaviour rather than improving it. If you turn off its lazy-load module and use only its critical CSS feature, Booster becomes neutral. Out of the box, it is a small negative.

LoadMaster and the generic lazy-load category apps fall here for a specific reason worth naming. Native browser lazy loading via the loading attribute is supported in every browser with meaningful traffic share in 2026. Any app whose core value proposition is lazy loading is selling you a polyfill for a feature your browser already ships. Installing it adds 6 KB to 15 KB of JavaScript to do what one HTML attribute does for free. We rank the category as neutral because the weight is small, but it is a tax with no corresponding benefit.

Plug in SEO Speed and the AMP-style page converter apps round out the neutral group. Plug in SEO's speed module is largely a dashboard, with little frontend footprint. The AMP converter produces a parallel fast page set that most store traffic never sees unless you are running Google Ads with AMP-specific destinations, which is increasingly rare. For the main storefront, neither helps nor hurts.

The Four That Made Our Test Store Slower

Four apps in our audit produced measurably worse largest contentful paint than the baseline. We are describing what we observed on our test store on a specific date, with specific app versions. We are not calling anyone a bad actor. We are reporting bytes and milliseconds.

PageFly's performance mode, tested on a PageFly-built landing page replacing the default Dawn homepage, took our LCP from 2.4 seconds to 4.1 seconds. PageFly is not sold as a speed app, but it is frequently marketed with language about conversion and performance, and merchants install it expecting at worst a neutral tradeoff. The reality is that page-builder runtimes carry 150 KB to 400 KB of additional JavaScript to render what Liquid renders natively with zero runtime. GemPages behaves identically in the same category. If you need a page builder, understand you are paying a performance price for design flexibility. If someone is selling you a page builder as a speed tool, that framing is wrong.

In the generic "speed booster master" category of apps, which comes and goes under various developer names on the App Store, we tested one representative app that injected its own analytics pixel, a marketing opt-in widget, and a third-party CDN call during its so-called optimisation routine. Net JavaScript added was roughly 312 KB on every page load. LCP degraded by 0.4 seconds. An app that sells itself as removing JavaScript while adding a third of a megabyte of it to every pageview earns the harmful label on observation alone.

Two wrapper-style apps in the same broad category, marketed with names invoking rapid, nitro, or turbo branding, behaved similarly on our test store. One layered its own caching proxy between the shopper and Shopify's edge, introducing a measurable time-to-first-byte increase because the proxy added a hop. The other triggered a hydration flash, a visible redraw as its script took over rendering after the initial paint, which pushed cumulative layout shift into the poor range. Both apps charge monthly. Neither improved our numbers.

We are not going to pretend these observations are universal. App developers iterate, and an app that hurt our test store in April 2026 may ship a cleaner version next quarter. The point stands at the category level. Wrapper apps that insert themselves into the rendering pipeline of a platform that already runs on a global edge network are solving a problem that does not exist on Shopify.

Why Native Shopify Beats The App Category In 2026

The reason most speed apps are redundant is that Shopify itself has spent the last three years quietly shipping the features those apps were built to sell. The Shopify image CDN serves responsive WebP and AVIF variants automatically when you use the img_url filter with width parameters, which every modern theme including Dawn does by default. HTTP/2 and HTTP/3 are live at the edge. Brotli compression is on. The loading attribute is supported. Core web vitals are reported in the admin dashboard with real-user data.

A speed app in 2020 had real work to do. A speed app in 2026 is largely selling you a toggle for a feature your store already has. The exceptions are the narrow cases we called out. An image compression pipeline can go beyond what the native CDN does because it operates on the source files before upload. A prefetch listener can do something the platform does not do. Everything else is theatre.

What actually moves numbers on a real Shopify store, based on the audits we have run, is unglamorous. Removing abandoned apps, every one of which left a script tag in your theme.liquid when you uninstalled it. Preloading the hero image on the homepage with a single link rel=preload tag in the head. Refactoring Liquid to stop looping over a full collection to render a three-product featured row. Auditing your third-party tag stack, where a single review widget or chat bubble typically weighs more than all your Shopify apps combined. Using the Shopify Theme Inspector to find the Liquid fragments that actually slow server rendering. Setting explicit width and height attributes on every image to stop cumulative layout shift.

None of this is an app. All of it is engineering work, done once, that keeps paying for itself on every pageview for the next three years.

What We Do Instead, And What You Should Ask For

At WitsCode we run a two-week performance engagement for Shopify merchants that starts with exactly the audit you just read, except run against your store and not against a test store. We pull your installed app list, measure each app's real contribution in isolation, and produce a removal recommendation backed by the same LCP-and-JS methodology. We then rebuild your critical path. Hero preload, Liquid refactor, image discipline, tag stack cleanup, theme hygiene.

The deliverable is not an app you subscribe to. It is a storefront that loads faster after we leave than it did while we were working, and keeps loading that way because the fixes live in your theme, not in a rented dependency. We call it being the last mile developer for vibe coders, which means taking the store you or your team built with AI and design tools and making it survive contact with a real mobile shopper on a real three-bar connection.

If you are running a Shopify store and you currently have more than one app with the word speed in its name installed, the highest-leverage thing you can do this week is open your theme code, find the liquid snippets those apps inserted, and get a measurement of what the store looks like without them. If you want us to run that measurement for you, we are two-week booked out most of the time and the intake form is on the site. The short version of this entire article is that your speed stack is probably the problem, not the solution, and the fix is engineering, not an install.