Start an Online Business with Shopify.
3 days free, no credit card. Then $1/month for your first 3 months.
We take the guesswork out of Shopify decisions. Every number on this site comes from a first-party dataset of 3,500,000+ live Shopify stores, not surveys or estimates. Here is exactly how we collect that data and turn it into the figures you see.
Most "best Shopify theme" advice is opinion. Ours starts with evidence: we scan real, live Shopify storefronts and record the theme and apps each one runs, so the percentages you see reflect what merchants actually use in the wild, not guesses or vendor marketing. This page explains where that data comes from and how we turn it into the numbers on our blog and statistics pages, so you can make firm decisions based on real stores.
The percentages you see on our data blocks ("18% of stores use this app", "9% of stores run this theme") come from our own first-party scan dataset. Our detector has scanned 3,500,000+ Shopify stores since 2017. The percentages themselves are computed from our detection record, which runs from February 2026 to today and is refreshed daily: each figure is a share of the stores in that record, not of every store ever scanned.
A store enters our dataset the first time someone submits its URL: a visitor using our public detector or our browser extension. Each successful scan records the store's detected theme, the apps we can fingerprint from the storefront, and the timestamp. We do not scrape Shopify or crawl en masse; every store in our dataset was added by a real person running the detector.
Theme detection reads the store's public storefront and looks for the signals a Shopify theme leaves behind. We check several independent markers and only record a theme when they agree, which keeps false positives low. If none of them identify a theme, the store is recorded as "theme not detected" and left out of theme adoption stats.
App detection works the same way. We scan the public storefront for the footprints Shopify apps leave behind, combine several independent signals, and cross-check them against a maintained library of patterns for the most popular apps. An app is only counted when we can positively fingerprint it, so a match means the app is genuinely present on that storefront.
For any given app or theme, the percentage shown is the count of distinct domains where we detected it at least once, divided by the total distinct Shopify domains in our dataset:
For segment-filtered tables (for example, "themes used by dropshipping stores"), the denominator narrows to just the stores in that segment, so each percentage reflects that group rather than the whole dataset.
Each app in our database carries two kinds of labels: its function (what the app does, such as reviews, SEO, page builder, live chat, or email marketing) and one or more use cases (what kind of store uses it, such as dropshipping, print on demand, subscription, or wholesale). Use case labels are reviewed by our team based on each app's official Shopify App Store description. One app can carry multiple use case labels when it serves multiple audiences.
Theme speed is measured on real stores, not in a lab. We read Google's Chrome UX Report, which reflects the Core Web Vitals that Chrome users actually experienced on the Shopify stores running each theme, aggregate it per theme, and report medians and pass rates only, never averages or extrapolated totals. A theme's numbers show in full once at least 50 of its stores have field data, carry a limited-sample note between 20 and 50, and stay pending below 20, so every figure rests on a real sample.
We report three cohorts side by side, because the same theme performs differently depending on what merchants load onto it:
For each cohort we publish a pass rate (the share of stores meeting all three Core Web Vitals) plus the median of each metric, rather than blending the three metrics into one index. A blended index clusters near the top, because most live stores already sit in Google's good range, and hides the real differences between themes. Google's threshold for each metric, and what it measures:
The one number we do rank on is the all-stores pass rate, adjusted for how many stores it was measured across. We use the lower bound of its confidence interval rather than the raw percentage, so a theme passing 92% on 24 stores does not outrank one passing 76% on 48,000. Thin samples are pulled down automatically and by a defensible amount; the percentage we display is always the raw one.
Two things to keep in mind. First, a theme's field numbers reflect the type of stores running it as much as its code: a theme popular with image-heavy luxury brands will read slower than one used for lightweight catalogs, even if the code is identical. We describe these figures as the speed of the stores running a theme, not as the theme making stores slow. Second, stores enter our dataset when someone submits them to the detector, so the sample leans toward popular and interesting stores rather than a random cross-section of Shopify.
A store's app count is the number of distinct apps we detect on it, from the same detection that produces our app adoption figures. Stores are grouped into the bands we publish everywhere else: 1, 2, 3, 4, 5, 6 to 10, 11 to 20, and 21 or more. A store we have never successfully scanned for apps belongs to no band and is left out of these figures entirely, rather than being counted as running zero apps.
When we report Core Web Vitals by app count, both halves come from the same store: the real-world speed data Chrome users produced on it, and the apps we detect on it. The relationship that shows up is an association between the kind of store and the speed its visitors get. Stores running twelve apps are typically older, larger and busier than stores running two, so the app count describes the store at least as much as it describes the software.
The obvious comparison, stores with an app against stores without it, is misleading on its own. The two groups are not alike: bigger and busier stores install more apps, and they differ in many other ways that affect speed. Compared directly, an app can look slow purely because successful stores are the ones that install it.
So we do not compare the two groups as they stand. Every store is sorted into a cell defined by two things: the theme it runs, and the app-count band it falls in. Only cells holding stores on both sides, with the app and without it, count at all. Within a cell we are comparing stores that are alike in the ways we can measure. We then combine the cells, weighting the without-the-app side to match the mix of cells the app's own stores actually sit in, so both sides are read across the same spread of themes and app loads.
We match on theme and app load, and we do not control for catalogue size. We held catalogue size as a third dimension until August 2026 and dropped it: the product counts we hold are recorded snapshots rather than live figures, thousands of the stores with real-world speed data have no count at all, and splitting the cells that finely left most of them with stores on one side only, so they were discarded. Two dimensions leave more stores inside a usable comparison, which is the thing that decides whether a figure can be published at all. It does mean a store's size is controlled only as far as the theme it chose and the apps it runs stand in for it.
The difference this makes is not cosmetic. Compared raw, stores running schema markup pass Core Web Vitals slightly less often than stores without it. Compared cell by cell, they pass considerably more often. The raw comparison has the sign backwards.
We publish the number of stores and the number of cells behind every comparison. A matched figure needs at least 25 stores with real-world data standing behind it; below that we publish the plain comparison alone and say why, because a standardised rate on a handful of stores is noise dressed as a finding. Stores whose theme we could not resolve, and cells where one side has no real-world data, take no part in the matched figure. The medians shown beside a comparison are ordinary medians across the stores in those cells, not re-weighted the way the pass rate is.
What this is not: proof that an app makes a store faster or slower. Matching removes the differences we can measure, and it cannot remove the ones we cannot. A positive result means stores running the app are faster than comparable stores without it, which is a reason to say the app carries no measured speed cost, not a reason to say it improves anything. Nothing here is a before-and-after measurement of the same store. To know what one app does to your store, measure your store with it and without it.
Being clear about the limits is part of being trustworthy. Our data does not capture:
Data blocks recompute daily. The "Last updated" date on each block reflects the last successful refresh. The total store count grows as new domains are submitted to the detector.
App and theme catalogs are kept in sync with the public Shopify App Store and Shopify Theme Store. Vertical and category classifications use Shopify's open-source Standard Product Taxonomy as the canonical reference.
Free to cite and republish with a link to shopthemedetector.com. Journalists, researchers, analysts, and vendors writing about their own numbers are all welcome to use these figures in articles, reports, decks, and marketing pages. No permission request needed, and no fee. All we ask is a visible credit and a working link back to the page you took the figure from.
ShopThemeDetector, "Shopify Usage Statistics", 2026. https://shopthemedetector.com/shopify-statistics
These figures are recomputed from live detection daily, so quote the date you accessed the page alongside the citation.
This dataset takes the guesswork out of what merchants actually run, but it is only half of how we recommend. Our editors weigh quality, pricing, support, and fit for each list's specific audience, and the numbers inform those picks without dictating them. Read how the two work together in our review approach, or browse the live figures on our Shopify statistics hub.
Enter a Shopify URL and see its theme, full app stack, and how it compares to its category, from the same dataset described above.
Scan a store