Judge.me vs Loox vs Stamped: Shopify Review Apps Ranked by Performance

Every Shopify merchant who cares about conversion eventually installs a review app. Every merchant who cares about Core Web Vitals eventually regrets the install they made. After deploying Judge.me, Loox, and Stamped across more than forty stores each over the last four years, the pattern is consistent enough that we can rank them by what actually matters on a product detail page, which is not the feature matrix on the app store listing. It is the cost the widget imposes on Largest Contentful Paint, the cumulative layout shift the star rating block introduces when it finally hydrates, and the total kilobytes the shopper downloads to see a number and a row of stars that could have been rendered on the server in fifty bytes of HTML.

This comparison is observational. The kilobyte figures are 2026 estimates based on production Shopify stores we monitor, and app vendors update their bundles often. What does not change is the architecture. Understanding how each app delivers its widget is what lets you predict which install will hurt your Vitals, and where a server-rendered alternative could replace the widget entirely without giving up the review count that shoppers actually read before they add to cart.

Why the review widget is usually the heaviest third party on a PDP

Open any Shopify product page with a review app installed and filter the network panel to scripts. The review widget is almost always in the top three by transfer size, often second only to the theme's own main bundle. It is larger than the cart drawer library. It is larger than the analytics stack on most stores. It is routinely larger than the product image itself once the image is WebP encoded and properly sized.

The reason is structural. A review widget has to do several things no other third party on the page has to do. It has to fetch a paginated list of reviews, which means a JSON call and templating logic. It has to render star icons, which means an SVG library or an icon font. It has to handle photo and video galleries, which means a lightbox and sometimes a player. It has to submit new reviews, which means form handling, file upload, and validation. All of that ships whether or not the shopper interacts with any of it. On a product page with four reviews, the shopper downloads the same widget bundle as a product page with four hundred reviews. That is a fixed tax on every session.

The compounding problem is that the widget is usually placed in two spots on a single page. There is a summary badge directly under the product title, showing the aggregate rating and count, and there is the full widget lower on the page showing the individual reviews. Both render from the same bundle, but both contribute to layout shift independently. The badge under the title is especially painful because it sits above the Add to Cart button, and anything that changes height above the primary action pushes the action down in the viewport after the shopper has already reached for it.

Judge.me, the sensible default with a CLS problem nobody mentions

Judge.me is the app we recommend most often, which is not the same as saying it is the best performer out of the box. It is the app whose performance profile is most forgiving when you do the integration work properly, and whose pricing does not punish stores that grow past the free tier.

The default Judge.me install ships a loader script that weighs roughly fifty-five to eighty kilobytes gzipped in 2026, with widget CSS adding another fifteen to twenty-five kilobytes and one API call per product page to fetch the reviews JSON. The script is deferred on modern installs, which keeps it out of the critical path for LCP, and the API call is quick enough that the summary badge under the product title usually hydrates within the first second on a decent connection. This is where most performance reviews of Judge.me stop, and this is where the trap starts.

The badge container rendered by the Shopify theme is an empty div with no reserved height. Before the script runs, the div occupies zero pixels. After the script runs, the div occupies approximately eighteen to twenty-two pixels, because it now contains a row of SVG stars and a review count. That is a layout shift. Every element below the badge, including the price, the variant selectors, and the Add to Cart button, moves down by roughly twenty pixels. On a fast connection on a warm cache the shift happens so early that Core Web Vitals does not penalise it heavily. On a cold mobile connection, which is the traffic Google measures for field data, the shift lands well after the shopper has started reading. That is the kind of shift that drags a store from a passing CLS score to a failing one, and it is the kind of shift that never appears on the app vendor's marketing page because Judge.me's lab tests are run on theme previews that already have the widget cached.

The full widget at the bottom of the page is a bigger shift in absolute terms, expanding from a sixty pixel placeholder to anywhere between four hundred and nine hundred pixels depending on how many reviews are fetched. Because that shift is below the fold on most templates, it rarely affects CLS as scored, but it does affect scroll anchoring, which creates the jarring jump merchants describe as the widget moving under their finger when they are trying to read a review.

Loox, the video review trap

Loox is the app we recommend to apparel brands and lifestyle brands where the photo wall of customer submissions is a meaningful part of the conversion story. It is also the app that imposes the heaviest performance tax of the three, and the tax is not only in the main bundle. It is in the media it loads alongside the bundle.

The Loox main script in 2026 is roughly one hundred and ten to one hundred and sixty kilobytes gzipped, which already places it ahead of Judge.me on pure JavaScript weight. That number understates the real cost because the Loox widget is photo and video first. Every thumbnail in the review grid is an additional network request. On a product page with thirty reviews and photo uploads enabled, the widget fires thirty image requests to render the grid. If video reviews are enabled, the player loads for any inline video, which adds parse cost even when the video itself is lazy. We have seen total transfer for the Loox widget block exceed two megabytes on PDPs where the brand has leaned into video reviews and left the default settings on.

The CLS profile is worse than Judge.me. The Loox grid uses a masonry layout that can only finalise its geometry once every thumbnail has reported its natural dimensions. On a cold connection the grid rearranges itself for several seconds as images arrive in an unpredictable order. The star summary under the product title exhibits the same hydration shift as Judge.me, with roughly the same magnitude, so that part is a wash. What is not a wash is the weight of the photos, which compete for bandwidth with the hero product image and can delay LCP on templates where the hero loads from the same origin or pipeline as the review media.

Loox merchants who care about Core Web Vitals generally have to do two things. They have to enforce native lazy loading on every thumbnail, which Loox does not always apply correctly on custom themes, and they have to gate the entire grid behind an intersection observer so that the widget mounts only when the shopper scrolls near it. Both are possible, neither is default, and both are work the merchant pays for in consultant hours.

Stamped, the web component option

Stamped sits between the other two on most performance dimensions. The main bundle in 2026 weighs roughly seventy to one hundred and ten kilobytes gzipped, which is heavier than Judge.me and lighter than Loox. The delivery mechanism is more modern on newer installs, because Stamped has moved toward custom elements for its badge and widget, exposing tags like a stamped-badge element that upgrades once the script loads.

Web components sound like they should solve the CLS problem because they are part of the HTML at parse time. In practice the upgrade still happens after the script runs, and unless the theme reserves height for the unupgraded element through CSS that targets the not defined pseudo-class, the upgrade is a layout shift. Most themes do not ship that CSS, and most Stamped installs do not add it, so the experience is similar to Judge.me in CLS terms despite the architectural advance.

Where Stamped earns its place is in merchants already using its loyalty and Q&A products. If the store is already paying Stamped for points, tiers, and question threads, adding reviews from the same vendor avoids a second SDK on the page and simplifies identity matching. For a store that only needs reviews, the web component architecture is not a decisive advantage, and the pricing is harder to justify than Judge.me's at comparable volumes.

The server-rendered alternative that no review app will tell you about

All three apps write data to Shopify product metafields. Judge.me writes an aggregate rating and review count. Loox writes the same. Stamped writes the same. These metafields are available to your theme at the Liquid layer, which means they can be rendered as plain HTML in the page response, before any script runs.

A star summary rendered from a metafield is a small span element containing a row of inline SVG stars masked to the rating, followed by the review count as text. Total weight is under two hundred bytes. It reserves its own height because the SVG has fixed dimensions. It contributes zero layout shift because it is present at first paint. It works with JavaScript disabled. It works when the app's CDN is slow. It works when the shopper's network blocks third party scripts entirely.

The trade-off is interactivity. The metafield badge is not clickable. It does not scroll the page to the review list on tap. That trade-off is almost always acceptable, because the shoppers who want to read the actual reviews scroll down to read them, and the reviews themselves can still be rendered by the widget lower in the page where CLS does not affect the score and where the bundle can be gated behind an intersection observer so it loads only if the shopper scrolls near it.

This pattern, metafield-rendered summary at the top, lazy-hydrated widget at the bottom, is the single biggest performance win available to any Shopify store running any review app. It removes the visible layout shift above the fold, it lets the shopper see the social proof immediately, and it defers the expensive part of the widget until there is evidence the shopper cares enough to scroll. We have moved stores from a failing CLS score to a passing one with this pattern alone, with no change to the app they use and no change to the reviews they display.

Ranking in prose

If performance is the primary criterion and the store does not depend on visual review content, Judge.me is the clear recommendation. It has the lightest default footprint of the three, the most predictable CLS profile once the metafield pattern is applied, and the most forgiving pricing at scale. It is the app we install first and only replace if a specific feature gap forces the change.

If the brand depends on photo and video reviews as part of its conversion story, Loox is the only app of the three that makes that content easy to collect and display, and the performance tax is the price of that positioning. Loox should be chosen with eyes open, with image lazy loading enforced, with the grid gated behind an intersection observer, and with the understanding that the store will need continuous performance attention to stay in the passing band on Core Web Vitals.

If the store is already inside the Stamped ecosystem for loyalty or Q&A, Stamped reviews is the right choice for consolidation reasons, and the web component architecture is a genuine advance that pays off once the theme adds the CSS to reserve height for the unupgraded elements. For stores that only need reviews, Stamped is a defensible choice but not a compelling one.

Closing

The real question is not which review app is fastest. It is which parts of the review app you actually need on the server-rendered product page and which parts you can defer. The summary badge belongs in the HTML response. The full widget belongs behind a scroll trigger. Every app we install ends up in that shape before we hand the store back to the merchant, and every store we audit that has not been through that shaping is leaving Core Web Vitals and conversion on the table.

A WitsCode review-widget audit looks at exactly this split. We measure the current bundle weight, the layout shift contribution from the badge and the widget separately, and the path from the app's metafields to a Liquid-rendered summary that replaces the heavy client-side badge with static HTML. The widget itself stays where the shopper expects it, lower in the page, gated behind an observer, loading only when it earns its place in the session. The result is a product detail page that keeps the review count and the star rating shoppers look for, without the kilobytes and the shifts that usually come with them.