The Apps Behind Every Slow Shopify Store (Data From 50+ Audits)

Every Shopify performance post names the same suspects and then refuses to show numbers. We have spent the last eighteen months running performance audits for Shopify merchants, fifty plus stores at this point, and the pattern is too clean to keep quiet about. The apps that appear on the slow stores are the same apps, installed in the same combinations, breaking Core Web Vitals in the same ways. This post names them, shows what they weighed on the test pages we ran, and explains three cross-app effects that single-app benchmarks miss.

Before the list, a framing note. Every app below can be configured to behave better than what we measured. These are the defaults and common install patterns we saw in the wild on stores that came to us specifically because they felt slow. Weights are transfer size in kilobytes on a single test page on a dated run, captured in WebPageTest on a Moto G Power profile throttled to 4G. They are not universal verdicts. They are field notes.

How we built the sample

The fifty plus audits in this dataset ran between October 2024 and March 2026. Every store came to WitsCode asking for help with either a failing Lighthouse score, a drop in organic traffic that correlated with a Core Web Vitals regression, or an unexplained checkout conversion dip. We captured the installed app list from the Shopify admin, ran three WebPageTest traces on the homepage, a collection page, and a top-selling product page, and attributed each long task on the main thread back to the originating script URL.

The ten apps below showed up in that audit list more often than any others. They are not obscure. They are the apps every growing Shopify store installs. That is exactly why this is worth writing down. If the tools everyone reaches for are also the tools breaking the store, the merchant needs more than a generic "audit your apps" recommendation.

The ten most frequent apps on slow stores

Klaviyo appeared on forty one of fifty audits. The onsite.js bundle ran between ninety five and one hundred forty kilobytes compressed on the pages we tested, with a parsed size closer to five hundred kilobytes after decompression. It installs a MutationObserver that re-evaluates whenever the DOM changes, which on infinite-scroll collection pages turned into a steady background cost we could see in the performance panel. Klaviyo itself is not the problem. The problem is that Klaviyo onsite forms are almost always paired with one more popup app, and the two of them stack.

Judge.me was on thirty three. The widget loader itself is small, around twelve kilobytes, but it pulls in eighty to one hundred sixty kilobytes of review HTML plus a star sprite stylesheet per product page. Lazy mode is available in the dashboard. Most installs we audited had not enabled it, so the widget hydrated above the fold on every product detail page whether the shopper scrolled to reviews or not.

Loox appeared on twenty two. Fifty five to ninety kilobytes of JavaScript and thirty to seventy of CSS, plus a Swiper fork for the carousel. Loox hydrates review cards on the client, which means the product grid layout shifts after the first paint unless the theme reserves space for the star row. On several audits we measured CLS spikes in the 0.12 to 0.18 range traceable directly to late-hydrating Loox badges.

Gorgias was on nineteen. The launcher alone is sixty to one hundred ten kilobytes and subscribes to window events the moment it loads. When a shopper actually opens the chat, a second payload of two hundred to three hundred fifty kilobytes arrives. The launcher is the part that matters for Core Web Vitals because it runs on every page load regardless of whether the widget is ever opened.

PageFly appeared on eighteen of the fifty stores. Page builders replace the theme rendering pipeline with their own runtime. We measured one hundred fifty to two hundred forty kilobytes of builder JS on PageFly-rendered landing pages, and the per-widget pattern means a page with a countdown, a tabs component, and an image slider ships three separate scripts instead of one bundle.

Privy was on seventeen. Core payload ran forty to seventy five kilobytes, another sixty to one hundred twenty when a campaign actually rendered. Privy injects styles inline rather than through a stylesheet, which defeats browser CSS caching on repeat visits.

Yotpo was on sixteen. Ninety to one hundred seventy kilobytes across reviews plus loyalty when both are active on the same store. If SMSBump is enabled on the same Yotpo account, a third bundle comes with it.

Tidio was on fourteen. Eighty five to one hundred thirty kilobytes for the launcher, three hundred plus when opened, and a WebSocket connection that opens on page load whether or not the shopper engages.

Shogun appeared on twelve. Same builder pattern as PageFly, one hundred eighty to two hundred sixty kilobytes of runtime, and we repeatedly found duplicated jQuery when the theme already shipped one.

ReCharge was on eleven. Twenty five to fifty kilobytes on a subscription-enabled product page. Light by comparison to the others, but the account portal script adds eighty kilobytes on customer pages where logged-in shoppers actually spend time.

Render-blocking versus deferred, and why defer is not a free pass

Most of these apps now ship their main tag with async or defer attributes. That is good for First Contentful Paint because the HTML parser does not wait on the script. It is not good for Largest Contentful Paint when the LCP element is a hero image on a product page and the deferred script lands in the same frame as image decode. The browser has one main thread. A two hundred kilobyte script that parses while your hero image is trying to decode will delay LCP even if the script tag had defer on it.

The framing "defer your scripts and you are fine" is a myth from the HTTP/1.1 era. With HTTP/2 and especially HTTP/3 the cost has shifted from connection count to CPU. Parse and compile now dominates. A mid-tier Android phone takes roughly one second to parse a megabyte of JavaScript. If the combined app payload on your product page is eight hundred kilobytes compressed, you are spending close to a second of main thread time on parse alone before any of your theme code runs. Defer does not help with that. Only shipping less JavaScript does.

Total Blocking Time attribution, the part other posts skip

The Chrome DevTools Performance panel lets you attribute long tasks back to the script URL that triggered them. Most "slow Shopify apps" posts quote totals without this attribution, which makes their advice unactionable. You cannot know whether to remove Judge.me or Klaviyo until you know which one is eating your budget.

On the median audited store the TBT breakdown on a product page came out roughly like this. Theme JavaScript accounted for fifteen percent. Shopify platform scripts, including the checkout token and the analytics bootstrap, accounted for another ten. Third-party analytics, mostly GA4, Meta Pixel, and TikTok Pixel combined, took fifteen. The reviews app, whichever one it was, took twenty. Chat took fifteen. The popup took ten. The page builder runtime, when present, took fifteen more.

Apps accounted for about sixty percent of TBT on a typical audited store. That is the headline. Your theme is not the problem. Your apps are the problem, and a small number of identifiable apps drive most of it.

The cross-app interaction effects nobody writes about

This is where single-app benchmarks fail merchants. An app that looks reasonable in isolation can destroy performance when it is layered with another app that does a similar job. We saw three distinct interaction effects often enough to call them patterns.

Pointer event contention

When Privy and Klaviyo are both installed, both are listening for pointer events on the document so they can trigger exit-intent or engagement popups. Each handler on its own is fast, a few milliseconds. The problem is that they fire synchronously during the same user interaction. When a shopper taps the add-to-cart button, the INP measurement is the full interaction latency, which now includes both handlers plus any main-thread work they scheduled.

We measured INP on add-to-cart buttons go from ninety milliseconds with one popup app installed to two hundred sixty milliseconds with two. The browser scheduler cannot parallelize synchronous JavaScript handlers on the same event. Two popup apps fighting for the same events is a direct, measurable hit to INP, which is now a Core Web Vital that affects your ranking.

CSS collisions on star ratings

Loox, Judge.me, and Yotpo all inject star rating sprites, and they all use their own class names. That sounds safe. It is not, because the widgets render at different times. On one audited store running Loox on the collection grid and Yotpo on the product detail page, the second widget hydrated after paint and repainted its stars, creating a late CLS spike that pushed the page to 0.14.

The fix is picking one review app and removing the other. Merchants rarely do this on their own because each app owns a different feature, one has better referral mechanics and the other has better UGC tooling, and removing either feels like a step back. It is not. Running two review apps is a reliable way to fail CLS.

The page builder tax

Shogun and PageFly both move layout decisions from the server to the browser. Instead of Shopify Liquid rendering a section on the edge and sending HTML, the builder sends a runtime and a configuration, and the browser reconstructs the section at hydrate time. On a landing page with a countdown timer, a tabs component, and a featured collection, the builder ships three small scripts, each of which has to parse and execute before its section renders.

We audited one store where a PageFly landing page fired eleven separate requests for builder assets, totaling two hundred forty kilobytes, before any first-party product content rendered. The same page rebuilt as a native Liquid template shipped zero builder JavaScript and cut LCP from 3.8 seconds to 1.6.

What to actually do about it

Pick one review app, not two. If you have both Loox and Yotpo, one of them is costing you CLS and neither is adding enough on top of the other to justify the cost. Same logic for popups. One popup tool is enough. If Klaviyo has forms, you do not also need Privy.

Turn on lazy mode for reviews. Judge.me and Loox both support deferring widget hydration until the shopper scrolls to the reviews section. Most installs we audit have not enabled this. It is a one-click change in the app dashboard and it removes the review widget from your above-the-fold budget entirely.

Move chat to a delayed load. Gorgias and Tidio both ship a small launcher that expands on click. If your chat does not need to be available in the first five seconds of the page life, you can defer it yourself with a small script that injects the chat loader after a timer or on the first user interaction. We have done this on several audited stores and it removed sixty to one hundred kilobytes from the critical path without any measurable drop in chat engagement.

Replace page builder landing pages with Liquid sections when traffic justifies it. Shogun and PageFly are fine for rapidly testing page ideas. Once a page is the destination for a paid campaign or a top organic landing page, the builder tax becomes a real revenue cost. Rebuilding it as native Liquid pays for itself in conversion lift.

Audit Klaviyo configuration. Klaviyo itself is not usually removable, it is running your lifecycle email, but the onsite.js configuration is. If you are not using onsite forms, you can disable the form fetch. If you are using forms, make sure they are not rendering above the fold on mobile when they fire as overlays.

How WitsCode runs this audit on your store

We built the performance audit WitsCode offers around exactly the methodology in this post. You give us a URL. We run the WebPageTest capture on three representative page types, pull the installed app list from your admin, and return a ranked table showing each app by its measured contribution to TBT, LCP, and CLS on your actual pages with your actual theme, not a generic benchmark. Then we hand you a shortlist of what to change and in what order, ranked by measured impact rather than by which app has the worst reputation.

Most merchants have three or four apps doing real damage and another five or six that are fine. Knowing which is which, on your store specifically, is the difference between a week of ripping out apps that were not the problem and a one-week sprint that actually moves your Core Web Vitals back into the green.

If your Shopify store is slow, the apps in this post are probably why. Which of them, in what combination, and in what order to fix them is a different question, and that is the one we answer. Send us the URL and we will run the numbers.