We took apart the Online Store 2.0 theme of a store we have managed long term, after four years of edits by several suppliers. On disk it had 807 files and 18 MB. A different pair of numbers is more interesting though: 323 templates in JSON format described only 193 different structures (our own analysis of a local copy of the theme, 27 August 2026).
Those hundred and thirty extra templates did not appear there by mistake. They appeared because a one-off matter was repeatedly solved in a permanent way - and that is a disease you can measure before it shows up in the price of every further edit.
Structure, not file: how it is counted
The structure of a template is the set of section types that are enabled in it. Two templates with the same structure do the same thing and differ only in settings: an image, a heading, a colour.
When there are roughly as many structures as files, the theme is fine - each template describes a different type of page. When there are markedly fewer structures, it is a signal that content is being stored in templates instead of in data.
The clearest case from the analysis: 67 collection templates had an absolutely identical trio of sections and differed in four values - a desktop image, a mobile image, a heading and its colour.
The banner was made a template instead of a field in the admin
Those 67 files have one cause and it is a decision, not carelessness. Somebody needed a different header on one collection, the fastest route was to copy the template, and it worked. It worked the second time too. After sixty-seven repetitions a system nobody designed came into being.
The right solution is one template and four metafields on the collection. The content then belongs to the collection, where the shop staff can change it, and not to a file that requires a developer.
The difference in operation is concrete. Changing the banner layout is done in one file in the first case and in sixty-seven in the second - and sixty-seven manual edits mean three of them will be forgotten.
The theme after four years: what is actually in it
| Theme element | Count | Of which dead |
|---|---|---|
| Sections | 149 | 34 |
| Snippets | 102 | 31 |
| Templates | 341 | - |
| Files in assets/ | 138 | 15 (312 kB) |
| Locale files | 52 | - |
| Theme blocks | 19 | - |
Dead means the file name does not occur anywhere else in the theme: no template and no {% section %} calls the section, no render and no include calls the snippet. It is not an estimate, it is a string search across the whole folder.
Almost every fourth section and almost every third snippet were useless. The price for them is not paid in speed - they never reach the page - but in time. A developer looking for a place to put a new feature goes through those 65 files as well.
723 disabled sections lie about what is on the page
JSON templates also keep sections with "disabled": true. They look like part of the page, but they do not render. In the theme we analysed there were 723 of them out of 3,192 inserted sections, that is 22.6 %.
One finding from this group deserves a paragraph of its own. The main-page section, the one that outputs the page text entered in the admin, was disabled in 136 page templates out of 137.
In practice this means the complaint "I fixed the text in the admin and nothing changed on the site" was not a caching or translation bug. It was a consequence. Before you start looking for the cause in the cache, check whether the section that outputs that content is not disabled.
50 % untranslated? Half of that number will never go live
This is the trap everyone falls into who counts locales in bulk. The theme had 52 translation files and a rough calculation gave 50 to 58 % untranslated strings.
Split apart, the result looks different. 24 files had exactly the same number of missing keys, 264 out of 564 - that is the fingerprint of a locale nobody has ever touched, that is, of languages the store does not publish. In the five actually used languages 8 to 12 % were missing.
The difference between "half the theme is untranslated" and "the live languages are missing a tenth" is the difference between two different quotes. Never send a client a rough number until you have split the locales into published and stock ones.
Branched templates come back at the second market
While a store has one storefront, a surplus of templates is annoying but manageable. With the second storefront it becomes a cost nobody budgeted for.
On a live pair of storefronts we measured that 255 out of 264 shared templates had drifted apart between the markets (comparison of exports of both themes, 26 July 2026). A hundred and thirty extra templates means a hundred and thirty places where two stores can differ - and they do, because somebody has to make every fix twice.
Reducing to metafields solves this problem not only backwards, but above all forwards: what is not a template cannot drift apart.
Five questions that tell you you are on this path
A "yes" to two or more of them means the theme has got out of hand and a clean-up pays off sooner than the next feature.
- Does a new template appear when an image or a heading needs changing?
- Are there more files in templates/ than in sections/ and snippets/ together?
- Does the shop staff have to call a developer over text on a collection?
- Is anyone afraid to delete a file because it is not certain what calls it?
- Is the same fix made separately in two storefronts?
The fastest way to check it in a downloaded copy of the theme:
ls templates/*.json | wc -l # how many templates there are
rg -c '"disabled": true' templates/*.json # how many sections are disabled
rg -o '"type": "[^"]+"' templates/*.json | sort -u | wc -l # section typesWhen the third number comes out markedly lower than the first, you are dealing with what this whole article is about.
What to do instead of templates
The procedure has four steps and deliberately does not end with deletion. What is alive has to be established first.
- Measure the structure, not the number of files. Group templates by their set of section types. Groups with more than five files are candidates for merging.
- Separate the variable from the structural. An image, a heading, a colour and a link belong in collection or product metafields. Only what changes the layout belongs in a template.
- Deploy merged templates in groups and check the collections on the site after every group. Merging seventy templates at once cannot be verified.
- Delete dead code last, with a name search across the whole theme and with a backup. A section nobody calls may be called from an app.
Theme blocks solve this problem directly: the layout is composed in the editor instead of creating a file for every variant. The theme we analysed had 19 of them, so the tool was available - it just was not used.
What the clean-up costs you
It is fair to say it out loud. A theme clean-up is invisible. It adds no feature, changes no design, the before and after screenshots are identical. It sells badly and that is exactly why it gets postponed until every edit is twice as expensive.
It pays off at the next order, when the work is done faster because it is clear what is alive. That is a return measured in months, not days, and if somebody promises you otherwise, they are costing out a different project.
The other side of the trade-off: merging templates takes away the staff's ability to click together an exception without a developer. Metafields are order, but also a guard rail, and somebody will find that guard rail irritating.
We take over themes from other suppliers
Send us the store address or a theme export. We will return the number of templates against the number of structures, a list of dead sections and snippets, and an estimate of how much of it can be merged without touching the appearance.
What we build on Shopify and what we check when taking a store over is described on the Shopify store development page. If speed is more your concern, start with the article on why a fast Shopify is slow and the one on auditing apps.
Write to info@lamapixel.com or call +420 775 599 009.
