The Shopify apps quietly slowing your checkout down

The app slowing your store down is not on your checkout page

Take a composite of three stores we have watched reach the same conclusion. Paid traffic converts worse than last quarter, the ads look fine, and somebody opens the web performance report at 11pm.

Mobile product pages are painting slowly. The largest element on the page turns out to belong to a reviews widget nobody has opened the settings for since 2023.

Then the conversation goes sideways, because the team starts talking about the checkout. Shopify hosts your checkout and does not let apps drop arbitrary JavaScript into it, so the checkout page is close to the one page on your store an app cannot make heavier.

The slow checkout people describe is almost never the checkout. It is the product page that took four seconds to become clickable, and the cart drawer that stuttered on open.

Everything below is about that stretch, from the product page to the payment button, because that is where the app weight actually lands.

Three ways an app can attach itself to your store

An app has three places to put itself, and the choice decides almost everything about what it costs you.

Script tags load a remote JavaScript file into your storefront pages. The file lives on the app’s own domain, so the browser opens a new connection to fetch it, and it usually loads on every page whether or not the feature is used.

Theme app extensions ship app blocks you place in the theme editor. Assets are served from Shopify’s CDN, and a block only loads on the templates where you actually placed it.

Server-side extensions run nowhere near the browser. Shopify Functions execute on Shopify’s infrastructure during checkout, and web pixels run in a sandbox rather than on your page’s main thread.

The third category is invisible in a speed audit because it contributes nothing to measure. That is the whole point of it.

What each app category costs in milliseconds

Assumptions for every row: a mid-range Android handset on 4G, 1ms of main-thread time per kilobyte of JavaScript for parse, compile and execution, and 150ms to open a connection to a new third-party origin. These are planning figures, not measurements from your store.

App category	Usual delivery	JavaScript shipped	Modelled delay before largest paint
Page builder	Script tag or theme code	200 kB	350ms
Live chat	Script tag	180 kB	330ms
Upsell and bundling	Script tag	120 kB	270ms
Reviews	Script tag	90 kB	240ms
Popup and email capture	Script tag	60 kB	210ms
Currency switcher	Script tag	40 kB	190ms
Wishlist	App block	30 kB	30ms
Analytics via web pixel	Sandboxed pixel	25 kB	Off the main thread
Discount via Shopify Function	Server side	0 kB	0ms

The wishlist row is the one worth staring at. Thirty kilobytes delivered as an app block from Shopify’s CDN costs 30ms, while the same thirty kilobytes from a new third-party origin would cost 180ms, because the handshake dominates the payload.

Size is not the variable most stores think it is. Origin count and page coverage are.

Six script tag apps of modest size, each loading on every page, cost more than one large app block on the product template. Which categories deserve a slot at all is answered by category in the stack audit.

Why the script tag route closes on 26 August 2026

Script tags are on their way out, and the dates are worth knowing because they change what your app vendors have to do.

Script tags stopped running on the order status page for Plus stores in August 2025. For non-Plus stores they stop on 26 August 2026.

Separately, script tags now only work on vintage themes, and any app submitted to the Shopify App Store has to integrate through theme app extensions instead. An app still asking for script tag access on an Online Store 2.0 theme is telling you something about its release cadence.

The practical effect for a merchant is good. The heavy delivery mechanism is being closed off, and the replacement is a block you can see, move, and delete in the theme editor without emailing anyone.

Most stores have never placed a single app block, which is a separate and more interesting problem, covered in the extensions nobody can ignore.

How to find the app that owns your LCP element

The web performance report in your Shopify admin runs on real user metrics from actual shoppers rather than a lab test, which is what makes it worth opening.

Look for the LCP target element. The report gives you the CSS selector of whatever painted last, and app-owned elements almost always carry the app’s name in a class or an id.

If that selector points at your own hero image, stop reading about apps. You have an image problem, and it is cheaper to fix.

Two things about the data will trip you up. The window is 28 days, so an app installed yesterday will not show its full cost until next month, and the report needs your storefront password protection removed to collect anything at all.

The honest version of the test is slower than anyone wants. Uninstall one app, wait a full fortnight, and read the number again, because uninstalling three at once tells you only that something helped.

What a zero-JavaScript offer looks like

Offer mechanics are the app category with the widest gap between implementations. The same feature can be a 120 kB storefront script or nothing at all, depending on where the logic runs.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

The discount is a Shopify Function reading a shop metafield during checkout. There is no storefront bundle, no third-party origin, and nothing on the main thread, because the decision happens on Shopify’s infrastructure rather than in the shopper’s browser.

That architecture is not a performance feature anyone designed for its own sake. Functions cannot call the network at runtime, which is why the state has to be written to a metafield in advance, and the reason for that constraint is set out in what changed after Scripts died.

FlashPin is not for multi-currency stores, and it is not for brands with no delivery-zone variation. A zero-weight offer engine on a store with one uniform delivery zone is a zero-weight offer engine with nothing to offer.

The one honest cost is the display side. If you want a banner telling shoppers which pincode is live, that banner is an app block with real bytes attached, and it belongs on the templates where it earns its place rather than sitewide.

Attribution is the category most likely to run on every page

Attribution and analytics tools have a structural reason to be heavy. Their job is to observe the session, so the naive implementation is a script that loads on every page view and watches.

A redirect-based approach inverts that. The tracking happens once, at the click, before the shopper reaches your storefront at all.

Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients.

The trade is real and worth stating plainly. A redirect adds a hop at the moment of the click, and a page-level tracker adds weight to every page of the session, so the redirect wins on stores where shoppers view several pages and loses on one-page sessions.

Web pixels are the other half of this. Shopify runs them in a sandbox off your main thread, so an analytics tool delivered as a web pixel is cheap in a way the same tool delivered as a script tag is not, and it is a fair question to ask a vendor.

Which apps are worth the milliseconds

Speed audits go wrong when they turn into a purge. Some apps earn their weight several times over and the arithmetic is not hard to set up.

Pick your own conversion assumption. Assume a 1% conversion loss for every 200ms of added delay, which is a planning figure to replace with your own data rather than a law of nature.

At 900 orders a month, ₹1,800 AOV and 40% gross margin, 1% of orders is 9 orders and ₹6,480 of gross margin. A 330ms chat widget therefore costs about ₹10,700 a month before it has answered a single question.

That is a bar, not a verdict. A chat widget that converts fifteen hesitant buyers a month clears it, and the same widget on a store selling a ₹400 impulse product does not come close.

Run the same test on every app on the bill, in the same units as the fee. The break-even arithmetic for the fee itself sits in the stack that pays for itself, and the two numbers add up to what an app actually costs you.

When app weight is not your problem

On most stores the largest element is the merchant’s own hero image, not an app. Compressing that image and giving it loading priority beats a month of uninstalling things, and it is the first check for a reason.

Small stores cannot read this data at all. A 28 day window on 4,000 sessions produces a number that moves when one shopper on a bad connection loads the homepage twice, and you will be reading noise and calling it a regression.

Vintage themes change the whole calculation. If your theme predates Online Store 2.0, app blocks are not available to you, script tags are all your vendors can offer, and the real project is the theme rather than the app list.

The last limitation is the one nobody says out loud. The fastest store in your category, with no reviews, no chat and no upsell, is almost never the one making the most money, and a store optimised only for milliseconds is optimised for a metric its shoppers were never measuring.